Exception handling

What is a floating point exception?

A floating point exception occurs when an arithmetically not exactly executable operation is instructed in the floating point unit of the CPU. IEEE 754 defines these cases: inexact, underflow, overflow, divide-by-zero, invalid-operation. If one of these cases occurs, a status flag is set, which indicates that the arithmetic operation cannot be executed exactly. It is further defined that each arithmetic operation must return a result – one that in the majority of cases leads to the possibility of ignoring the exception.

For example, a division by zero results in +inf or -inf. If a value is divided by inf in the further code, this results in zero, so that no consequential problems are to be expected. However, if inf is multiplied or other arithmetic operations are performed with inf, these are invalid operations, whose result is represented as a Not-a-Number (NaN).

How does the TwinCAT Runtime react in case of exceptions?

TwinCAT C++ Debugger not active The following explanations only apply if the C++ debugger is not activated on the TwinCAT runtime system. When the C++ debugger is enabled, exceptions are caught by the debugger and can be handled, see Debugging.

Default behavior

Default setting in TwinCAT is that at "divide-by-zero" and "invalid-operation" the execution of the program is stopped and TwinCAT issues an error message.

Task setting: Floating Point Exceptions

This default setting can be changed on the level of each TwinCAT task. If the checkbox "Floating Point Exception" is unchecked, an exception does not lead to a TwinCAT stop and no error message is issued. This setting is then valid for all objects that are called by this task. As a consequence, care must be taken in the application that NaN and inf values are handled accordingly in the program code.

Check for NaN and Inf

If, for example, a NaN is passed on via mapping to a TwinCAT object that has activated floating point exceptions, an arithmetic operation with NaN naturally leads to an exception in this object and subsequently to a TwinCAT stop. Therefore, NaN or inf must be checked directly after mapping. In the PLC, corresponding functions are available in the Tc2_Utilities library, e.g. LrealIsNaN.

Try-Catch statement

Another way to handle exceptions is to embed them in a try-catch statement. In the PLC the instructions __TRY, __CATCH, __FINALLY, __ENDTRY are available for this purpose. If floating point exceptions are enabled on the calling task and an exception occurs within the Try-Catch, it is caught in the Catch branch and can be handled. Accordingly, no variables are set to inf or NaN in this approach. However, it is also important to note that the code in the Try branch is run through only up to the point of the exception and then a jump is made to the Catch branch. In the application code, it should be noted that internal states in the Try branch may not be consistent.

Dump Files

From TwinCAT 3.1.4024.22 (XAR), dump files can be created at runtime in case of exceptions in the TcCOM object.

Specification of the behavior in the event of exceptions on object level

In addition to the option to influence behavior in the event of exceptions at task level, the behavior can also be specified at TwinCAT object level, i.e. the generated TcCOM or the generated PLC function block (PLC-FB).

On the object level, a wealth of possibilities can be realized with the TwinCAT Target for Simulink^®. Basically, however, all the options presented below are based on the above principles.

Definition of the object behavior in case of occurring exceptions

A total of 9 different settings are available.

