Post by danieldiaz on Problem with FB execution ^{CODESYS Forge talk (Post)}
Hello everyone, I've been working on a system which needs an error function, with this purpose I've created a FB programmed in LD, after debugging I run the simulation. It seems that the variable linked to a coil doesn't change the value when the contacts are associated to input variables. When I use internal variables the logic works properly. I don't know if the problem is related to the variables definition or with the logic program. As you can see in the image, I1 and I2 are variables declared on the FB, the rest are input variables. If I force the eStop and Reset signals to TRUE the coil value should change, but it doesn't. However in the second network if I1 is TRUE the coil change to TRUE as it has to be. To sum up, my doubt is why that coil doesn't change its value? I would like someone to shed a light on this. Thanks!
Last updated: 2024-04-02

Post by alexgooi on Modbus writing on value change ^{CODESYS Forge talk (Post)}
Hi Duvan, You could make this in 1 single object (FB), Indeed don't use a function for this beacuse you need some memory to keep the old value. For i := 0 TO 200 BY 1 DO //Check if the value has been changed IF Old_Value[i] <> Value[i] THEN //Set the trigger to TRUE Trigger[i] := TRUE; Old_Value[i] := Value[i]; END_IF END_FOR If you define the Value array as an In_Out and the Trigger as an In_Out you arn't claiming any aditional memory to your system. You ofcourse then need to add some code arround it that does something with the trigger and writes it back to FALSE again. If you want more flexability you also could use pointers instead of using the IN_OUT FOR i := 0 TO 200 BY 1 DO address := address_Input + i * SIZEOF(*Put type here); IF Address^ <> Old_Value[i] THEN Trigger[i] := TRUE; Old_Value[i] := Address^; END_IF END_FOR
Last updated: 2024-04-02

Post by timvh on Toradex and CODESYS and licensing ^{CODESYS Forge talk (Post)}
For the Virtual Control you need to use a "Network license". The Virtual Control has parameters of which one is the reference to the license server. This can be the device itself, but you need to activate the license on the host system (not in the container). For this, CODESYS has a Network License server with WBM (web based management). See for the Network License configuration: https://content.helpme-codesys.com/en/CODESYS%20Control/_rtsl_license_controller_linux.html If it is only for evaluation, I would advise to use a CODESYS (USB) key and activate the license on the key. Then you still have to install the CODESYS Network License server on the host, but you don't have to activate the license as soft license on the device. The benefit is that you can easily move your license to another device when needed. Off course your device must have a free USB port available to be able to do this.
Last updated: 2025-10-20

Post by animesh on SoftPLC (CODESYS Control x86 RTE V3 x64) OPC UA binds only to 127.0.0.1 — Not binding to LAN IP ^{CODESYS Forge talk (Post)}
Hello everyone, I am facing a persistent issue with the OPC UA Server on Advantech Soft PLC with hard realtime for Win64 (V3_5_2010_3) and need help from the community. Device Information Name: Advantech Control x86 RTE V3 x64 Vendor: Advantech Co., Ltd. Categories: PLCs Version: 3.5.20.10 Description: Advantech Soft PLC with hard realtime for Win64 (V3_5_2010_3) Problem Summary The OPC UA Server works perfectly when accessed via: opc.tcp://localhost:4842 opc.tcp://<hostname>:4842</hostname> But it does NOT work when using the LAN IP: opc.tcp://192.168.0.XX:4842 In UAExpert I get: Discovery FindServers on opc.tcp://192.168.0.XX:4842 failed (BadCommunicationError) Port is LISTENING in windows Firewall.. Tried with turning off the firewall completely. System Information Windows 10 x64 Advantech CODESYS RTE Soft-PLC (hard real-time) Network IP: 192.168.0.XX Hostname: WINDOWS-XXXXX Need your Support
Last updated: 2025-11-24

