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?
MPU
(x86 Processor)
SP 0
(Servo Processor)
SP 1
Generic EtherCAT Slave
Motion Control System
Motor
Encoder
I/O
Ethernet
Serial
ECAT

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

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

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

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

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(int argc, char** argv) {
HANDLE hComm;
int retVal;
char label[] = "Axis0";
char address[] = " ";
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(int argc, char** argv) {
HANDLE hComm;
int retVal;
char address[] = " ";
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
PLC
Can communicate with controller using Ethernet/IP
Other

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 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?