• CallerExceptions (default): Exceptions are triggered as configured at the calling task.
• ThrowExceptions: Exceptions in the TwinCAT object are triggered in any case, regardless of how the task is configured.
• An exception causes a TwinCAT error message and a TwinCAT stop
• SuppressExceptions: Exceptions are not triggered, regardless of how the task is configured.
• An exception does not cause a TwinCAT stop.
• Outputs or internal states can be NaN or inf.
• LogExceptions: Exceptions are triggered, but do not lead to a TwinCAT stop.
• An exception does not cause a TwinCAT stop.
• Outputs or internal states can be NaN or inf.
• The ExecutionInfo output is filled with information about an exception in the current cycle. If several exceptions occur in one cycle, only the first exception is displayed at the output. When the TwinCAT object is called again, the information is reset.
• LogAndHold: Exceptions are triggered. The execution of the TwinCAT object is stopped.
• An exception does not cause a TwinCAT stop.
• Outputs or internal states can be NaN or inf.
• The ExecutionInfo output is filled with information about an exception in the current cycle. If several exceptions occur in one cycle, only the first exception is displayed at the output. When the TwinCAT object is called again, the information is reset.
• The execution of the TwinCAT object is stopped after an exception occurs. TwinCAT itself remains in run mode. Restart execution: ReleaseObjectStop.
• LogAndCatch: Exceptions are caught with try-catch in the TwinCAT object. The execution of the TwinCAT object is stopped.
• An exception does not cause a TwinCAT stop.
• Outputs or internal states cannot contain NaN or inf.
• The ExecutionInfo output is filled with information about an exception in the current cycle.
• The execution of the code ends at the point of the exception. From there, the program jumps to the catch junction, i.e. internal states can be inconsistent.
• The execution of the TwinCAT object is stopped after an exception occurs. TwinCAT itself remains in run mode. Restart execution: ReleaseObjectStop.
• LogAndDump, LogHoldAndDump and LogCatchAndDump
• Behavior like LogExceptions
• Additionally a dump file is stored on the runtime system in the TwinCAT folder Boot. For more on dump files, see here.

Version recommendation for 64-bit target systems When using the "LogExceptions", "LogAndHold", "LogAndDump", LogHoldAndDump" settings, it is recommended to use XAR version of at least 3.1.4024.35 and TE1400 version of at least 2.4.2.0.

<< Setting for TcCOM >>

You can define the behavior of a TcCOM object when exceptions occur under TC TcCOM General in the Code Generation Settings in Simulink^®. The behavior must be defined separately for the initialization phase of the TcCOM and for the runtime phase (update phase).

If you are working with an already compiled TcCOM in TwinCAT, you can also change the settings on the object instance afterwards. To do this, use the Parameters (init) tab and select Show hidden Parameters.

<< Setting for PLC-FB >>

The settings for the PLC-FB (PLC function block FB_<ModelName> in the PLC library) must be made independently of the settings for the TcCOM object at TC PlcFb General. A subsequent adaptation of the exception options when using the function block in TwinCAT is not provided.

Note that the other PLC function block FB_<ModelName>_TcCOM is a wrapper for a TcCOM object and therefore the exception settings from the TcCOM area are valid when it is used.

Optional ExecutionInfo Output

If exceptions are handled at object level, it makes sense to make corresponding information about occurred exceptions accessible at the object output. This output can be used to query whether an exception has occurred, what kind of exception it was, whether a dump file has been written, etc.

<< Setting for TcCOM >>

You can activate an additional "ExecutionInfo" output for the TcCOM object via the TC TcCom Interface entry.

The ExecutionInfo output is a structure with the following entries:

ExecutionInfo structure

TcMgSdk.ExceptionInfo

With the InstructionAddr it is possible to judge if the exception with the given ExceptionCode always occurs at the same place in the source code. If the InstructionAddr is the same for repeating exceptions, it always occurs at the same point in the code. Via ReturnAddr you can see where the calls came from that led to the location of the exception. So you can judge if the call that leads to the exception always takes the same call path. If the code is called from outside the Tmx driver, there is a 0 in ReturnAddr.

If you use the TcCOM Wrapper FB, the ExecutionInfo structure is available at the function block. Note that according to the TwinCAT programming conventions the entries carry prefixes corresponding to the data type.

<< Setting for PLC-FB >>

The PLC-FB always contains nExceptionCount and stActiveException as properties according to the above definition. I.e. no checkbox has to be set separately to get these properties. The only parameter that is not available in comparison to the TcCOM is the cycle count, since this can be implemented very easily in the PLC itself if required.

Handle execution stop of a TwinCAT object

LogAndHold and LogHoldAndDump

In the event of an exception, execution of the code in the TcCOM object or PLC function block (PLC-FB) concerned is stopped by setting the Execute parameter to FALSE.

<< Setting for TcCOM >>

The parameter Execute can be read or written from the XAE and via ADS.

In the XAE, you can display and change the online values of the TcCOM object under Parameters (Init).

In the block diagram the parameter is offered to you under Module parameters.