Post by fredashbolt on Dynamically Update JSON Payload ^{CODESYS Forge talk (Post)}
I am trying to generate a JSON payload populated with a value that updates for use with a telemetry system, the payload is to be published by MQTT. I have established the MQTT client and can publish a working JSON payload but I can't get the payload to update as the value (iValue) changes. I am using a timer to trigger the .SetValue function periodically, but the JSON will only give the value as it is when it is first initialized using xFirst IF statement. Any suggestions? Thanks VAR pJsonData : POINTER TO JSON.JSONData := factory.Create(); fb_JBuilder : JSON.JSONBuilder; diRootIndex, diObject1Index : DINT; iValue : INT := 10 ; jsonArrayWriter : JSON.JSONByteArrayWriter; wsJsonData : WSTRING(1000); xFirst : BOOL := TRUE; utf8JsonData : STRING(2000); diTempVal : DINT ; PublishTimer : TON ; END_VAR IF xFirst = TRUE THEN fb_JBuilder ( pJsonData := pJsonData , diRootObj => diRootIndex ) ; diObject1Index := fb_Jbuilder.SetKeyWithObject ( "Device" , diParentIndex := diRootIndex ) ; diTempVal := fb_Jbuilder.SetKeyWithValue ( "Temp" , iValue , diParentIndex := diObject1Index ) ; xFirst := FALSE ; END_IF PublishTimer ( IN := PublishTimer.Q = 0 , PT := T#5S ) ; IF PublishTimer.Q THEN fb_JBuilder.SetValue ( iValue , diTempVal ) ; END_IF jsonArrayWriter( xExecute := PublishTimer.Q , pwData := ADR(wsJsonData), udiSize := SIZEOF(wsJsonData), jsonData := pJsonData^, xAsyncMode := FALSE ) ; JSON.Stu.ConvertUTF16toUTF8( ADR ( wsJsonData ) , ADR ( utf8JsonData ) , SIZEOF ( utf8JsonData ) , bStrictConversion := TRUE ) ;
Last updated: 2026-03-10

Post by meke001 on Visualisierungswerkzeuge ^{CODESYS Forge talk (Post)}
Hallo zusammen, ich habe ein hartnäckiges Problem mit der CODESYS-Visualisierung und hoffe auf eure Expertise. In meinem Projekt wird die Toolbox ("Werkzeuge") für die Visualisierung komplett leer angezeigt, es lassen sich also keine Basis-Elemente wie Rechtecke oder Kreise in die Zeichenfläche ziehen. Mein System: CODESYS V3.5 SP22 Patch 2 (64-bit) Device / Compiler-Version: 3.5.22.20 Das Kuriose:Das eigentliche Projekt läuft absolut einwandfrei. Mein Programmcode lässt sich ohne Probleme übersetzen, die SPS-Logik funktioniert fehlerfrei und auch die Simulation läuft einwandfrei durch. Nur das "Gesicht" des Projekts fehlt. Zwischendurch tauchte in den Meldungen der Fehler auf: Die Bibliothek '#System_VisuElems' konnte nicht aufgelöst werden. Was ich bereits zur Fehlerbehebung versucht habe: Installer-Check: Im CODESYS Installer geprüft, ob das Add-on "CODESYS Visualization" installiert ist (ist vorhanden und aktiv). Profil erzwungen: Im Visualisierungsmanager das Visualisierungsprofil manuell auf die aktuellste Version gesetzt. Gerät aktualisiert: Das Device im Projektbaum per Rechtsklick sauber auf die Version 3.5.22.20 hochgezogen. Clean Build: Mehrfach "Alles bereinigen" ausgeführt und neu übersetzt. Neues Projekt: Selbst wenn ich ein komplett neues Standardprojekt anlege, fehlen die Werkzeuge in der Visualisierung weiterhin. Hat jemand von euch eine Idee, woran das noch liegen könnte? Gibt es unter Windows eventuell einen versteckten Cache-Ordner für die Visualisierungs-Bibliotheken, den man manuell leeren muss? Für jeden Tipp wäre ich sehr dankbar! Viele Grüße
Last updated: 2026-06-15

Post by megasilver on Cannot download program to CR1074 – Version mismatch error ^{CODESYS Forge talk (Post)}
Hello, I am having a problem downloading my application to an ifm CR1074 using CODESYS. When I try to download the program to the controller, I get the following errors: [FATAL ERROR] Version mismatch at: 'KEYBOARD_SET_MAPPING' Requested version: 2.0.0.12 Implemented version: 3.4.0.0 [FATAL ERROR] Version mismatch at: 'SYSCFG_SPLASH_SET_SPLASH_SCREEN_VISIBLE' Requested version: 2.0.0.12 Implemented version: 3.4.0.0 [FATAL ERROR] Version mismatch at: 'SYSTEM_IO_BACKLIGHT_SET_CURRENT_BACKLIGHT_BLOCKING' Requested version: 2.0.0.12 Implemented version: 3.4.0.0 [FATAL ERROR] Version mismatch at: 'SYSTEM_IO_BACKLIGHT_SET_CURRENT_BACKLIGHT' Requested version: 2.0.0.12 Implemented version: 3.4.0.0 [FATAL ERROR] Version mismatch at: 'KEYBOARD_RESET_LEDS_BLOCKING' Requested version: 2.0.0.12 Implemented version: 3.4.0.0 [FATAL ERROR] Version mismatch at: 'KEYBOARD_SET_LED_COLOR' Requested version: 2.0.0.12 Implemented version: 3.4.0.0 [FATAL ERROR] Version mismatch at: 'SYSCFG_DEVINFO_GET_KEYBOARDS_INFO' Requested version: 2.0.0.12 Implemented version: 3.4.0.0 The controller is running an OS version that should be compatible with CODESYS 3.5 SP16, and I am using the latest available ifm/ecomatDisplay package for this OS version. Therefore, I do not think this is simply a CODESYS or OS compatibility issue. It looks like the application expects system functions with version 2.0.0.12, while the controller implements version 3.4.0.0. Could this be caused by an incorrect or outdated library, device description, package installation, or a mismatch between the libraries used in the project and the libraries installed on the CR1074? What would be the correct way to identify which component is requesting version 2.0.0.12 and how can I resolve this version mismatch? Thank you for your help.
Last updated: 2026-08-21

