Spiiplus training class
This presentation is the property of its rightful owner.
Sponsored Links
1 / 25

SPiiPlus Training Class PowerPoint PPT Presentation


  • 159 Views
  • Uploaded on
  • Presentation posted in: General

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

Download Presentation

SPiiPlus Training Class

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Spiiplus training class

SPiiPlus Training Class

Program Structure and Execution


What are acspl programs

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

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 run1

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


How do acspl programs run2

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


How do acspl programs run3

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


How do acspl programs run4

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 run5

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


How do acspl programs run6

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


How do acspl programs begin

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 begin1

How do ACSPL+ Programs Begin?

AUTOEXEC Start


How do acspl programs begin2

How do ACSPL+ Programs Begin?

Internally Generated Start


How do acspl programs begin3

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

}


How do acspl programs end

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 end1

How do ACSPL+ Programs End?

Internally Generated Stop


How do acspl programs end2

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

}


Pause resume acspl programs

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

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 structured1

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

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 programming1

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


Controller driven programming

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 programming1

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 programming2

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

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?


  • Login