1. SPiiPlus Training Class
Safety and Faults

2. Faults Mechanism
Fault: An abnormal situation detected by the controller related to safety of motion, hardware damage, faulty wiring, EtherCAT errors, limit switch tripped, etc.
Faults and errors are monitored every controller cycle.
The controller has a predefined set of faults and default responses.
All fault responses can be customized by the user

3. Faults Mechanism Example faults: Encoder error due to bad wiring
Drive alarm caused by problem with the power amplifier
Axis limit switch tripped
E-Stop activation
Critical position error caused by a driving axis into a hard stop

4. Some Predefined Axis and System Faults
Axis Faults
Right Limit
Left Limit
Soft Right Limit
Soft Left Limit
Encoder not connected
Encoder error
Drive Alarm
Position Error
Critical Position Error
Velocity Limit
Overcurrent
System Faults
Program error
Memory overuse
Runtime overload
Servo Processor alarm
Servo Interrupt
Emergency stop

5. Axis Fault Variables FAULT FMASK FDEF
Encodes all faults for a certain axis. For example, ON FAULT(1).#ENCNC will activate an autoroutine when axis 1 encoder is disconnected.
FMASK
Masks a defined axis fault. For example, FMASK(0).#RL=0 will mask axis 0 hardware right limit fault.
FDEF
Activates/deactivates default response to axis fault. For example, FDEF(3).#SLL=0 will disable the default response to axis 3 software left limit fault.

6. System Fault Variables
S_FAULT
Aggregates one specific fault for all axes. For example, ON S_FAULT.#LL will activate an autoroutine when any axis passes the left limit.
S_FMASK
Masks a defined system fault. For example, S_FMASK.#ES=0 will mask the Emergency Stop fault.
S_FDEF
Activates/deactivates default response to system fault. For example, S_FDEF.#ES=0 will disable the default response to the Emergency Stop fault.

7. Customized Fault Responses
The user can define a customized fault response that can override/supplement the default fault response by:
Activating the fault FMASK variable
Writing an autoroutine, for example:
! Axis 0 critical position error is being checked
FMASK(0).#CPE = 1
FDEF(0).#CPE = 0
STOP
ON FAULT(0).#CPE; BLOCK ! Run on critical position error
KILL (0,4) ! Kill axis 0 and 4
START 3, User_PE ! Run buffer 3 starting at label User_PE
DISP "Critical position error Axis 0"
END; RET

8. Safety and Faults Configurator
MMI component used for configuration of controller responses to faults
Invert fault signal (if necessary)
Allow detection of fault
Allow default fault response
Red LED indicates a fault

9. Safety and Faults Monitor
Provides immediate monitoring of axis and system faults

10. Default Responses
The controller provides default responses for most faults
A default response can be one of the following:
No response – for indication only.
Kill motion – when the axis is under control
Disable motor – when the controller can’t control the axis
Kill Disable – Kill motion followed by disable

11. Default Responses To view default responses:
In the System Information Viewer, look under “Safety & Fault Response” heading to view predefined fault responses per axis
Alternatively, the terminal command #SC prints the same information to the Communication Terminal

12. Fault Mechanism

13. Fault Mechanism
Example 1 – Axis 0 left limit fault

14. Fault Mechanism
Example 2 – Axis 0 left limit fault

15. Encoder Faults Encoder Not Connected Encoder Error
Quadrature encoders:
Checked by HW to verify continuity between A/A’ and B/B’ on quadrature encoders
Analog Sin-Cos encoders:
Checked by SW using Sin^2 + Cos^2
Encoder Error
Checks encoder logic by the SW (Firmware) to verify legal transfers between A and B signals (00 <=> 01 <=> 11 <=> 10)
Fault
Quad Encoder
Sin-cos Encoder
Encoder not connected 
Encoder Error

16. Hardware Limit Faults
During operation, when the left limit switch is on, the controller detects a left (negative) limit fault.
During operation when the right limit switch is on, the controller detects a right (positive) limit fault.
As a default response, the controller kills the violating motor.
As long as the fault is active, the controller kills any motion toward the limit while motion away from the limit is allowed.

17. Software Limit Faults
The user can define left and right software limits in the Adjuster Wizard:
Unlike hardware limits, the software limit causes the fault before the trajectory passes the software limit position
The controller provides processing so the termination point is very close to software limit – using the KDEC deceleration variable

18. Software Limit Faults
As long as the fault is active, the controller kills any motion toward the limit while motion away from the limit is allowed

19. Velocity and Acceleration Limits
Maximum reference (not feedback) velocity (XVEL) and acceleration (XACC) can be specified for each axis.
Calculated automatically by the Adjuster Wizard based on motor data entered earlier in the Adjuster process
Can be specified by user if necessary