Post by pernockham on Gateway in China - "Gateway not connected" ^{CODESYS Forge talk (Post)}
Some new test. Now I cannot connect from Automation server to my gateway in any way also from my office setup with my unit directly connected to my router by dhcp. I can use the IDE and the tool "Connect Edge Gateway" and successfully connect to my server/link to my Automation server account. However no PLC will respond from Automation server "Network scan". I guess the traffic should be initiated by the gateway towards automation server? Any tips on how I can diagnose my problem? Ports to be opened etc? Thing is that this has been working previously but not now (base system has been updated from debian 12 to debian 13, but I dont know at which point it has stopped working). Setup as before. A "Codesys Control for Linux SL" running on a debian 13 installation. Any help/tips appreciated! Per Update. Found the error. Had a wrong gateway-setting. Which meant the PLC could not reach internet. Checked by "ping google.com" from the PLC.
Last updated: 2026-02-12

Post by risele on Modbus connection via Qronox PCD3 M6893 ^{CODESYS Forge talk (Post)}
You are welcome. Also note, that it's valid only if you modbus-device use same real/float value representation (IEEE 754). That's true for most of systems. But some devices may have other representation, such as integer + position of the decimal point, for example 123.456 is integer = 123456 and position = 3 Also note, that, ones again, depending on endianess of each system, you may also need to swap not just words, but bytes. TYPE u_Real : UNION rVal:REAL; wVal:ARRAY[0..1] OF WORD; bVal:ARRAY[0..3] OF BYTE; dwVAL:DWORD; //same as previous, may be easier to specify the MB register END_UNION END_TYPE than swapping may be something as VAR A,B,C,D:BYTE; //Bytes of the real value uIn, uOut:u_Real; rVal:REAL; ModbusReg1,ModbusReg2:WORD; END_VAR uIn.rVal:=rVal; uOut.A:=uIn.D; uOut.B:=uIn.C; uOut.C:=uIn.B; uOut.D:=uIn.A; ModbusReg1:=uOut.wVal[0]; ModbusReg1:=uOut.wVal[2]; Or you even need to reorder bits... Ones again, sending float/real values is not defined by Modbus protocol itself, so it is hardware- and software-dependent. The Modbus Poll (and most of modbus tools) have configuration parameters that will properly swap bytes on their side. Ones again, that's very helpful: https://www.scadacore.com/tools/programming-calculators/online-hex-converter/
Last updated: 2026-02-19

