SPiiPlus Training Class Program Structure and Execution

What are ACSPL+ Programs? ACSPL+ programs are independent sequences of instructions written to perform specified tasks on the SPiiPlus line of motion controllers. Up to 64 independent programs can be executed on a single controller Each program is isolated – resides in separate program buffers Programs are fully portable to any SPiiPlus motion controller Programs provide real-time task scheduling for guaranteed determinism

How do ACSPL+ Programs Run? All SPiiPlus motion controllers have a centralized motion processing unit (MPU) that acts as the motion system master. MPU firmware responsible for: EtherCAT Communications Motion Profile Generation Axis Handling / Safety Control Host Communications Execution of ACSPL+ Programs Other Housekeeping

How do ACSPL+ Programs Run? MPU (x86 Processor) SP 0 (Servo Processor) SP 1 Generic EtherCAT Slave Motion Control System Motor Encoder I/O Ethernet Serial ECAT

How do ACSPL+ Programs Run? Firmware Breakdown MPU (x86 Processor) Background Tasks Real-Time Tasks Ethernet Communications Serial Communications File System Management EtherCAT Communications Motion Profile Generation ACSPL+ Execution Axis Handling Other Housekeeping

How do ACSPL+ Programs Run? MPU Interrupt Controller Cycle 0 Controller Cycle 1 MPU Interrupt MPU Interrupt Firmware Cycle: 1 or 2 kHz Real-time Tasks Background Tasks Real-time Tasks Background Tasks SP Tick 0 SP Tick 1 SP Tick 2 SP Tick 3 SP Tick 4 SP Tick 5 SP Tick 6 SP Tick 7 SP Tick 8 SP Tick 9 SP Cycle: 20 kHz Servo Loop Servo Loop Servo Loop Servo Loop Servo Loop Servo Loop Servo Loop Servo Loop Servo Loop Servo Loop

How do ACSPL+ Programs Run? When the firmware handles the ACSPL+ execution, it executes 1 command “block” per controller cycle per running ACSPL+ buffer. Normally, 1 line of code = 1 command “block” Multiple commands can be on a single line (separated by ;) Statements between BLOCK…END control structure are executed as one command “block” Certain commands cannot be executed as a single command block (background tasks, loops, array processing)

How do ACSPL+ Programs Run? Round-Robin Execution: 1 block per buffer per cycle ACSPL+ Execution Buffer 0 Buffer 1 Buffer 2 Buffer 3 Buffer 4 Buffer 5 Buffer 6 Buffer N Buffer 7 Buffer 8 Buffer N-2 Buffer N-1

How do ACSPL+ Programs Run? ACSPL+ Buffer Execution: 1 command “block” per controller cycle Buffer 1 Buffer 0 AUTOEXEC: ! Initialize variables BLOCK VEL(0) = 10 ACC(0) = 100 DEC(0) = 100 JERK(0) = 1000 END ENABLE (0) CALL HOME IF (HOMED(0) = 0) ! Not homed, fail GOTO FAIL WHILE 1 CALL PROCESS1 CALL PROCESS2 VEL(1) = 10; ACC(1) = 100; DEC(1) = 100 JERK(1) = 1000 ENABLE (1) IF (HOMED(1) = 0)

How do ACSPL+ Programs Begin? ACSPL+ Programs have 3 different mechanisms for starting execution: AUTOEXEC statement. Start buffer upon controller reboot Every buffer can have its own AUTOEXEC Only one AUTOEXEC per buffer Internally generated START command Buffer or autoroutine (interrupt) generated START Can be triggered by a logical condition (e.g., a digital input driven on) Externally generated START command Host communications streamed START Can be sent via serial, Ethernet, or MODBUS

How do ACSPL+ Programs Begin? AUTOEXEC Start

How do ACSPL+ Programs Begin? Internally Generated Start

