SPiiPlus Training Class

1. SPiiPlus Training Class Program Structure and Execution

2. 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

3. 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

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

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

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

7. 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)

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

9. 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) CALLHOME IF (HOMED(0) = 0) ! Not homed, fail GOTO FAIL END WHILE 1 CALL PROCESS1 CALL PROCESS2 END AUTOEXEC: ! Initialize variables VEL(1) = 10; ACC(1) = 100; DEC(1) = 100 JERK(1) = 1000 ENABLE (1) CALLHOME IF (HOMED(1) = 0) ! Not homed, fail GOTO FAIL END WHILE 1 CALL PROCESS1 CALL PROCESS2 END

10. 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

11. How do ACSPL+ Programs Begin? AUTOEXEC Start

12. How do ACSPL+ Programs Begin? Internally Generated Start

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

14. 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

15. How do ACSPL+ Programs End? Internally Generated Stop

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

17. 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)

18. 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.

19. 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

20. 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

21. 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 • Can communicate by sending low-level commands • PLC • Can communicate with controller using Ethernet/IP • Can communicate by sending low-level commands • Other • Can communicate by sending low-level commands

22. 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

23. 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

24. 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.

25. 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 DISPmessages • 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?