Post by wiekon on OPC UA Probleme ^{CODESYS Forge talk (Post)}
Hallo zusammen, ich hoffe, ihr könnt mir helfen. Eigentlich möchte ich etwas ganz einfaches erreichen: CODESYS Runtime auf Raspberry Pi (OPC UA Client über Datasources Manager) <--> Cognex Designer (OPC UA Server) auf Windows PC Es will einfach nicht klappen. Wenn ich die Datenquelle hinzufüge, Adresse opc.tcp://192.168.150.10:4840 kommt immer BadRequestTimeout. Es ist keine Security und keine Authentication auf dem Server eingerichtet. Auf dem gleichen Raspberry klappt es aber wunderbar mit dem Tool opcua-client! Das heißt für micht, es ist kein Raspberry oder Firewall Thema. Was auch geht: Diese CODESYS Runtime auf dem Raspberry ist OPC UA Server (einfach über die Symbolkonfiguration) und eine andere CODESYS Runtime (ControlWin auf meinem Rechner) ist Client und verbindet sich über den DatasourceManager. Allerdings: Die Daten kommen im Client nur im 1s Takt an, obwohl die Aktualisierungsrate auf 10 ms eingstellt ist und sowohl Server, als auch die DatasourcesTask im Client auf 10 ms laufen. Ich kann einstellen, was ich will, es bleibt bei exakt 1 Sekunde Aktualisierungszeit im Client. Warum ist das so? Wenn ich auf dem gleichen Windows PC, auf dem die ControlWin läuft den UaExpert verwende und mich zum Raspberry verbinde, kriege ich die Daten im 10 ms Raster! Am Server liegts also nicht! Zurück zu meiner eigentlichen Aufgabe: Ich konnte mir vorübergehend so behelfen, dass ich auf dem gleichen Raspberry einen IO-Broker laufen lasse, der zwei Instanzen des OPC UA Clients hat. Er verbindet sich mit dem OPC UA Server des Raspberry und des Cognex Designers (also die zweite Instanz auf dem Raspberry, die es schafft, sich mit dem zu verbinden, nur Codesys schafft es nicht). Der IO Broker ist also das Bindeglied zwischen beiden OPC UA Servern. Über Javascript kopiere ich bei Wertänderung die Daten vom einen Server auf den anderen. Das ganze Funktioniert tadellos, nur die Performance ist nicht so toll, wobei ich mir nach der Erfahrung mit den zwei Codesys Instanzen nicht sicher bin, ob es nicht an Codesys liegt und der IO Broker nichts dafür kann. Ich komme mit dem Thema einfach nicht weiter. Könnt ihr mir Tipps geben? Am liebsten wäre mir natürlich der direkte Weg: Cognex Designer als Server --> Codesys als Client Aber zur Not wäre auch der IO Broker ein gangbarer Weg, allerdings muss die Performance stimmen. Gibt es noch weitere Wege? Ich danke euch für eure kreativen Ideen und Lösungsvorschläge!
Last updated: 2024-11-29

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 bbm1995 on Camera RTSP Feed ^{CODESYS Forge talk (Post)}
Hi dgrard, I had the same issue for a long time, but on a WAGO webvisu. Now I'm glad that I can share my solution. I don't know if you are trying to use the webvisu or the target visu, but this works on webvisu: Get "go2rtc" and set it up according to the documentation. I'm running the Windows binary. Here's my example of the go2rtc.yaml config file (contains working example streams): api: listen: ":1984" # default ":1984", HTTP API port ("" - disabled) origin: "*" # default "", allow CORS requests (only * supported) static_dir: "www" # default "", folder for static files (custom web interface) tls_listen: ":443" # default "", enable HTTPS server tls_cert: "./SSL/fullchain.pem" tls_key: "./SSL/privatekey.pem" streams: # Streams with multiple links will fall back on the next link. ABUS TVIP48511: - rtsp://<username>:<password>@<hostname>:<port>/ch1/main - rtsp://<username>:<password>@<hostname>:<port>/ch1/sub # Diagnostic connections Kirchhoff Institute for Physics - Germany: http://pendelcam.kip.uni-heidelberg.de/mjpg/video.mjpg Blanton Bottling, Kentucky - USA: http://camera.buffalotrace.com/mjpg/video.mjpg Tokyo - Japan: http://61.211.241.239/nphMotionJpeg?Resolution=320x240&Quality=Standard Tampere Hacklab - Finland: http://tamperehacklab.tunk.org:38001/nphMotionJpeg?Resolution=640x480&Quality=Clarity Soltorget Pajala - Sweden: http://195.196.36.242/mjpg/video.mjpg Kaiskuru Skistadion - Norway: http://77.222.181.11:8080/mjpg/video.mjpg webrtc: listen: ":8555" #ice_servers: # - urls: [ "stun:localhost:3478" ] # username: "" # credential: "" Access the webinterface of go2rtc and get the link of your stream. Use the link as for your browser frame in the visualization. Depending on your device, you need to be able to access the file /etc/lighttpd/lighttpd.conf or /etc/lighttpd/webvisu.conf and change the contents similar to this one, otherwise you'll get CORS and CSP errors in the browser and you won't be able to view the stream on the webvisu: # Webvisu specific settings $SERVER["socket"] =~ port_webvisu_used_any { url.redirect += ( "^/webvisu/?$" => "/webvisu/webvisu.htm" ) $HTTP["url"] =~ "^/webvisu/?" { var.response_header_policy_webvisu = ( # CSP for WebVisu, allowing inline sources. "Content-Security-Policy" => "default-src 'self' 'unsafe-inline'; media-src *; frame-src *", # CORS for WebVisu, allowing any origin to access. "Access-Control-Allow-Origin" => "*", # Tell older browsers that this page can only be displayed if all ancestor # frames are same origin to the page itself. "X-Frame-Options" => "SAMEORIGIN" ) # Response header policy for WebVisu setenv.set-response-header = var.response_header_policy_webvisu setenv.set-response-header += var.response_header_policy_common }
Last updated: 2023-11-14