How do ACSPL+ Programs Begin? Externally Generated Start int main(int argc, char** argv) { HANDLE hComm; int retVal; char label[] = "Axis0"; char address[] = "10.0.0.100"; hComm = acsc_OpenCommEthernet(address, ACSC_SOCKET_DGRAM_PORT); retVal = acsc_RunBuffer(hComm, 1, label, NULL); }

How do ACSPL+ Programs End? ACSPL+ Programs have 4 different mechanisms for ending execution: “STOP” command. When a STOP command is executed in the buffer, it stops running Internally generated “STOP (buffer)” command Another Buffer or autoroutine (interrupt) generated STOP command Can be triggered by logical condition Externally generated “STOP (buffer)” command Host communications streamed “STOP (buffer)” Can be sent via serial, Ethernet, or MODBUS Program Error If the program gets a run-time error, the firmware will stop the execution

How do ACSPL+ Programs End? Internally Generated Stop

How do ACSPL+ Programs End? Externally Generated Stop int main(int argc, char** argv) { HANDLE hComm; int retVal; char address[] = "10.0.0.100"; hComm = acsc_OpenCommEthernet(address, ACSC_SOCKET_DGRAM_PORT); retVal = acsc_StopBuffer(hComm, 1, NULL); }

Pause/Resume ACSPL+ Programs? ACSPL+ Programs can be paused and resumed. During normal operation this feature is not commonly used, but it can be helpful for debugging. Pause Internally generated PAUSE command (buffer or autoroutine) Externally generated PAUSE command (host application) Resume Internally generated RESUME command (buffer or autoroutine) Externally generated RESUME command (host application)

How are ACSPL+ Programs Structured? SPiiPlus controllers have a lot of flexibility for how they can be programmed. How each application is setup depends on application needs and programmer preference. We will go through some common paradigms for program structures – you do not have to follow them.

How are ACSPL+ Programs Structured? The biggest distinction in programming approaches is host-driven vs. controller-driven. Host-Driven (host program, HMI, PLC): The host application is in constant communications with the controller and dictates its behavior. Minimal amount of ACSPL+ code is required Non real-time communications behavior should be expected Controller-Driven ACSPL+ code initiates on startup and is responsible for dictating controller behavior Host is not necessary, but can be present for getting diagnostic information and sending high-level commands Real-time behavior

Host-Driven Programming With host-driven applications, the core logic of defining what the controller does occurs in the host. This includes aspects such as: Initializing / homing axes Commanding motion Safety / Fault handling Setting digital / analog outputs Responding to digital / analog inputs Data processing / logging

Host-Driven Programming The exact way the host communicates with the controller depends on the host. Windows-based application Can communicate with controller using C / COM libraries Can communicate by sending low-level commands HMI Can communicate with controller using MODBUS PLC Can communicate with controller using Ethernet/IP Other

Controller-Driven Programming With controller-driven applications, the core logic of defining what the controller does occurs in the controller’s program buffers. This includes aspects such as: Initializing / homing axes Commanding motion Safety / Fault handling Setting digital / analog outputs Responding to digital / analog inputs Data processing / logging

Controller-Driven Programming The exact way the buffers run depends on the application. State Machine With the state machine approach, a single buffer is set as the state machine. It is started on controller boot (AUTOEXEC) and runs in a constant WHILE loop until the controller is turned off. It is responsible for calling other buffers / routines to handle detailed aspects of the control Homing axes Running specific motion profiles Responding to I/O

Controller-Driven Programming Sequential Programming With the sequential programming approach, a buffer will start and go through every step of the process in order, and stop at the end. Buffer can either be started on controller boot, or it may be triggered by some external input If a failure occurs, typical approach is to log it and stop the sequence.

ACSPL+ Programming Example Load program “Programming 03 - ProgStructure.prg” to the controller Should populate buffers 29 and 30 Open communication terminal and set it up to show DISP messages Open watch window and monitor FPOS(0)and FPOS(1) From the communication terminal start buffer 29 at line 1 (“START 29, 1”). Follow the instructions on the screen. When finished with buffer 29, start buffer 30 at line 1 (“START 30, 1”). Follow the instructions on the screen. What happens?