1.7 KiB
atMb 0.8 user guide
Execution model
TCP, RTU and slave transport progress synchronously when the owning client or slave FB is called. Keep the related client, request FBs and data arrays in one PLC task and call them every scan. This version intentionally has no native worker thread, CPU-affinity input, or scan watchdog.
The C state machines use nonblocking sockets and fixed storage. Serial driver calls remain target-dependent, and a long PLC task interval can delay transport progress; choose request timeouts accordingly.
Online change
FB_reinit closes the native context before CODESYS replaces IEC instance memory,
then clears handles, active request pointers and registration arrays. Request FBs
clear in-flight state. TCP/RTU clients and slave listeners reopen on a later PLC
scan. Expect active requests to be cancelled and reads to remain stale until a
validated reply arrives. Writes already transmitted are not replayed.
Status and recovery
Client statistics aggregate all registered requests. toString uses
OK:<successful requests>/Er:<failed requests>. Three consecutive failed request
results are required before a request is exposed as offline; a short TCP-to-RTU
converter reconnect therefore does not immediately mark every request offline.
A valid response restores online immediately. Reconnect remains automatic
through the synchronous state machine.
For TCP-to-RTU converters, set ClientTCP.in_baudrate to the converter's
serial baud rate. When no explicit request or client timeout is supplied, the
library estimates timeout from the request/response frame size and baud rate,
then adds turnaround and device-processing margin. Direct TCP clients should
leave in_baudrate at zero and use the normal fixed TCP timeout.