Post by jonasz on Device diagnosis ( EtherCAT IO card ) ^{CODESYS Forge talk (Post)}
Hi, I'll link to the topic not wanting to start a new one. In the application I am building, I wanted to use the diagnostics described in the CAA Device Diagnosis library. In principle, everything is ok, except for the elements related to ModbusTCP. Despite the fact that ModbusTCP is taken into account in the documentation, it is not recognised via the interfaces. FUNCTION_BLOCK NET_HW_DIAG VAR_INPUT END_VAR VAR_OUTPUT END_VAR VAR (* Referencja do struktury z danymi dla HMI ASTRAADA.*) Visu: REFERENCE TO VISU; (* Wskaźnik na mastera EtherCAT.*) pEtherCATMaster : POINTER TO IoDrvEtherCAT; (* Wskaźnik na slave EtherCAT.*) pEtherCATSlave : POINTER TO EtcSlave; (* Interfejs dla węzła w drzewie urządzeń.*) _itfNode: DED.INode; (* Ogólny interfejs magistrali. Zapewnia podstawowe informacje o magistrali polowej.*) _itfBus: DED.IBus; (* Interfejs urządzenia. Zapewnia rozszerzone informacje o urządzeniu (magistralowym).*) _itfDevice2: DED.IDevice2; (* Ogólny interfejs magistrali. Zapewnia podstawowe informacje o magistrali polowej.*) _itfStack: DED.IStack; (* Numer węzła w drzewie urządzeń.*) uiNodes: UINT; (* Operator jest rozszerzeniem normy IEC 61131-3. W czasie wykonywania operator wykonuje konwersję typu odwołania do interfejsu na inny typ. Operator zwraca wynik BOOL. Wartość TRUE oznacza, że CODESYS pomyślnie wykonał konwersję. *) xQueryResultBus: BOOL; xQueryResultDevice2: BOOL; xQueryResultStack: BOOL; (* Struktura danych dotyczących węzłów w drzewie urządzeń.*) NetHwDiag: NW_HW_STAT; ModbusTcpClientDeviceInfo: IoDrvModbusTCP.DED.DEVICE_INFO; ModbusTcpClientDeviceState: IoDrvModbusTCP.DED.DEVICE_STATE; ModbusTcpDeviceInfo: IoDrvModbusTCP.DED.DEVICE_INFO; ModbusTcpDeviceState: IoDrvModbusTCP.DED.DEVICE_STATE; END_VAR (* Pobranie wskaźników dla pierwszego mastera i pierwszego slave w sieci EtherCAT.*) pEtherCATMaster := g_pFirstMaster; pEtherCATSlave := pEtherCATMaster^.FirstSlave; (* Diagnostyka sieci EtherCAT.*) pEtherCATMaster := g_pFirstMaster; pEtherCATSlave := pEtherCATMaster^.FirstSlave; NetHwDiag.xConfigFinished := pEtherCATMaster^.xConfigFinished; NetHwDiag.xDistributedClockInSync := pEtherCATMaster^.xDistributedClockInSync; NetHwDiag.xError := pEtherCATMaster^.xError; NetHwDiag.xSyncInWindow := pEtherCATMaster^.xSyncInWindow; NetHwDiag.sLastMessage := pEtherCATMaster^.LastMessage; NetHwDiag.LastError := pEtherCATMaster^.LastError; (* Diagnostyka drzewa urządzeń.*) uiNodes := 0; _itfNode := DED.GetRoot(); REPEAT NetHwDiag.asDeviceName[uiNodes] := DED.GetDeviceNameString(itfNode := _itfNode); xQueryResultBus := __QUERYINTERFACE(_itfNode,_itfBus); IF xQueryResultBus THEN _itfBus.GetBusInfo(buiInfo := NetHwDiag.aBusInfo[uiNodes]); NetHwDiag.aBusState[uiNodes] := _itfBus.GetBusState(); END_IF xQueryResultDevice2 := __QUERYINTERFACE(_itfNode,_itfDevice2); IF xQueryResultDevice2 THEN _itfDevice2.GetDeviceInfo(deiInfo := NetHwDiag.aDeviceInfo[uiNodes]); NetHwDiag.aDeviceState[uiNodes] := _itfDevice2.GetDeviceState(); IF pEtherCATSlave <>0 THEN pEtherCATSlave^(); IF pEtherCATSlave^.SlaveAddr = NetHwDiag.aDeviceInfo[uiNodes].idSystem THEN NetHwDiag.aAlStatus[uiNodes] := pEtherCATSlave^.ALStatus; pEtherCATSlave := pEtherCATSlave^.NextInstance; END_IF END_IF ELSE xQueryResultStack := __QUERYINTERFACE(_itfNode,_itfStack); IF xQueryResultStack THEN _itfStack.GetDeviceInfo(deiInfo := NetHwDiag.aDeviceInfo[uiNodes]); NetHwDiag.aDeviceState[uiNodes] := _itfStack.GetDeviceState(); END_IF END_IF uiNodes := uiNodes + 1; _itfNode := DED.GetNextNode(_itfNode); UNTIL _itfNode = 0 END_REPEAT (* Diagnostyka Modbus.*) Modbus_TCP_Client.GetDeviceInfo(deiInfo := ModbusTcpClientDeviceInfo); ModbusTcpClientDeviceState := Modbus_TCP_Client.GetDeviceState(); PAC_3200T.GetDeviceInfo(deiInfo := ModbusTcpDeviceInfo); ModbusTcpDeviceState := PAC_3200T.GetDeviceState(); Of course, you can take the easy way out and refer directly to the devices, but I wanted a reusable component. Any constructive help is very welcome Best regards Jonasz
Last updated: 2025-07-15

