Post by winki on ModbusFB ClientRequest: never recovers after a single ReplyTimeout (requires full download) ^{CODESYS Forge talk (Post)}
Library: ModbusFB (CODESYS Modbus package) IDE / Runtime: CODESYS V3.5 SP___ / Control runtime ___ Target: ___ (e.g. gateway, Linux ARM64 / Debian) Slave: Modbus TCP inverter Summary I poll a Modbus TCP slave with a permanent connection: one ClientTCP (kept connected, xConnect:=TRUE) and one ClientRequestReadHoldingRegisters, triggered cyclically. Everything works fine after a fresh application download. But as soon as one single ReplyTimeout occurs (slave temporarily not answering), the request never recovers. It stays stuck and no further messages are sent, even though the TCP connection is still reported as alive. Only a full application download brings it back — an online change or a runtime reset is not enough / not what I want in production. State observed when stuck So the connection is alive, the request finished in ReplyTimeout, the FB is back to _state = None, but udiNumMsgSent no longer increases — as if a new rising edge on xExecute is no longer accepted / no longer produces a new message. My trigger logic (simplified) Each PLC cycle, in this order: If the request is fully at rest (NOT xExecute AND NOT xBusy AND NOT xDone AND NOT xError) and a read is pending, I set xExecute := TRUE. I call clientTcp() then clientRequest(rClient := clientTcp) once each, per cycle. On xDone or xError, I set xExecute := FALSE. I made sure to insert at least one full cycle with xExecute = FALSE (seen by the FB call) before re-triggering, so the falling edge is processed. Questions After a ReplyTimeout (xError = TRUE), what is the exact, correct sequence to re-trigger the same ClientRequest so a new message is actually sent again? Is a full cycle with xExecute = FALSE between two executions mandatory? Is there a known condition where, after ReplyTimeout, the ClientTCP keeps xConnected = TRUE but silently stops sending new requests (e.g. an internal request queue / _udiRequestId that gets out of sync)? udiNumMsgSent freezing at 23 while the FB shows _state = None is what puzzles me. Is the recommended pattern to drop the connection (ClientTCP.xConnect := FALSE for one cycle, then TRUE) on a request error, rather than keeping it alive? The docs state a request error does not close the connection, so I kept it open — but maybe that is the issue here. Could the large uiStartItem (50514) be relevant? It works right after download, so addressing seems correct, but I want to rule it out. Any guidance on the canonical recovery pattern after a request timeout would be greatly appreciated. Thanks!
Last updated: 2026-06-19

Post by marek71 on Ambiguous use of name - CO136 ^{CODESYS Forge talk (Post)}
My PLC is WAGO PFC200 Firmware Revision 26. target After updating WAGO_Devices_and_Libraries with newer Firmware 27, CODESYS wants to update all libraries to new versions. I will only add that I did not update the Firmware in the PLC. After compiling the program, I received the following errors: ------ Build started: Application: Device.Application ------- Typify code... [ERROR] wagosyscom_internal_pfc, 1.0.2.5 (wago): FbSerialInterface_internal: C0136: Ambiguous use of name 'RTS_IEC_HANDLE' [ERROR] wagosyscom_internal_pfc, 1.0.2.5 (wago): FbSerialInterface_internal: C0136: Ambiguous use of name 'RTS_IEC_RESULT' [ERROR] wagosyscom_internal_pfc, 1.0.2.5 (wago): Initialize [FbSerialInterface_internal]: C0032: Cannot convert type 'Unknown type: 'RTS_INVALID_HANDLE'' to type 'POINTER TO BYTE' [ERROR] wagosyscom_internal_pfc, 1.0.2.5 (wago): Initialize [FbSerialInterface_internal]: C0136: Ambiguous use of name 'RTS_INVALID_HANDLE' [ERROR] wagosyscom_internal_pfc, 1.0.2.5 (wago): Initialize [FbSerialInterface_internal]: C0046: Identifier 'RTS_INVALID_HANDLE' not defined [ERROR] wagosyscom_internal_pfc, 1.0.2.5 (wago): comextra_is_tx_empty: C0136: Ambiguous use of name 'RTS_IEC_HANDLE' [ERROR] wagosyscom_internal_pfc, 1.0.2.5 (wago): comextra_get_line_state: C0136: Ambiguous use of name 'RTS_IEC_HANDLE' [ERROR] wagosyscom_internal_pfc, 1.0.2.5 (wago): comextra_is_line_available: C0136: Ambiguous use of name 'RTS_IEC_HANDLE' [ERROR] wagosyscom_internal_pfc, 1.0.2.5 (wago): COMSW_SET_MODE: C0136: Ambiguous use of name 'RTS_IEC_HANDLE' [ERROR] wagosyscom_internal_pfc, 1.0.2.5 (wago): comextra_set_line_state: C0136: Ambiguous use of name 'RTS_IEC_HANDLE' Compile complete -- 10 errors, 0 warnings Build complete -- 10 errors, 0 warnings : No download possible The problem was caused by the WagoSysPlainMem(WAGO) library in the original version 1.5.3.0 after updating to 1.5.3.1. After returning to version 1.5.3.0, the problems disappeared. Probably the version number of this library is responsible for supporting the appropriate Firmware Revision. Can anyone confirm or deny my suspicions?
Last updated: 2024-07-06

