Automation Studio

Project Architecture

Projects should be stored in C:\Projects\<Client>\<ProjectName>. This ensures that referenced files point to the correct location on everyone’s computer.

Creating New Projects

To create a new Automation Studio project one can use Loupe’s internal framework for creating starter projects, Buttercup (https://github.com/loupeteam/Buttercup). The README within the repo has the latest instructions on how to use the tool. Contact Loupe for starter projects built by Buttercup.

Structure

The packages in the logical view are traditionally arranged in order of importance as below with corresponding descriptions. Order of packages may differ between projects.

  • Documentation - Project documentation.
  • Infrastructure - Project infrastructure. Some notable tasks contained in this package include:
    • FirstInitProg - Task for initializing the machine. This is the first task run on startup. It ensures that certain conditions are met before other programs initialize. This could include loading a configuration file, initializing the logging system, defining File Devices, etc. It should not have any cyclic code.
    • getRevInfo.sh - Build tracking (see Tracking Machine Builds).
    • ErrorProg - ErrorCollector or AlarmLib cyclic task.
  • HMI - User facing variables, tasks, and resources.
  • DataHandling - Handles database management, some file management, and recording data.
  • MotionControl - Motor control, CNC, Robotics, Synchro, and anything motion related.
  • ProcessControl - Low level control of process tasks such as temperature control, metrology data, and control of peripheral systems.
  • Communication - Communication between machine components.
  • Machine Control - Top level control, safety programs, and machine commands and statuses.
  • Diagnostics - Error management and logging. Deprecated
  • Utilities - Any auxiliary helper functions. Deprecated
  • Mapp - Mapp components.
  • Test - Tasks used for testing machine functionality.
  • Libraries - Holds any libraries needed for the project.
    • _AS - BR libraries.
    • Motion - BR Motions libraries.
    • <Client> - Client libraries. ex Loupe.
  • GmcIpConfig - Settings for the GMC Interpreter.
  • GmcIpUserConfig - User settings for the GMC Interpreter.

Configuration Variables

Each task can contain its own configuration as a task local variable named Configuration. Any global configuration is kept in a global structure named gConfiguration. These configuration variables are maintained in permanent memory, and can be backed up and restored to and from a file, configuration.csv.

Permanent Memory

Permanent Memory is handled by the Persist library. Using this library gives us more flexibility in how the permanent memory is handled. We can easily back up and restore permanent memory. It also gives us the ability to save local variables and parts of structures. For example: the axis parameter structures are saved directly in permanent memory so that user changes can be saved through power cycles. This is currently not possible as a built in function since only entire global structures can be saved to permanent memory.

Persist is given multiple data chunks so that different parts of permanent memory can be backed up and restored separately. For example, the homing data can be backed up and restored separately from the machine configuration.

It is a good idea to leave some unused space in the buffer. This allows changes to be made to the data structures without having to reconfigure permanent memory.

Tracking Machine Builds

It is important to know what software and configuration is shipped on each machine. After a machine configuration is changed, it should be backed up to a file and saved in the repository for future reference. The folders on the user partition should be saved in the repository’s user partition folder, contained in a folder with their serial number or other standard identifier.

The most important folders are Recipe and Configuration TODO: I don’t think these are up to date. What about PermBackup?. Before a machine ships, and before a machine is updated or worked on, these folders MUST be backed up to ensure that the machine can be restored to its running state without reconfiguration.

System Integration with Piper

A machine subsystem should be self contained and, typically, in its own task. Integration of subsystems into the main machine logic should be done using Piper’s state/response mechanism. Piper is the main tool used to handle subsystem synchronization. If the subsystem needs tighter integration with other components, it may be necessary to make a global interface for other systems to use.

Machine state changes should be requested using:

gMachine.IN.CMD
Piper Description Piper Flowchart
Folder Structure File Structure

Motion

Motion Functions

The ServoMgr task contains all of the axis functions that apply to all axes, including real and virtual motors. This includes status, error handling, position feedback, etc. New functionality that should be applied to all axes, such as tuning or torque monitoring, should be added to the ServoMgrs AxisBasicFn_cyclic TODO: Is this true? I don’t think this is the architecture we use anymore..

Machine specific functions should be contained in a task that is specific to that functionality. One example is a task for probing routines that require PLCOpen, as opposed to G-Code. The process task should use local PLCopen function blocks, as opposed to AxisBasicFn() commands. This allows the proper use of the function blocks’ ‘Done’, ‘Busy’, ‘Error’ and ‘CommandAborted’ outputs.

Machine functions that use G-Code programs should be started using gCNCMgr parameters and gMachine.IN.CMD.Start. This ensures that any necessary administrative functions are performed before starting the program. These functions could include setting limits based on the operating mode, for example.

Synchro

Synchro is designed to be a modular backbone for kinematic systems. Synchro can be added to any project to convert it from a pile of axes into a working system with multiple frames, tools, compensations, kinematic transformations, and geometric offsets.

Generally, the rest of the application should only need to interface to Synchro through a defined application interface for enabling the synchro chain, changing between frames, and setting operating modes.

Tasks

Tasks should be able to run independently of the system. Tasks should generally avoid state if possible. In general task cyclic should go as follows: Convert IO to useful information (scale, interpolate, store internally), Do logic, Call FUBs, Reset inputs.

Made by Loupe