Post by jackbrady on Function Blocks and arrays of function blocks ^{CODESYS Forge talk (Post)}
Hello, I am new to Codesys and PLC programming in general (please go easy ha!) I'm not looking for code to be written for me just some help and pointing in the right direction. I am writing some code to send commands to a relay based on input values (to put it simply). Quite basic stuff. I have wrote a function block that takes a global variable (Open_command:BOOL) and outputs to another global variable (Opened : BOOL). The function block is simulating a device so I'll eventually get the globals from that. I now need to create multiple versions of this function block/ device (lets say 100) but I need each iteration of that function block to reference it's own relevant global variable. I think that the best way of doing this would be to use arrays, although I could be wrong. I am aware that for up to 100 instances I could very well manually assign everything but that seems rather time consuming and I want a fancier way of doing it. Here is a very basic example of what I am looking to do, please note I have not written this in proper code it's just to show what I mean. Global Variables V[0-100] int Open_command [0-100] Bool Opened [0-100] Bool Function Block var input x : BOOL Var output y : BOOL if x then y = TRUE ELSE y = FALSE The input to my function block will be Open_command, output will be Opened Example code. If V[x] > 10 then Open_command [x] = TRUE ELSE Open_command [x] = FALSE (So when V1 goes above 10 I need Open_command1 = TRUE therefore initiating FB1 output. V2 > 10, open_command2 = True > FB2 output V3 > 10, open_command3 = True > FB3 output ... ... ) What I can't seem to figure out is how to tie all this together, I have read through the codesys documentation and if anything it has confused me more! ha. Apologies for the poorly written post but hopefully you understand what I am trying to get at. Thanks, Jack
Last updated: 2024-02-14

Post by pra83 on CODESYS SoftRedundancy — Both PLCs stay standalone after network interruption — Auto recovery not working ^{CODESYS Forge talk (Post)}
Hello, We are facing a critical issue with CODESYS SoftRedundancy that we have been unable to resolve despite extensive troubleshooting. HARDWARE: 2× HP EliteDesk 800 G9 SFF Intel Core i7-14700 (20 cores) 16GB RAM, 512GB NVMe SSD Windows 11 IoT Enterprise LTSC 2024 NIC1: Built-in Intel GbE NIC2: Intel I210-T1 PCIe (NIC team) SOFTWARE: CODESYS Control Win V3 - x64 Version 3.5.22.10 CODESYS SoftRedundancy SL Server 1 IP: 172.10.10.101 (PLC1 — Active) Server 2 IP: 172.10.10.102 (PLC2 — Standby) CURRENT CODESYSControl.cfg: [CmpRedundancy] BootupWaitTime=120000 StandbyWaitTime=12100 SynchronousTimeout=12100 [CmpSchedule] ProcessorLoad.Maximum=80 WatchdogTime=12000 WatchdogTimeoutAction=0 CONFIRMED WORKING: PLC1/PLC2 identification configured via IDE Connection IP configured via IDE AutoSync enabled and written via IDE Normal Active/Standby operation working Server 2 auto-promotes when Server 1 completely fails PROBLEM DESCRIPTION: When NIC1 cable is removed from Server 1 — both servers go to standalone mode. When NIC1 cable is reconnected — both servers remain in standalone indefinitely. Neither server auto-recovers to Active/Standby without manual CODESYS service restart. AutoSync fires (!!! Autosync !!! visible in log) but recovery does not complete. Tested with direct cable (no NIC team) — same result. Confirmed not a hardware or NIC teaming issue. KEY LOG MESSAGES: "Timeout: No sync message RMSG_StartCycle (5) from master: Standalone" "Socket on other side closed gracefully 0" "Standby PLC: Open acyclic work socket failed" "Connection broke after 11806ms. Check BootupWaitTime." Autosync(fires but does not complete recovery) PCAP ANALYSIS (Wireshark): CODESYS sync stops completely at T+3s Server 1 sends TCP FIN on ports 1206 and 1208 at T+5s No CODESYS redundancy traffic for remaining 24 seconds Both servers stay standalone indefinitely WHAT WE HAVE TRIED: StandbyWaitTime = 12100ms SynchronousTimeout = 12100ms WatchdogTime = 12000ms (less than StandbyWaitTime) AutoSync enabled NIC2 set as Standby adapter Disabled Windows Network Discovery Direct cable test — rules out NIC hardware QUESTION: Per official CODESYS documentation: "No automatic Reconnect is included in the functional scope of the redundancy components. You can program the triggering of a reconnect." Is RDCY.Synchronize() the correct function to add to our application for automatic recovery after both PLCs go standalone? What is preventing auto-recovery when AutoSync is enabled and PlcIdent is correctly set? Thank you for your support.
Last updated: 2026-05-02

