Post by imdatatas on TO_STRING operator not working for IMPLICIT ENUM ^{CODESYS Forge talk (Post)}
Hi Everyone, It is a very useful feature to be able to obtain the enum value as a string with the TO_STRING operator by defining {attribute 'to_string'}. However, unfortunately the same function does not work for IMPLICIT ENUMs. I hope that {attribute 'to_string'} behavior can also work for Implicit Enumeration data types in one of the upcoming Codesys versions. https://content.helpme-codesys.com/en/CODESYS%20Development%20System/_cds_pragma_attribute_to_string.html https://content.helpme-codesys.com/en/CODESYS%20Development%20System/_cds_datatype_implicit_enumeration.html Best regards, Imdat
Last updated: 2025-03-27

Post by yannickasselin on Linux ARM64 SL, GPIO Access ^{CODESYS Forge talk (Post)}
A bit of work but maybe possible to make your own driver using "CODESYS Control SL Extension Package". Look at the "ExternalIoDrv" example. It is installed in "C:\Program Files\CODESYS 3.5.20.0\CODESYS\CODESYS Control SL Extension Package" when you install the "CODESYS Control for Linux SL".
Last updated: 2024-05-08

Post by mecmag on gear over gear (2 masters,1 slave) - how to do it? ^{CODESYS Forge talk (Post)}
Hello, i need to create an application that uses 2 masters, with 2 different ratios, and it outputs in one single slave. I explain better: Imagine axis A, B and C. -Axis A is the slave. -Axis B is master of A, with a specific ratio. -Axis C is master of A, with a specific ratio. the result motion from B and C should be executed by A, proportionally in position and ratios from B and C. With standard softmotion libraries (MC_...) it is not possible (i couldn't) because it is allowed only one master with its ratio. I have made a similiar application in past, using MoveOverGear in order to synch gears before engage. Instead this time, i need to do a gear over gear application, using 2 different masters. The position have to be the sum of both masters (considering their ratios). Any clue about how to do it? Or were to find some FB that can do it?
Last updated: 2024-08-16

Post by imdatatas on MC_MoveAbsolute: C0138: No matching 'FB_Init' method found for instantiation of SMC_MoveAbsRelPerformerImpl [ERROR] ^{CODESYS Forge talk (Post)}
Hello everyone, Updating and converting an existing working Codesys Softmotion axis control project to the latest Codesys IDE and Softmotion version always gives the following error message during compilation. " [ERROR] sm3_basic, 4.18.0.0 (codesys): MC_MoveAbsolute: C0138: No matching 'FB_Init' method found for instantiation of SMC_MoveAbsRelPerformerImpl " -- Previously working version: Codesys IDE SP18.50, Softmotion 4.10.0.0 -- Later updated version with the error: Codesys IDE SP21.10, Softmotion 4.18.0.0 Has anyone encountered a similar issue? How can this be resolved? Regards, Imdat
Last updated: 2025-07-24

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

Sort by relevance or date