If you move the mouse over the Execute name in the change dialog, you will be shown the ADS address of the parameter, as with all other parameters. This allows you to set the parameter also by ADS.

By right-clicking on the name Execute you can also save the ADS symbol information to the clipboard. This also applies to all other parameters.

If you use the TcCOM Wrapper FB, you can change the Execute parameter by writing to the bExecute property.

<< Setting for PLC-FB >>

The Execute parameter is available on the FB as property bExecute with read and write rights. Use this property to restart the execution of the FB.

LogAndCatch and LogCatchAndDump

In addition to the parameter Execute, the online parameter Initialized also changes to FALSE in the case of LogAndCatch and LogCatchAndDump. The module must be reinitialized before the module can perform a calculation again. This is necessary because internal states, due to the termination of code execution at the point of the exception, can be inconsistent.

<< Setting for TcCOM >>

Reinitialization can only be performed by returning the TcCOM object to the "Init" state and moving it to OP again. At runtime, only TcCOM objects that have no mappings can be shut down, otherwise active mappings would block the shutdown. A new initialization is only possible in the case of active mappings on the TcCOM by restarting the entire TwinCAT runtime. It is therefore recommended to use the TcCOM Wrapper FB. This can be used to call the TcCOM from the PLC and does not require any mappings to access its inputs and outputs. Accordingly, the TcCOM object can also be reinitialized during runtime.

Property settings for the TcCOM Wrapper FB In the following sample code properties, e.g. bExecute, are read. Create the TcCOM Wrapper FB with TcCom Wrapper FB properties set and with the "CyclicUdate" option for the properties so that the code below matches the wrapper.

PROGRAM MAIN
VAR
   stInitTemp : ST_FB_SimpleTempCtrl_TcCOM_InitStruct := (nOid := 16#01010010);
   fbTempCtr  : FB_SimpleTempCtrl_TcCOM_InitStruct(stInitTemp);
   Inputs     : ST_ExtU_SimpleTempCtrl_T;
   Outputs    : ST_ExtY_SimpleTempCtrl_T;
   ExecutionOut : ST_ExecutionInfo2;
END_VAR

// check if TcCOM is in OP mode and all set 
IF fbTempCtr.bExecute = TRUE AND fbTempCtr.bInitialized = TRUE AND fbTempCtr.nObjectState = TCOM_STATE.TCOM_STATE_OP THEN
    
    // call the module
    fbTempCtr(stSimpleTempCtrl_U := Inputs, stSimpleTempCtrl_Y => Outputs, stExecutionInfo => ExecutionOut);
    
    // handle exceptions
    IF ExecutionOut.ActException.ExceptionCode <> 0 THEN
       // collect exception information
       (* ...... *)
       
       // reinit TcCOM
       fbTempCtr.Reinit(stReInit := stInitTemp); 
    END_IF
    
 END_IF

Note that the ReInit method is executed synchronously, i.e. depending on the cycle time and the time required to reinitialize, cycle overruns may occur.

<< Setting for PLC-FB >>

You can use the property bInitialized on the FB to check whether the stored module is not (no longer) initialized. You have read-only access here. Reinitialization is currently not possible via a method on the FB. The PLC runtime, alternatively the entire TwinCAT runtime, must be restarted.

Dump files

Writing the dump file may take a few cycles. It is best to use a separate task for the TcCOM object or the PLC-FB in question that does not block any important tasks.

Dump files are only written with a TwinCAT XAR version >= 3.1.4024.22, otherwise you get a corresponding warning.

In the case of LogAndDump the execution of the code is continued cyclically after the occurrence of an exception, accordingly exceptions can occur cyclically which could lead to persistent cycle timeouts. Therefore, the online value of the parameter UpdateExceptionHandling is set to LogExceptions after the dump file has been written, i.e. the writing of dump files is deactivated, but can subsequently be switched on again, e.g. by ADS or intervention via the XAE under parameter (Init).

The created dump file is stored on the runtime PC in the boot folder and can be copied from there to another PC for analysis. If you use a TwinCAT version lower than 3.1.4024.x you can open the dump files with WinDbg and start your analysis.