400-878-1895
To report errors please use the following e-mail link:
openSAFETY-bugreport@ixxat.com 
.
To ensure fast error analysis and bug fixing please send us, besides a detailed error description, information about the used version of the openSAFETY stack, the development environment and if available information about the file and the code line where the error was found.
List of known errors:
| No. | Concerns openSAFETY version | Error description | Status |
| 1 | V1.1.1.0 | Restart after SPDO synchronization error Detailed description and bug fix  |
A corrected version of the openSAFETY stack is already in development |
| 2 | V1.1.1.0 | Too small receive buffer when receiving Slim SSDOs Detailed description and bug fix |
A corrected version of the openSAFETY stack is already in development |
1. Restart after SPDO synchronization error
Description:
If the openSAFETY stack reports a SPDO synchronization error (e.g. 0x2822 - SPDO_k_ERR_SCT_TIMER: SPDO_ConsSm():) to the application via SAPL_SERR_SignalErrorClbk(), the values of this SPDO are set to default values (fail safe values).
- If the application doesn't ensure the permanent safe state afterwards and
- the non safe layer transmits autonomously the same valid time synchronization response again and again (data with time response frame) (e.g. always the same openSAFETY Frame after interruption of the non safe communication) and
- the application processes the following time synchronization responses via SPDO_ProcessRxSpdo() and
- the application continues to restart the time synchronization via SPDO_buildTxSPDO(),
then, after an overflow of the CT and for a short time, valid data is forwarded to the application until a new time synchronization error is reported.
Bug fix:
Implementation of a restart lock on application level, this means the application stays in a safe state after a synchronization error or adaptation of the openSAFETY stack (SPDO unit).
2. Too small receive buffer when receiving Slim SSDOs
Description:
At reception of a Slim SSDO Powerlink Safety Frame, it may be the case that the received data is written, besides in the planned receive buffer (s_rxBuf in SSCprocess.c), also in the transmit buffer (s_txBuf in SSCprocess.c). This is caused, at certain configurations which differ from the specification, by a too small Receive Buffer for Slim SSDOs.
No error occurs under the following standard configuration:
- on the SN the define EPLS_cfg_MAX_PYLD_LEN is set to the value 8, and
- on the SCM the define EPLS_cfg_MAX_PYLD_LEN is set to the value 12
For other target systems, in particular configurations which deviate from the specified configuration, and in particular have a high difference of the define EPLS_cfg_MAX_PYLD_LEN between the value for the SN and the value for the SCM, however, an error behavior cannot be excluded.
Solution:
Use of the default configuration of EPLS_cfg_MAX_PYLD_LEN,
for both, the SN and the SCM