20. Velocity and Acceleration Limits
When the commanded motion exceeds the maximum velocity value, a FAULT.#VL fault is generated.
When the commanded motion exceeds the maximum acceleration value, a FAULT.#AL fault is generated.
Important – the velocity limit (XVEL) parameter affects the servo control loops because it scales velocity feedback. Make sure XVEL is set properly before tuning.

21. Current/Torque Protection
There are three current/torque protection variables defined in terms of percentage of peak drive current:
XRMS – defines maximum allowable RMS current. If violated, an overcurrent fault occurs.
XCURI – defines absolute maximum current when axis is idle. This sets a physical limit on drive output.
XCURV – defines absolute maximum current when axis is in motion. This sets a physical limit on drive output.

22. Current/Torque Protection
Overcurrent protection
The controller provides over-current protection by calculating RMS current
The protection relates to continuous current rating of drive and motor
The Adjuster Wizard automatically calculates current protection parameters based on motor and drive data entered earlier in the Adjuster process
Current protection parameters can be modified by users if necessary

23. Current/Torque Protection

24. Position Error Faults
There are six variables for position error faults
As a default response, the critical position error fault disables the drive
The position error fault has no default response (indication only). The user can define a customized response.

25. Error Mechanism
A four-digit error code is generated after any malfunction during operation.
The controller returns error codes which belong to the following categories:
ACSPL+ Syntax Errors: numbers 1000 to 1999
ASCPL+ Compilation Errors: 2000 to 2999
ACSPL+ Runtime Errors: 3000 to 3999
Motion Termination Errors: 5000 to 5150
System Errors: 5151 to 5999
EtherCAT Errors: 6000 to 6999
Reserved for user-defined error codes: 9000 and above

26. Error Mechanism The meaning of an error code can be determined by
Looking up the error code in section 5 of the ACSPL+ Command and Variable Reference Guide
Querying the error code in the Communication Terminal using double question mark syntax
For example; ??5167 returns “Initialization problem: Number of drive modules does not meet the configuration”
If an error occurs when using the MMI, a pop up window displays the error code along with its meaning.

27. Error Mechanism
MERR is an ACSPL+ standard variable that stores motion termination cause per axis
If axis motion terminates without error, MERR returns 0
If axis motion terminates with error, MERR returns the corresponding 4-digit error code in the range of

28. Error Mechanism
PERR is an ACSPL+ standard variable that stores ACSPL+ error code (progam error) per program buffer
If an ACSPL+ error occurs during program execution, the controller stores the error code in the corresponding element of the PERR array

29. Error Mechanism
In addition to the SPiiPlus error codes, the user can add their own codes in the range of 9000 and above. For example:
ON (RPOS(axis) > 10000) ! Condition for error
KILL (axis), 9123 ! Kill motion citing error code 9123
DISP "Cause of motion termination", MERR(axis);
FCLEAR(axis)! Reset MERR flag of the axis
RET

30. EtherCAT Diagnostics
EtherCAT diagnostic commands allow you to view connected EtherCAT network nodes, operational state, network offsets (variables), errors, etc.
There are three diagnostic commands:
#ETHERCAT – A terminal command showing connected EtherCAT nodes, corresponding states, and variable offsets
ECST – Shows the status of the EtherCAT network. All bits should be on with the possible exception of bit 4 (synchronization bit) if using 3rd party IO.
ECERR – Gives an error code that can be sent to ACS Support for troubleshooting purposes. If zero, no errors exist

31. Example 1
A vision system moves a scanner head along a single linear axis
Safety and faults need to be configured for the axis
If the scanner head moves into the limit, it is important not to remain there due to hazards
Turn off the default response to limits for the axis and define new response so the scanner head does not stay in the limit

32. Example 1
Load Safety and Faults example 1 to an empty buffer, review code, and execute.
If using trainer unit, command motion and manually toggle limit switches
If using simulator, command motion and simulate limit switches by toggling. SAFINI(X).#LL, or SAFINI(X).#RL

33. Example 2
The vision system needs to wait for a signal from the user before it is allowed to continue operation
Modify example 1 so that after moving out of a limit, code execution halts until user sends a signal from the terminal (i.e. user changes the state of a global variable from the terminal)
Use the terminal to notify the user of any safety issues (use DISP to display messages to the Terminal), and prompt for user input when necessary

34. Example 3
For safety purposes it is desired to disable all axes and stop the program if the user does not send a signal for an extended amount of time
Modify example 2 accordingly, define an appropriate user-response timeout length