[ openSYDE_v1.90r1 ]


See also:

[CAN installation and CoDeSys gateway troubleshooting guide]

[OpenSYDE Quick Start Guide]


Summary of changes:


Encrypt diagnostic protocol communication between client and server devices

Potentially security-critical parts of the openSYDE protocol communication can be encrypted to prevent replay attacks and reverse engineering of transferred data. This requires a target device that supports this new protocol feature. Protocol encryption can be activated/deactivated in the openSYDE GUI's System Update screen. If such configuration is set and exported to a .syde_sup package, such a package can only be handled by the new version of SYDEsup.


Data Logger: Additional Trigger - Improve Handling

Data Logger/Additional Trigger:

- trigger condition: all system data elements can be used now (previously only logging data elements could be used)

- expert view: add data elements selection dialog added

- additional trigger is now available for all logging modes


Data Logger: Add logging trigger condition mode: "On Receive"

Data Logger: New logging trigger condition mode "On Receive" added. In this mode every received signal is logged to file (use case: e.g.: heartbeat detection).


Add support for new device type ESX-4CTTC377

New device ESX-4CT-TC377 is available in the tool box.


Add support for new device type TCG-Nano

New device TCG-Nano is available in the tool box.


Bug fix - COMM Messages: Graphical editing using the Message Layout Viewer could cause issues in certain edge cases.

COMM Messages: Graphical editing using the Message Layout Viewer could cause issues in certain

edge cases. This has now been fixed.


Bug fix - Incompatibility within the openSYDE GUI between v1.81r0 and v1.84r1: big images vanish and dashboard progress bar height changed

Incompatibilities with vanishing images in case of used very big images and problems with changing sizes of dashboard progress bars fixed.


Bug fix - Code generation: Communication buffer size for server does not consider buffer needed for ETH <-> CAN routing

When routing between Ethernet and CAN the routing node needs a buffer to hold a full protocol service before sending on to the target bus. If the target node had datapool elements larger than those of the routing node this could result in that

buffer being too small. So communication with the target node via the routing node would have failed. The buffer size can now be set manually in the code generation settings.