Raspberry Pi to Codesys 2.3 ^{CODESYS Forge talk (Thread)}
Raspberry Pi to Codesys 2.3
Last updated: 2014-01-29

Getting Started With CoDeSys ^{CODESYS Forge talk (Thread)}
Getting Started With CoDeSys
Last updated: 2013-08-06

AWS IoT core CODESYS ^{CODESYS Forge talk (Thread)}
AWS IoT core CODESYS
Last updated: 2023-12-06

AWS IoT core CODESYS ^{CODESYS Forge talk (Thread)}
AWS IoT core CODESYS
Last updated: 2023-12-06

AWS IoT core CODESYS ^{CODESYS Forge talk (Thread)}
AWS IoT core CODESYS
Last updated: 2023-12-06

AWS IoT core CODESYS ^{CODESYS Forge talk (Thread)}
AWS IoT core CODESYS
Last updated: 2023-12-06

AWS IoT core CODESYS ^{CODESYS Forge talk (Thread)}
AWS IoT core CODESYS
Last updated: 2023-12-06

Codesys 2.3 & Peak PCAN ^{CODESYS Forge talk (Thread)}
Codesys 2.3 & Peak PCAN
Last updated: 2024-07-16

SFC Reset Codesys 2.3? ^{CODESYS Forge talk (Thread)}
SFC Reset Codesys 2.3?
Last updated: 2024-11-26

Simulate PLC with CodeSys ^{CODESYS Forge talk (Thread)}
Simulate PLC with CodeSys
Last updated: 2015-09-02

Pragma Pack In CodeSys ^{CODESYS Forge talk (Thread)}
Pragma Pack In CodeSys
Last updated: 2023-06-30

CODESYS SP RTE V2.3 ^{CODESYS Forge talk (Thread)}
CODESYS SP RTE V2.3
Last updated: 2019-07-31

Webinar: CodeMeter secures CODESYS V3.5 ^{CODESYS Forge talk (Thread)}
Webinar: CodeMeter secures CODESYS V3.5
Last updated: 2013-10-08

Code coverage and codesys bugs ^{CODESYS Forge talk (Thread)}
Code coverage and codesys bugs
Last updated: 2011-11-16

Cheapest CoDeSys PLC/smart relay? ^{CODESYS Forge talk (Thread)}
Cheapest CoDeSys PLC/smart relay?
Last updated: 2013-05-07

Codesys Libraries - Creating Your Own ^{CODESYS Forge talk (Thread)}
Codesys Libraries - Creating Your Own
Last updated: 2015-10-07

Missing libray codesys 2.3 ^{CODESYS Forge talk (Thread)}
Missing libray codesys 2.3
Last updated: 2020-06-19

Xsoft Codesys v2.3.9 CFC _ issue ^{CODESYS Forge talk (Thread)}
Xsoft Codesys v2.3.9 CFC _ issue
Last updated: 2012-08-08

C Code implementation in Codesys ^{CODESYS Forge talk (Thread)}
C Code implementation in Codesys
Last updated: 2007-06-22

CodeSys SP Program Download ^{CODESYS Forge talk (Thread)}
CodeSys SP Program Download
Last updated: 2011-09-03

Infinite loop in CoDeSys ^{CODESYS Forge talk (Thread)}
Infinite loop in CoDeSys
Last updated: 2007-05-07

codesys 2.3.9.34 Silent uninstall problem ^{CODESYS Forge talk (Thread)}
codesys 2.3.9.34 Silent uninstall problem
Last updated: 2020-10-23

New Guy Help Codesys 2.3 ^{CODESYS Forge talk (Thread)}
New Guy Help Codesys 2.3
Last updated: 2012-12-14

Sort by relevance or date