System Heirarchy

Typical task types include:

Drivers, Application Tasks, Process Task

The goal of a well designed software platform is to allow the developer to spend a majority of the development time up front, either in simulation or with low level hardware, building the Drivers and Application code before the machine is built. This allows them to spend time on the machine debugging the Process. Depending on the type of drivers it may be difficult to do without any hardware, but the typically application task should be completely simulatable.

Drivers

Drivers are the lowest level functions and should be closest to the hardware. Most drivers have minimal state machines. Each function might have a sequence, but overall these are typically relying on the state of the devices they are interfacing with or the higher level Application task to maintain the state. These types should except commands and execute them. They will often be able to do multiple things at onces.

Drivers are used to perform basic functionality and hardware specific logic. These are typically transferable between applications, and are meant to be generic; once you’ve written it once you usually don’t want to do it again. These make for good function blocks.

Sometimes it makes sense for the driver to be a function block in an application task, but ideally they are bundled with other drives of the same type in a separate task. Drivers often have more stringent timing requirements than the Application or process task that control them.

One of the goals of a well defined driver is to abstract the hardware so that if you change the medium (servo/stepper, serial/ethernet), your application code won’t know the difference.

Some examples of drivers are:

  • Valve controls
  • PWM outputs
  • Temperature Controlers
  • Axis Managers
  • Dual Motor Controllers
  • General File IO
  • Serial Communication

Drivers typically DO NOT need to know about the state of the machine. Some drives may interface with Piper to the extent that they must finish initialization for the system can fully boot. A driver like an Axis manager may interface with Piper and Power on/off during piper resetting/aborting.

Application Tasks

Application Tasks are a mid level set of functions. These are usually somewhat transferable. They perform typical medium level operations, such as preparing gantry axes by gearing them in on power up. These usually make more sense as tasks as opposed to Function blocks. They are more application specific than drivers. Where drivers tend to be given parameters and commands, application tasks may configure drivers and themselves, have specific mapping to hardware such as axes or interfaces. These tasks take generic drivers and “Apply” them to a specific application.

Application Tasks are typically the parts of the machine that just have to work. They are not usually strongly related to the core process. They are preparing the machine for the process or the systems that enable the process.

This type of task is a bridge between the low level driver and the actual process. There are cases where the application task may take the place of a process task, and no more specialization is required.

Some examples of Application Tasks might include:

  • Recipe managers
  • Gantry controllers
  • Cam controllers
  • Conveyor systems
  • Spindles

Application tasks are often controlled by Piper state transitions and are closely tied to the machine state and mode.

Conveyor example:

Take a conveyor system. A conveyor may be made up of a motor that has 3 drive options: servo drive on Powerlink, a VFD using CANOpen or a VFD driven with digital IO. It needs to turn turn on while the machine is operational and stop if there is hold command from downstream or when the operator stops the process.

In this system you would likely have 3 drivers, one for each drive type, and one application task. 

The drivers check if they are enabled and let piper know when they are finished initializing or they are disabled. They listen for start stop commands and accept a speed command.

The application task might decide which driver to use based on the machine configuration. It would take input from a recipe or user to set the speed of the drive. It would also integrate with piper. 

It would implement the following responses to piper: 
- Resetting -> by powering on
- Aborting -> stop then power off
- Starting or unholding -> Start the conveyor
- Stopping or holding -> stop the conveyor

If the conveyor has an error it will trigger a piper Abort to stop the process.

Process Tasks

Process Tasks are typically related to the core technology of the machine. This is what the machine does. Ideally, a machine builder spends most of their time here. Process tasks tie together the application tasks to achieve an end product. These are usually sequences that have a specific order or recipe that must be performed. Typically anything that is a process task would run when the machine is in the PackML Execute state.

In a typical CNC machine, the drivers and application tasks do the work to get the machine from bootup to execute, then the process task (CNC Kernel in this case) takes over. The application tasks and drivers respond to request from the process task for work to be done. In a CNC machine this may be through M-Flags, built-in processes or many other mechanisms.

In a system without a CNC kernel, or where the CNC kernel is more like a component, a (or many) process tasks can act as a sequencer. If the drivers and application tasks have been well designed, the process task should not need to know much about how to do the operations, or details about checking the states of subsystems. It should know the order of things to do and have a clear, concise way to command an action and check when it is done.