Post by mozed on Connection to device closed ^{CODESYS Forge talk (Post)}
Hello I am using an OpusA3 with version 3.5 SP17 Patch 3 as part of a project. I had no real problem before I encountered a problem that blocked me. The detection of the OpusA3 from Codesys is done correctly. The gateway is well configured and if I ping the gateway or the OpusA3 I receive the response correctly. The problem is that when I try to connect, the Opus screen freezes and a few moments later Codesys displays an error message ("connection to device closed"). I tried to change PC, to update the runtime, to change OpusA3 but the problem remains the same. I'm a little lost knowing that before it worked without problem. I went back to a previous version of the project (where it worked correctly) but the message still appears. Do you have any clues to solve the problem? Sincerely,
Last updated: 2023-08-23

Post by alimans on Hex string ^{CODESYS Forge talk (Post)}
Hi kdkwhite, for Word you still can use suggested code by using a union structure and crack down your Word to two byte as bellow: TYPE CrackWordToByte : UNION InWord : WORD; OutBytes : ARRAY [0..1] OF BYTE; END_UNION END_TYPE then define your variable as this type: udInput : CrackWordToByte; now assign your Word variable input to InWord and send OutBytes[x] to the mentioned method: udInput.InWord := WordVariableInput; Input := udInput.OutBytes[x]; Regarding your question about the code: actually 48 is ascii code of "0" and while 65 is the ascii code of "A" so in above code 55 + 10 would be 65.
Last updated: 2023-09-20

Post by andrej on Threads and TID created by CODESYSControl Win V3 ^{CODESYS Forge talk (Post)}
Hi all, for a deeper understanding of the Codesys RTE - I created a simple application with 3 IEC tasks (Ta,Tb,Tc) each with different priorities, and different cycle times. The application runs on Windows 10 in the Soft PLC CODESYS Control Win V3. If my understanding is correct, the RTE i.e. the Process CodesysControlService should spawn 3 threads (Th_a,Th_b,Th_c) which are executed with the defined cycle times, the priority of the threads should reflect the priority of the task set in the Codesys IDE. Does somebody have an idea, how I could identify the respective threads in Windows? Kind regards Andrej
Last updated: 2023-10-02

Post by janber0206 on Gateway doesn't come online, regarding a working internet connection ^{CODESYS Forge talk (Post)}
Solved (see comment) Setup: Kunbus RevPi Connect+ (a raspberry based PLC) Codesys runtime package: 4.5.0.0 (raspberry, armhf) based on Codesys V3.5.18.20 Edge Gateway: 4.5.0.0 (edgearmhf,armhf) EN: The edge-gateway was added over a year ago to the automation server. I now need to make a few changes to the Codesys software, but the Pi is not showing as online in the Automation Server. Internet connection is established, I have remote access to the Pi via RealVNC. Anyone have an idea how I can solve this? Some screenshots added. DE: Ich muss nun ein paar Änderungen an der Codesys-Software vornehmen, aber der Pi wird im Automation Server nicht als online angezeigt. Die Internetverbindung ist hergestellt, ich habe über RealVNC Fernzugriff auf den Pi. Hat jemand eine Idee, wie ich das Problem lösen kann?
Last updated: 2023-10-26

Post by bahrt on Mapping GPIO and adding GPIO configurations ^{CODESYS Forge talk (Post)}
Hi I am about to configure ALL GPIOs on a Raspberry Pi 3 model B V1.2. It seems that I have limited understanding of why not all the IO’s become available with the corresponding mapped IO’s – the 'dwInUse' contains mapping of the inputs from GPIO0 to GPIO27. But 'dwInputs' are only showing GPIO0 to GPIO8 and GPIO15 as available inputs. These mentioned inputs work fine You will be able to watch the limited mapped IO activity here: https://drive.google.com/file/d/1zz4PBNBfRZBF2YkiJ2VQxw6L9MBVji7R/view?usp=sharing Can you please bring your best idea on why GPIO09 to GPIO14 and GPIO16 to GPIO27 state are zero in the dwInputs register? Thanks in advance. Best regards Andreas Bahrt
Last updated: 2023-11-16

