Exception Handling
Floating point exceptions can occur during runtime when processing a TcCom module in TwinCAT that was generated with the aid of the TE1420. This can happen, for example, when an unexpected value (e.g. initial value) is passed to a function. The handling of such exceptions is described below.
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. |
Standard 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.
Checking 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
As of TwinCAT 3.1.4024.22 (XAR), dump files can be created at runtime in case of exceptions in the TcCOM object.
Definition of the object behavior in case of occurring exceptions
You can define the behavior of a TcCOM object when exceptions occur under the TcCOM>General tab in the Code Generation Settings in Simulink®. You must define the behavior separately for the initialization phase of the TcCOM and for the runtime phase (update phase).

A total of 9 different settings are available.
- CallerExceptions (default): Exceptions are thrown as configured at the calling task.
- ThrowExceptions: Exceptions in the TwinCAT object are thrown 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 thrown, 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 thrown, 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 thrown. 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: . - 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 branch, 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: .
- LogAndDump, LogHoldAndDump and LogCatchAndDump
- Behavior in case of LogExceptions
- Additionally a dump file is stored on the runtime system in the TwinCAT folder Boot. You can see more about dump files here.