Post by bahrt on Raspberry Pi GPIO mapping ^{CODESYS Forge talk (Post)}
Hi I am about to configure ALL GPIOs on a Raspberry Pi 3 model B V1.2. It seems that I have limited understanding of why not all the IO’s become available with the corresponding mapped IO’s – the 'dwInUse' contains mapping of the inputs from GPIO0 to GPIO27. But 'dwInputs' are only showing GPIO0 to GPIO8 and GPIO15 as available inputs. These mentioned inputs work fine You will be able to watch the limited mapped IO activity here: https://drive.google.com/file/d/1zz4PBNBfRZBF2YkiJ2VQxw6L9MBVji7R/view?usp=sharing Can you please bring your best idea on why GPIO09 to GPIO14 and GPIO16 to GPIO27 state are not active (at a fixed zero state) in the dwInputs register? Thanks in advance. Best regards Andreas Bahrt
Last updated: 2023-11-21

Post by captaincookie on SP19 Runtime Zugriff auf lokales Dateisystem ^{CODESYS Forge talk (Post)}
Hallo, das konkrete Problem konnte ich seither leider nicht lösen, allerdings habe ich mit SP19 Patch 4 einen Workaround gefunden, der zumindest für meine Anwendung funktioniert: Zunächst besteht das Problem nicht für alle Funktionalitäten gleichermaßen. Die Anzeige einer .bmp oder .tiff-Datei im Visu-Elementtyp Bild beispielsweise funktioniert aus dem lokalen Dateisystem. Die Anzeige von .cnc-Dateien in einer Tabelle dagegen nicht. Allerdings funktioniert das wiederum, wenn der Dateipfad in den Ordner der PLC führt, genannt '_cnc'. In der PLC wird dieser Ordner über den Pfad _cnc/ erreicht. Auch lohnt es sich einen Blick in die PLC Config-Datei zu werfen und ggf. Anpassungen vorzunehmen. Einzelne Einträge definieren Zugriffsrechte und ähnliches. Die beschriebene Lösung ist nicht sonderlich schön und es erklärt das Problem nicht. Vielleicht kann das noch jemand anders beantworten.
Last updated: 2023-11-22

Post by eschwellinger on SP19 Runtime Zugriff auf lokales Dateisystem ^{CODESYS Forge talk (Post)}
seit SP19 nur noch im PLcLogic pfad. c:\ProgramData\CODESYS...usw datein schreiben lesen [SysFile] PlaceholderFilePath.1=/tmp, $TMP$ PlaceholderFilePath.2=/media/usb, $USB$ PlaceholderFilePath.2.Volatile=1 Seit der Behebung kann der IEC-Code aus Security-Gründen nur noch auf das Arbeitsverzeichnis PLCLogic zugreifen. Sollte auf Dateien außerhalb dieses Pfades zugegriffen werden müssen, dann können diese per Platzhalter bekannt gemacht werden und sind dann zugreifbar. Darüber hinaus kann weiterhin ForceIecFilePath=0 gesetzt werden, um das bisherige Verhalten wiederherzustellen. Von letzterem raten wir aber dringend ab, da dann der IEC-Code wieder auf das gesamte Filesystem zugreifen kann. Daher sollte beides nur nach einer eingehenden Securitybewertung erfolgen.
Last updated: 2023-11-23

Post by riccardo on Management of a PLC network from a remote station ^{CODESYS Forge talk (Post)}
Goodmorning, I would need to set a control station that can manage a PLC network. In short I need to access to all visu programmed in any PLC of the network (LAN). I was thinking to use a PLC with buttons that call, by mean an IP address, the visu of any PLC. I don't know if it is possible but I saw that there is a RemoteVisuTarget that run CODESYS Control Win V3. Can someone suggest me how to create a remote main control station from a normal PC? Thanks, Riccardo
Last updated: 2023-11-27

Post by drno on Konfigurierte Compilerversion in Installation nicht verfügbar ^{CODESYS Forge talk (Post)}
Hallo, bedingt durch einen Rechnerwechsel musste ich verschiedene Codesys-Versionen wieder neu installieren, bzw. habe mit dem Codesys-Installer beim Setup einer neuen Version Add-ons einer bestehenden Installation importiert. Nun möchte ich ein bestehendes Projekt, welches auf einem Zielgerät mit recht alter Runtime läuft öffnen, dabei kommt der error "C0510: The configured compilerversion '3.5.8.0' is not available in your installation". Auf dem alten Rechner wurde mit CODESYS V3.5 SP18 Patch 4 eben mit der Compilerversion 3.5.8.0 übersetzt, beim Erstellen des Projektarchives geht jedoch der Compiler nicht mit und so kommt es auf dem neuen Rechner mit der Installation V3.5 SP18 Patch 4 zu diesem error. Übersetze ich das Projekt mit dem aktuellen Compiler, kommt eine ganze Latte an Fehlermeldungen. Gibt es eine Möglichkeit die Compilerversion 3.5.8.0 in die Installation 3.5.18.4 zu bekommen? Danke, schöne Grüße
Last updated: 2023-12-01

Sort by relevance or date