Post by cdutz on Problems connecting to Codesys 4.9.0.0 runtime on my Wago PFC200 ^{CODESYS Forge talk (Post)}
Hi all. I am currently struggling to get my Wago PFC200 running the Codesys Runtime in version 4.9.0.0 working. I am using Codesys V3.5SP19. I updated the PFC200 to the firmware version 04.01.10(23) after having tried the latest version (04.03.03(25) from Wago and not being able to start the runtime. After reading version 23 was needed, I changed to that and at least was able to have it start the codesys runtime. I also installed the "Codesys Control for PFC200 SL 4.9.0.0" plugin for Codesys to install the Codesys runtime in version 4.9.0.0 as well as update the Gateway on the device. While I seem to be able to connect to the gateway on the PLC (the dot is green) and when doing a scan, I do now find my PFC200, which is a huge improvement to before, where with firmware version 25 it just failed to start the runtime and I never found any device when doing a scan. Unfortunately I don't seem to be able to connect to the PLC in codesys. I logged in via SSH and changed the password and I can see that this password is correct as the stuff in the Codesys PFC200 tools tab only works if I use my changed password. And I used those credentials to update the installed Runtime version, which the log claimed to have worked fine. Now whenever I try to connect to the device found in the scan, I get a authentication pop-up with empy device name, device address: 000A. As User I use "root" and as password the password that I changed it to. As a response I just get "Ungültige Benutzerauthentifizierung auf dem Gerät" (Eng. probably something like "Invalid user authentication on the device". What could I be doing wrong? Admittedly I'm a bit lost here :-/ Chris
Last updated: 2023-08-26

Post by mubeta on Some 'pathetic' errors in SoftMotion program ^{CODESYS Forge talk (Post)}
Thank you for your interest. Your answers are in line with what I knew, so at least it comforts me that I did not misinterpret the situation. However, I don't have an exact match as, for this project over the past few days I have: 1) I have gone back to leaving the various FBs of the motion always called, all of them, and in the state machine I use a boolean to activate the various useful Execute. (But in the future I want to go back and try the programming technique with which I wanted to develop this project); 2) For the occasional error: SMC_FB_WASNT_CALLED_DURING_MOTION perhaps it was due to the fact that I had set the Ethercat bus synchronism only at the CAN master level, but not at the level of individual drives. I have now also activated it for the individual drives and it does indeed seem to have been resolved, but having also adopted the programming technique mentioned in point 1), I cannot say whether this was the solution to the problem, or instead the previous point. Is there an error ‘regulator or start not set’ in the device log before the error ‘motion generating FB wasn't called for at least one cycle’? I can't answer that right now. By now the machine is running and I am no longer there, at this one. Also, I seem to remember that the 'fbeFBerror' drive structure (5-element array), does not cycle, BUT ONCE THE 5 EVENTS AFTER SWITCHING ON, IT DOES NOT UPDATE ANYMORE (but that's another issue), so diagnostics were not easy.
Last updated: 2024-07-24

Post by yannickasselin on MQTT QoS 1 & 2 ^{CODESYS Forge talk (Post)}
Hello, After some more tests, here is what I found out. It seems we have to increase the uiKeepAlive and tPingInterval parameters. If I increase the uiKeepAlive value to 60s and the tPingInterval to 30s, then if I disconnect the ethernet cable from Codesys and publish some messages to which Codesys subscribes to and then reconnect within 30s, I will get the messages. If I don't reconnect the cable within 30s (ping interval), the client goes in error with "ACKNOWLEDGE_TIMEOUT". When this happens, it will not automatically reconnect after reconnecting the cable. I have to disable and re-enable the client but I will not get the published messages. I need to do more tests because there are a lot of weird things happening when playing with the ping interval and the keep alive. It is not clear to me what does what. I even ended up not receiving messages anymore, even if I disabled and re-enabled the mqtt client. The client did not give any error. The only way I was able to get messages again was by modifying my client ID. After that, if I try to re-use one of the old client IDs, nothing works (publish, subscribe) and I get a TCP_INIT_ERROR and sometimes a TCP_READ_ERROR. I need more explanation/documentation about these weird behaviors. Maybe it is the way I use it, maybe it is related to the broker (I am using Mosquitto with default parameters). When using a Node-Red client, everything works perfectly. I am trying to achieve the same behavior with Codesys but it seems impossible so far.
Last updated: 2024-10-30

Post by john-robinson on Limiting Memory Access of an Array to Within its Bounds ^{CODESYS Forge talk (Post)}
Recently we had an issue regarding some simple code to calculate a rolling average. The code indexes from zero to 199 to properly store the current input into a circular buffer which then allows us to calculate a rolling average: VAR input_5s : REAL; outs_arr : ARRAY[0..199] OF REAL; i : USINT := 0; END_VAR ___ //this code runs every five seconds, calculating a rolling average outs_arr[i] := input_5s; i := i + 1; output := OSCAT_BASIC.ARRAY_AVG(ADR(outs_arr), SIZEOF(outs_arr)); IF i >= SIZEOF(outs_arr) THEN i := 0; END_IF There is a simple bug in this code where the index will be set to 0 when it has surpassed the length of the array in bytes (800 in this case) rather than larger than the number of reals in the array (200). The solution here is simple, replacing i >= SIZEOF(outs_arr) with i >= SIZEOF(outs_arr)/SIZEOF(outs_arr[0]). In this example when the index increased to 201 and the line outs_arr[201] := input_5s was called, codesys arbitrarily wrote to the address in memory that is where outs_arr[201] would be if the array was that long. I would like to find a way to wrap the codesys array inside of a wrapper class that checks if an input is within the bounds of an array before writing to that value. I know how I would implement that for a specific array, I could create a method or class that takes an input of an array of variable length, ie. ARRAY[*] OF REAL, but I don't know how to make this for any data type. I am wondering if anyone has ever done anything similar to this, or has any better suggestions to ensure that none of the programmers on this application accidentally create code that can arbitrarily write to other locations in memory.
Last updated: 2024-03-05

Post by mariussandu on OPC-UA ^{CODESYS Forge talk (Post)}
Hello, I am experiencing an intermittent OPC UA server issue on CODESYS Control for Raspberry Pi SL 4.21.0.0. Runtime information: codesyscontrol 4.21.0.0 Raspberry Pi 4 Model B Rev 1.1 - 4Gb OPC UA Server: CmpOPCUAServer 3.5.22.x Server IP: 192.168.0.110 OPC UA endpoint: opc.tcp://192.168.0.110:4840 The main OPC UA client is Node-RED running on 192.168.0.111. This has an active subscription with some tags and also some write functions active. The system normally works correctly for a period, but at some time the OPC UA communication stopped. Node-RED started reconnecting continuously but could not reconnect. I also tried connecting using UaExpert, but UaExpert returned: BadTimeout At the same time, the PLC application itself was still running. Before restarting CODESYS, I captured the TCP connections. The OPC UA server was still listening: tcp 11 0 192.168.0.110:4840 0.0.0.0:* LISTEN However, there were many connections from the Node-RED client stuck in CLOSE_WAIT: 192.168.0.110:4840 192.168.0.111:45008 CLOSE_WAIT 192.168.0.110:4840 192.168.0.111:53678 CLOSE_WAIT 192.168.0.110:4840 192.168.0.111:44032 CLOSE_WAIT 192.168.0.110:4840 192.168.0.111:36612 CLOSE_WAIT 192.168.0.110:4840 192.168.0.111:45012 CLOSE_WAIT 192.168.0.110:4840 192.168.0.111:36592 CLOSE_WAIT ... Some of these sockets also had data remaining in Recv-Q, for example: Recv-Q = 61 Recv-Q = 121 There were roughly 15–20 OPC UA connections in CLOSE_WAIT. Restarting only the CODESYS runtime immediately restored OPC UA communication. After restart: LISTEN 0 10 192.168.0.110:4840 and both Node-RED and UaExpert can connect normally again. There are no obvious OPC UA errors during startup or in log. On RPI 2 I had a memory leak regarding OPCUA so I had to upgrade to RPI4. What can I do in this case? Thank you!
Last updated: 2026-08-26

Post by e13740e on Parameterized Property syntax for array element processing ^{CODESYS Forge talk (Post)}
Since parameterized (indexed) properties are not possible, I decided to use architectural approach "Indexing Property Adapter" to achieve the intended goal — avoiding code duplication for validated access to array elements. Essence: Create a Function Block Adapter (FB_PropertyAdapter) that encapsulates the logic for working with a single element of the target array (e.g., with one settings structure). Declare Properties inside the adapter block for accessing each individual field of the data structure. All validation logic is implemented within the Set accessors of these properties. Data Binding via VAR_IN_OUT: The adapter block receives a reference to a specific data element from the global array through its VAR_IN_OUT section, which ensures direct work with the original data without copying. Create an Array of Adapters: In the parent POU (e.g., FB_SettingsManager), an array of these adapter blocks is created — one for each element of the global array that needs to be managed. Initialize Bindings: In a FOR loop, each adapter instance from the array is given a reference to the corresponding data element. Result: This approach allows accessing the data via the index of the adapter array, and then through the property name, which simulates the behavior of an indexed property: MyAdapterArray[Index].MyProperty Thus, the validation and data access logic is written only once inside the adapter block and is then reused multiple times by creating instances of it in an array. This completely solves the problem of code duplication while providing a clean, scalable, and object-oriented architecture compatible with standard CODESYS features. Question closed.
Last updated: 2025-10-19

Post by cfam on Codesys Control for PLCnext (PLC - AXL F 2152) ^{CODESYS Forge talk (Post)}
Good day All I would like to share some information on this site for the Codesys team as well for the future members using Codesys Control for PLCnext if it is allowed. I hope that i Post it in the correct spot. Subject: Codesys, Codesys Control for PLCnext Objective: Using the following Phoenix components to built a PLC Rack and run it on Codesys: Hardware and Software used 1. 2404267, AXC F 2152 - Controller 2. 1088136, AXL F BP SE6 - Module carrier 3. 1088129, AXL SE DO16/1 - Digital module 4. 1337224, AXL SE PD16 GND - Potential distributors 5. 1088127, AXL SE DI16/1 - Digital module 6. 1337223, AXL SE PD16 24V - Potential distributors 7. 1088123, AXL SE AO4 I 4-20 - Analog module 8. 1088134, AXL SE SC-A - Cover 9. Codesys v3.5 SP19 Patch 4 10. Codesys Control for PLCnext V4.10.0.0 Process: Firstly I built the Rack according to the Phoenix Project+ Software tool. Where I rebuilt it onto my test bench . I used the PLCnext Engineer IDE from Phoenix and all Communications where up and running and my PLC program executed successfully. THEN I tried the same PLC Layout with Codesys and Codesys Control for PLCnext. It was not successful and gave me the "Error: Local Bus not Running". I searched the web for answers but was unsuccessful in finding a solution. So I tried to change my configuration and found that the following Modules COULD NOT be recognized by Codesys Control. The result was that the Local Bus Failed to run. 1337224, AXL SE PD16 GND - Potential distributors 1337223, AXL SE PD16 24V - Potential distributors Example 1, Resulted in "Error: Local Bus Not Running": Module carrier slot 1: 1088129, AXL SE DO16/1 - Digital module Module carrier slot 2: 1337224, AXL SE PD16 GND - Potential distributors Module carrier slot 3: 1088127, AXL SE DI16/1 - Digital module Module carrier slot 4: 1337223, AXL SE PD16 24V - Potential distributors Module carrier slot 5: 1088123, AXL SE AO4 I 4-20 - Analog module Module carrier slot 6: 1088134, AXL SE SC-A - Cover Example 2, Result "Successful": Module carrier slot 1: 1088129, AXL SE DO16/1 - Digital module Module carrier slot 2: 1088127, AXL SE DI16/1 - Digital module Module carrier slot 3: 1088123, AXL SE AO4 I 4-20 - Analog module Module carrier slot 4: 1088134, AXL SE SC-A - Cover Module carrier slot 5: 1088134, AXL SE SC-A - Cover Module carrier slot 6: 1088134, AXL SE SC-A - Cover Result: Codesys or Codesys Control for PLCnext, has a PROBLEM to identify the following Modules. 1. AXL SE PD16 24V - Potential distributors 2. AXL SE PD16 GND - Potential distributors Hope that this information could be useful in future. Best regards Jaco Pretorius
Last updated: 2023-12-06

Post by struccc on Wish: CODESYSControl.cfg - again ^{CODESYS Forge talk (Post)}
Before creating this topic, I was browsing the search results for CodesysControl.cfg - many results, and I remember very well, it's a problematic issue for a long time. To summarize: there were many requests for documentation on this file - the most comprehensive reply is: https://forge.codesys.com/forge/talk/Runtime/thread/ebbf851a3d/#eb85 Hi, not really, this is covered by the manual which you get if you use a runtime toolkit which is not free of charge. Maybe we need to extract the config file part from that documentation if that is possible. BR Edwin I am not sure how much is this relevant, since we buy SL License directly from CODESYS... I think it is a reasonable demand, to get documentation on the configuration entries affecting the documented behaviour of the runtime system and it's components The actual reason I bring up this issue again can be read here: https://forge.codesys.com/forge/talk/Runtime/thread/febad3cc40/#0e12 but mostly my frustration about noticing some new, unknown and undocumented entries in my configuration file. Again. And this happens a lot recently. Just some examples: Changes with SysFile - and mandatory use of IEC path Introduction of Mandatory user management File transfer service now disabled by default SysProcess - allowed commands The above mentioned CmpApp parameters... And finally (Regaridng windows install): With the newer versions, the installation directory (together with the configuration file) tends to hide itself to some super silly location under the roaming profile data of local system account. I am not sure if this change was documented somewhere, but was a very unpleasant one. Someone could please explain the reason and the concept of the introduction of this release specific directories (I am sure, there is a good reason) - how to use them properly? - How to re-introduce user configuration (to preserve configuration data between versions)? - How to do version - to version migrations properly? - How to keep old version of runtime available and ready to start with it's original configuration and application? - ... Therefore, the lack a regularly updated description of CodesysControl .cfg , including all the configuration entries, together with their default values for different runtime versions is really a big deficiency.* This should be done for all components storing or just seeking data from this file... (Maybe there is such thing but I failed to find???) It is regularly causing trouble when introducing a new version (together with the long awaited bug fixes and enhancements), what has changed it's default behaviour for security or other practical reasons. I agree this is very important, and it is logical to change the default options: But it must be documented historically, and make it easily available, so we can prepare better for the upgrade of the runtime. Forge talk is a great source, but not very practical for this kind of documentation purposes... Thanks in advance for CODESYS staff 🙏🙏🙏 (Ps.: It would look rather silly, if some members of the user community prepares this documentation on a Forge Wiki page... Or??? Should we?)
Last updated: 2024-11-21

Post by kevinrn on CODESYS Development System V3 installation auf unter Parallells Windows 11auf MAC PRO M1 ARM Prozessor ^{CODESYS Forge talk (Post)}
Hallo, das Thema ist ja etwas offtopic. Aber ich kann gerne mal von meiner Erfahrung berichten: Nachdem ich von 2020 bis 2023 immer einen MacBook Pro mit Intel CPU hatte (i9/32GB) und nun seit Januar 2024 mit dem M3 Max unterwegs bin kann ich Nachfolgendes berichten. Infos zu den Aufgaben, die ich damit erledige: Die Runtime nutze ich nicht auf dem Mac (Wenn ich von Mac rede, dann meine ich damit die Win11 ARM64 Parallels Umgebung) Ich nutze die IDE für Library development und für automatisierungs Tests von CI/CD jobs. Weiterhin öffne ich oft große Projektarchive mit teilweise 160 MB. Erfahrungen zur Installation von CODESYS Versionen: Ich habe einige Versionen installiert, unter anderem, 3.5.14.4, 3.5.17.2, 3.5.16.3, 3.5.18.4 und 3.5.19.6. Ich hatte mit keiner einizgen Installation ein Problem. Die Installation lief immer ohne Probleme durch. Runtimes (Control Win) installiere ich nicht. Ich nutze linux basierte Zielsysteme und bei bedarf eine Windows VM auf einen entfernen Host mit X64. Lokales Gateway läuft ebenso Sonstige Erfahrungen: Ich nutze viele Komponenten Querbeet: Alarming, AC Persistence, Symbol Konfiguration, CFC und ST Editor, externes Packages wie STWeep, Git für Library Entwicklung, Visu, etc. Mit keiner dieser "Komponenten" hatte ich schwierigkeiten oder einen Unterschied zu x64 systemen festgestellt. Man muss aber auch sagen, dass das alles nur ein kleiner Bruchteil ist, was die CODESYS Welt beinhaltet, deshalb sind diese Aussagen auch nur subjektiv aus meinem Erfahrungsbereich. Für das Entwickeln von Libraries sehe ich keine Performance Einschränkungen. Ganz im Gegenteil, für das, dass hier eine emulation stattfindet, ist es erstaunlich schnell. Meiner Meinung nach sind sogar einfache und kleine Projekte schneller als beim Intel Mac. Die Akku Leistung mit dem Mac und Parallels ist fantastisch. Lüfter hört man nicht mal bei der Nutzung von CODESYS. Beim Intel konnte ich sonst ein Spiegelei auf der Abdeckung zubereiten... Was evtl. etwas langsamer ist bzw. mir manchmal so vor kommt ist, der CFC Editor im Online Mode. Aber hierzu fehlt mir ein richtiger Vergleich. Fazit: Ich bin selbst erstaunt wie gut die CODESYS IDE auf einem ARM64 emuliert wird. Ich muss aber auch sagen, dass ich jederzeit eine x64 Workspace zur Verfügung habe, falls was nicht funktionieren sollte. Das habe ich mir extra zum Umstieg zu gelegt. Bisher habe ich es jedoch noch nie benötigt, da meine Anforderungen alle erfüllt werden. Es sollte einem aber bewusst sein, dass dies keine supportete Umgebung ist und man auch bei spezifischen Problemen keinen Support erwarten sollte. Ich nutze CODESYS ca. 4-12 Stunden die Woche und ich warte immer noch auf etwas, um meine X64 Cloud Workspace mal zu verwenden... Vielleicht hilft dir dies ja etwas bei der Entscheidung.
Last updated: 2024-03-21

Post by kevinrn on Github Actions CI/CD tasks - development topic ^{CODESYS Forge talk (Post)}
Hello community, I just want to inform you about our plans and the current status of automating the build process for CODESYS libraries. So it might be helpful for some people who are in the same situation. Background story: I am a software engineer at powerIO GmbH, normally I use high level languages for the products we develop and offer. Sometimes I work with my team on CODESYS libraries, which can also be found in the CODESYS store. Most of the time I spend with them on architecture tasks and tasks that are not directly related to our products. Every time I see the manual processes for releasing a library etc., I am very surprised about this time intensive process. Current situation: I know there has been a scripting interface for years. CODESYS Git was released a few years ago, but the scripting interface was only released a few months (weeks?) ago. We developed a pseudo-automated solution a few months ago, but it was all very hacky. So now there is a better Git implementation and also more modularization and installation options. For example, the CODESYS installer has a full CLI, which makes it very convenient to install CODESYS installations headless. Plans: I think it's the right time to develop a better automation solution. Most of our software projects are hosted on Github and we use Github actions very intensively for other software projects. Therefore, we have decided to use Github for our CODESYS library projects as well. Following tasks should be implemented in automation for CI/CD tasks: - Automated setup of CODESYS installation (Already released: https://github.com/marketplace/actions/setup-codesys-installation) - Checkout CODESYS libraries - Execute tests scripts - Sign CODESYS libraries - Extract Library documentation - Create CODESYS package - Sign CODESYS package Side Note: - This is mainly a side project, and we do not provide support for the CI/CD part. - This topic is here to help and also to get help from other software engineers. - This project and idea is not prioritized as I am currently the only one working on it and I hope it will help us and also others and increase productivity. - We are putting this out there as an organization, but priorities can change quickly and the CI/CD tasks I am developing are mostly done in my spare time. So please don't expect this to happen in a short time or even be fully completed. I would be very happy if some ppl will join the development process and might be open to discuss some technical details for this. I hope this topic is not to off-topic, but I think the CI/CD part is very important today and it can increase a lot of quality and push productivity. Thanks :)
Last updated: 2024-03-28

Post by dantheman on Connecting to SoftPLC Only Works By Turning Off Modbus Ethernet Port ^{CODESYS Forge talk (Post)}
I have an IPC with 2 ethernet ports and 1 Wi-Fi. I'm using ModbusTCP with the ethernet port named "enp2s0" connected to my remote I/O. This works fine when testing with Python and also works with CODESYS, but CODESYS is only able to scan for the Linux SoftPLC when I turn off the "enp2s0" interface. In other words, I can't get online with the IDE if I want my ModbusTCP comms to run with CODESYS. I'm using a Linux SoftPLC that has the following entry in CODESYSControl.cfg, hoping that this will allow me to connect with "enp1s0" or "wlp3s0", and leave "enp2s0" for field comms, but this seems to only make the source IP of the ModbusTCP comms to be bound to "enp2s0". That last point is the case only if I don't restart the service, but if I do restart the service after changing the config file, the source IP for the ModbusTCP comms then becomes the one for "enp1s0", which is very confusing to me: [SysSocket] Adapter.0.Name="enp2s0" Adapter.0.EnableSetIpAndMask=1 On the device list, I only have "enp2s0" given as the ethernet device that has the ModbusTCP master & slave beneath it, shown in Screenshot 1. On the IPC, I can ping the ModbusTCP client (remote I/O) from "enp2s0", and I've attached a Wireshark capture of running ModbusTCP from the CODESYS runtime as Screenshot 2, 3 & 4 (again, I can't get online when this is running, I have to turn off "enp2s0" to connect even when it's idle and I don't have an active TCP session with my Python tests). Like I explained above, the source IP is "enp1s0", even though the ethernet device on the project is "enp2s0". I was lucky to catch the red message that showed the source IP that makes sense to me (the one for "enp2s0"), but for some reason that connection was reset and I never saw that packet again. I've also tried this with Auto-reconnect both enabled & disabled, for the ModbusTCP Master device. I also have to turn off "enp1s0" and then turn it on, just so that I can have the ModbusTCP comms running from "enp2s0" (which is not intuitive in any way to me, I'd love some help understanding that phenomenon as well) in the weird manner that I've described above. I would be very appreciative if someone can help me figure out this pickle. I'd love to just connect to CODESYS through my Wi-Fi interface and leave my ethernet ports for field comms.
Last updated: 2024-08-01

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 madskaizer on Task Priority Documentation? ^{CODESYS Forge talk (Post)}
Hi All I was watching the Wago PFC300 webinar ( https://www.wago.com/global/lp-thank-you-onlineseminar-pfc-300 ), and the presenters comment about priority 1 being way above the Ethernet task priority, so that a priority 1 PLC program can actually loose SCADA connection, made me try to round up some hard evidence on Codesys Priorities. I find there is very little information on "correct" task priority configuration. There is a lot of different hardware manufacturers, using Codesys Runtime, that has different descriptions in their manuals on how to set up priority. https://doku.amk-motion.com/en/Subsystems/PDK_202975_A-Serie_en/Content/Projekt/AMKAMAC/PDK_202975_A4-A5_Produktbeschreibung/Funktionalitaet/PLC-Programming/PLC%20Tasks.htm?TocPath=PLC-Programming%7C_____7 https://product-help.schneider-electric.com/Machine%20Expert/V1.1/en/SoMProg/index.htm?#t=SoMProg%2FTask_Editor%2FTask_Editor-7.htm&rhsearch=priority&rhhlterm=priority&rhsyns=%20&SUBSTRSRCH=1 https://content.helpme-codesys.com/en/CODESYS%20Development%20System/_cds_f_task_configuration.html So my questions :) 1) If there is only 1 PLC_PRG task, does priority matter? 2) What is the priority of Ethernet / communication, if nothing is entered? 3) What is the priority of Codesys OPC UA server? 4) Some users here on forge mentions that Wago PLC programs should run as priority 11, but where does this recommendation origin from? 5) What are you recommendations for a relatively slow process, like building automation? It uses OPC UA for communication to SCADA, maybe some MODBUS-RTU and MODBUS-TCP, usually around 100 I/O, been running with everything in a single task at priority 1, 50-100ms cycle time. Some controllers have separate MODBUS tasks, but doesn't seem like a big difference. How would you recommend splitting up communication, IO fieldbus and programs into differently prioritized tasks? I know its a complex matter and all about my application, but I really miss there was just some kind of guidance in the documentations and with all new standard Codesys programs having priority 1 as default, makes it seem less important, than it really is.
Last updated: 2025-08-11

Post by pppn on Issue with Forward Open Connections in Ethernet/IP Protocol Stack in Codesys ^{CODESYS Forge talk (Post)}
Hello, I am facing an issue with my Ethernet-based project in Codesys. My product was functioning well until I modified the protocol stack and uploaded it to my device. Here are the details of my problem: Project Setup: I am working on an Ethernet-based project to test my product. The project was running without issues before modifying the protocol stack. Issue: After modifying the protocol stack and uploading it to my device, I am encountering an error in Codesys related to the forward open connections. Error status: connection failure, extended: connection in use or duplicate forward open. According to the Ethernet/IP protocol in codesys, there are three forward open connections that need to be established. The first two connections are opening without any issues. The third connection, which is an input-only connection, is causing problems. The error message indicates that the connection is already open. Debugging Attempts: I have extensively debugged the protocol stack and found no issues. The product works well when tested with EIP tools but not with Codesys. Exclusive owner connections are working correctly, and only the input-only connection is problematic. Wireshark Traces: Wireshark traces show that the third connection attempts to open but reports that it is already open. Steps to Reproduce: Modify the protocol stack and upload it to the device. Attempt to establish three forward open connections in Codesys. Observe the error on the third connection (input-only). Request: I would appreciate any suggestions or guidance on how to resolve this issue. If there are specific settings or configurations in Codesys that I need to check, please let me know. Additionally, if there are known issues or workarounds related to this problem, I would be grateful for the information. Attachments: Wireshark traces showing the connection attempts and errors Screenshots of the error messages in Codesys codesys version: CODESYS V3.5 SP16 Patch 3 + 64 bit
Last updated: 2024-06-25

Post by pppn on Issue with Forward Open Connections in Ethernet/IP Protocol Stack in Codesys ^{CODESYS Forge talk (Post)}
Hello, I am facing an issue with my Ethernet-based project in Codesys. My product was functioning well until I modified the protocol stack and uploaded it to my device. Here are the details of my problem: Project Setup: I am working on an Ethernet-based project to test my product. The project was running without issues before modifying the protocol stack. Issue: After modifying the protocol stack and uploading it to my device, I am encountering an error in Codesys related to the forward open connections. Error status: connection failure, extended: connection in use or duplicate forward open. According to the Ethernet/IP protocol, there are three forward open connections that need to be established. The first two connections are opening without any issues. The third connection, which is an input-only connection, is causing problems. The error message indicates that the connection is already open. Debugging Attempts: I have extensively debugged the protocol stack and found no issues. The product works well when tested with EIP tools but not with Codesys. Exclusive owner connections are working correctly, and only the input-only connection is problematic. Wireshark Traces: Wireshark traces show that the third connection attempts to open but reports that it is already open. Steps to Reproduce: Modify the protocol stack and upload it to the device. Attempt to establish three forward open connections in Codesys. Observe the error on the third connection (input-only). Request: I would appreciate any suggestions or guidance on how to resolve this issue. If there are specific settings or configurations in Codesys that I need to check, please let me know. Additionally, if there are known issues or workarounds related to this problem, I would be grateful for the information. Attachments: Wireshark traces showing the connection attempts and errors Screenshots of the error messages in Codesys codesys version: CODESYS V3.5 SP16 Patch 3 + 64 bit
Last updated: 2024-06-25

Post by davidbo on Clean old license into an image SD ^{CODESYS Forge talk (Post)}
That might not be enough using CODESYS V3.5 SP20 and CODESYS Control for Raspberry Pi MC SL version: 4.11 I deleted .cmact_license directory. I installed new license and the dialog box said it was done successfully, but in reality it was not. What more should be deleted 5:/var/opt/codesys$ ls -la total 1948 drwxr-xr-x 10 root root 4096 Nov 17 12:29 . drwxr-xr-x 5 root root 4096 Jul 30 2020 .. -rw-r--r-- 1 root root 100014 Nov 17 12:08 .Audit_0.log -rw-r--r-- 1 root root 100040 Nov 17 11:30 .Audit_1.log -rw-r--r-- 1 root root 100062 Nov 17 09:18 .Audit_2.log -rw-r--r-- 1 root root 66260 Nov 17 12:36 .Audit.log drwxr-xr-x 2 root root 4096 Mar 30 2020 backup -rw-r--r-- 1 root root 2640 Feb 22 2024 bacstac.ini drwxr-xr-x 4 root root 4096 Mar 30 2020 cert drwxr-xr-x 2 root root 4096 Nov 17 12:29 .cmact_licenses drwxr-xr-x 2 root root 4096 Mar 30 2020 _cnc -rw-r--r-- 1 root root 1000088 Nov 17 08:35 codesyscontrol_0.log -rw-r--r-- 1 root root 422521 Nov 17 12:30 codesyscontrol.log -rw-r--r-- 1 root root 355 Nov 17 12:29 .GroupDatabase.csv -rw-r--r-- 1 root root 355 Nov 17 12:19 .GroupDatabase.csv_ drwxr-xr-x 3 root root 4096 Nov 17 11:16 OPCUAServer drwxr-xr-x 6 root root 4096 Mar 30 2020 .pki drwxr-xr-x 9 root root 4096 Nov 17 11:16 PlcLogic -rwxr-xr-x 1 root root 156 Mar 30 2020 rts_set_baud.sh -rw-r--r-- 1 root root 20736 Feb 22 2024 .SoftContainer_CmEmbedded.wbb -rw-r--r-- 1 root root 12445 Nov 17 09:06 SysFileMap.cfg -rw-r--r-- 1 root root 1983 Feb 22 2024 .UFC_SoftContainer_CmEmbedded.WibuC mLif -rw-r--r-- 1 root root 646 Nov 17 09:51 .UserDatabase.csv -rw-r--r-- 1 root root 646 Nov 17 09:51 .UserDatabase.csv_ -rw-r--r-- 1 root root 17305 Nov 17 12:29 .UserMgmtRightsDB.csv drwxr-xr-x 2 root root 4096 Mar 30 2020 visu -rw-r--r-- 1 root root 32684 Feb 8 2023 WibuCtxt.ctx
Last updated: 2025-11-17

Post by sahin6033 on DSE M840-001-02: DSEServiceTool transfers CodesysApp.pkg successfully, but device shows “No application loaded ^{CODESYS Forge talk (Post)}
Hi, I am trying to load a test application into a DSE M840-001-02 display, but after reboot the device still shows: “No application loaded” I would like to understand whether the problem is in my project, the package creation process, or firmware/runtime compatibility. Hardware Device: DSE M840-001-02 Firmware used: M840 MKII Firmware File v4.1.2 Software CODESYS V3.5 SP12 (32-bit) DSE CODESYS Package v1.5.44 DSEServiceTool What I did Created a new empty Standard Project Selected target/template: M840-02 V4.1 Used a minimal ST program only: PROGRAM PLC_PRG VAR xAlive : BOOL := TRUE; END_VAR Confirmed: project builds PLC_PRG is assigned to MainTask created Boot Application Generated CodesysApp.pkg Put the M840 into bootloader mode Sent the package using DSEServiceTool DSEServiceTool result Transfer completes successfully and I get: connection accepted 100% download package ACK <status>OK</status> ** Example log:** Searching for controllers.... sendPackageToController: waiting for incoming data connection... sendPackageToController: connection accepted... <status>Downloading</status> <percent>20</percent> <percent>40</percent> <percent>90</percent> <percent>100</percent> sendPackageToController: sent 112cb8 bytes OK Package ...\CodesysApp.pkg transferred to controller c0a80101 OK sendPackageToController: package ACK <status>OK</status> Actual result After reboot, the display still shows: “No application loaded” Additional issue I also saw earlier At one stage I also had these fatal errors in CODESYS: [FATAL ERROR] Unresolved reference: 'IOMGRLOCKENTER' [FATAL ERROR] Unresolved reference: 'IOMGRLOCKLEAVE' I checked library versions and adjusted them to: IoDrvBase = 3.5.5.0 IoStandard = 3.5.10.0 Also, I am using CODESYS SP12, which I understand is the correct version for DSE M840. My questions If DSEServiceTool shows Status OK and package ACK, but the device still says “No application loaded”, does that mean: the .pkg was transferred but not accepted as a valid application? the package was built incorrectly? the boot application / runtime / firmware versions are still mismatched? What is the correct procedure to generate CodesysApp.pkg for M840-02 V4.1? Is there any known compatibility issue between: DSE CODESYS Package 1.5.44 M840 MKII Firmware 4.1.2 CODESYS 3.5 SP12 Has anyone successfully loaded even a minimal empty test project into M840-001-02, and if so, what exact versions/process did you use? Any help would be appreciated.
Last updated: 2026-03-17

Post by rossanoparis on CAN TX regression in Control for Raspberry Pi 4.21.0.0 with CAN API library (RX works, TX silently fails) ^{CODESYS Forge talk (Post)}
Environment: Target: Revolution Pi (Kunbus RevPi), armv7l 32-bit OS: Raspbian GNU/Linux 9 (Stretch), kernel 4.19.95-rt38-v7 (SMP PREEMPT RT, built 2022-03-22) CAN: via SocketCAN (can0) Runtime: CODESYS Control for Raspberry Pi SL IDE: CODESYS V3.5 SP22 + patch 3 (previously V3.5 SP22 + patch 2, where everything worked with runtime 4.18.0.0) Library: CANBusAPI from the "CAN API" package, version 1.0.0.3 Summary: The setup worked correctly with V3.5 SP22 + patch 2 and runtime 4.18.0.0. After updating the IDE to SP22 + patch 3 and the runtime to 4.21.0.0, CAN transmission via the CANBusAPI library stopped working. Reception is unaffected. There are no error indications anywhere: the application runs normally and the CAN diagnosis reports a healthy bus. Systematic testing (below) shows the problem follows the runtime version, not the IDE update. Regression isolation: The same application (compiled under SP22 + patch 3, unchanged between tests) was downloaded to the same target with different runtime versions, changing only the runtime each time: 4.18.0.0: TX and RX both work 4.19.0.0: TX and RX both work 4.20.0.0: TX and RX both work 4.21.0.0: RX works, TX does not The behavior is fully reproducible in both directions (downgrading to 4.20 restores TX, upgrading to 4.21 breaks it again). Hardware, wiring, OS, project, and application code are identical across all tests. Diagnostic data (CANBusDiagnosis FB, while the application is transmitting on 4.21): ctSendCounter: incrementing normally ctTxErrorCounter: 0 ctRxErrorCounter: 0 eState: ERROR_FREE xBusAlarm: FALSE So the library accepts and counts the outgoing messages, no TX errors are reported, and the CAN controller state stays error-free, but the messages never reach the other nodes on the bus. Expected behavior: Messages sent via CANBusAPI (CANDriver / SendMessage) are transmitted on the bus, as with runtime versions up to and including 4.20.0.0. Notes: I am aware that the CAN API package (1.0.0.3, from 2016) is old; however, the regression is tied to the runtime version, since the identical binary works on 4.18-4.20. Questions: Is there a known change in CmpSocketCanDrv / CmpCAACanL2 between 4.20.0.0 and 4.21.0.0 that could affect TX via the CAN API library? Is runtime 4.21.0.0 still supported on Debian 9 Stretch (kernel 4.19, RT-patched), or is a newer OS required? If a minimum OS/kernel requirement was introduced with 4.21, is it documented?
Last updated: 2026-08-17

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 cdutz on Problems connecting to Codesys 4.9.0.0 runtime on my Wago PFC200 ^{CODESYS Forge talk (Post)}
Turns out I managed to get a connection to my PLC. It seems that a few weeks ago Wago released something with version 4.3.3(25). So I reset my PLC to Factory-Reset, set it to the 192.168.1.17 IP and changed the IP to the one I wanted with the Wago EthernetSettings tool. Then updated the latest firmware using the WAGOupload tool. Now the PLC came back up without a PLC runtime running, so in the Web-tool I wen't to the "Configuration"/"PLC Runtime" and selected the runtime version "CODESYS V3". I uninstalled all Codesys versions and installed the version from the download package of Wago together with all the packages the bundle provided. After creating a new project I didn't select the old PFC200 runtime, but one of the dozens of new device profiles, that it now listed. With these settings I was then able to connect to my PLC. Now I hope I'll get the existing project that I had ported to this new structure. Sorry for the noise. Chris
Last updated: 2023-08-26

Post by garyl on Comments in arrays and assigning RST coil's to 600 outputs ^{CODESYS Forge talk (Post)}
Hello all, im working on a project that requires me to convert an old automation direct DirectSoft PLC d2-250-1. One of the problems im encountering is that all of the comments are attached to members of the different addresses. When i convert the addresses (1777 "C" registers, 777 X registers, and 20,0000 V registers) im running into difficulties keeping the inputs/outputs correct since they are missing documentation. Is there a good way to retain the comments of the indexes in the array? Secondly, initially i was declaring the "C" and "V" addresses individually and this worked to retain the comments as to which register did what, however i ran into a problem when one rung reset (or set to 0) approximately 600 C Addresses. Since each tag is separately declared this proved to be nearly impossible without a literal wall of code that attempted to crash the program. So i converted all of the registers (C,X,Y,V) into separate structs, declared them as arrays and pointed all of the original call outs in the program to the newly defined structs. However i have now lost comments and the program is very hard to follow. Thanks for any help with this issue.
Last updated: 2023-08-31

Post by ofey on Codesys Soft PLC OPC UA server ^{CODESYS Forge talk (Post)}
Hi! I'm sorry if this has been asked before. I have tried looking up previous topics regaring this, but even though I'm following tutorials and other posts I cant seem to get this to work consistently. I actually got the connection established on a test project after some trial and error. I only got it to work with the "Anonymous login". But after i deleted the test project and tried to get the same thing to work on another project I cant get it to work anymore. What I'm trying to do: Set up and OPC UA Server using CODESYS with the free soft PLC. I then try to connect to the OPC UA Server with the program "UaExpert". What happens: I get the error Error "'BadUserAccessDenied' was returned during ActivateSession". What I have done in CODESYS: - Added the object "Symbol configuration" and checked some test variables - Checked "Support OPC UA features - In "Communication settings -> device -> Change runtime security policy" I have checked "Allow anonymous login" What I have done in UAExpert: - Found the OPC UA server under "local". (It is showing two servers though, I do not know why. It showed the same when it worked yesterday). Se attachment - Checked "Anonymous" under "Authentication settings in the OPC UA server. I'm new to CODESYS, so it could be something elementary wrong in my settings. Maybe something in the user settings in CODESYS regarding user rights or something?
Last updated: 2023-09-14

Post by toby on Ethercat Servo Setup ^{CODESYS Forge talk (Post)}
Hi Everyone, I have a simple project with a single servo, but its my first time using Codesys and motion, so I'm a little confused and lost, I've tried to read the tutorial online, but I'm not having much luck sorry. Can I please ask for some pointers. I have a ComfilePi HMI (Raspberry Pi) communicating to a Omron R88D-1SN08H-ECT amplifier. Please see the attached project file (which is better for sharing, the project file, or a archive?). This file was simply for testing the motion of the servo before anything else is tested with it. The project simply rotates the servo 1 rotation when called for, but the speed can vary based on user input. Nothing much fancy. As yet, I haven't had any servo movement, no errors on the amplifier display. How do I link the motion FBs to the physical drive? Thank you very much for any help you can offer. I'm sorry if I'm doing something very stupid or basic and getting it wrong. Have a good day. Toby
Last updated: 2023-09-20

Post by toffeebonbon on EL7041-0052 - does it run with EL7041 SoftMotion? ^{CODESYS Forge talk (Post)}
Good morning everyone. In my setup I am trying to use a couple of EL7041-0052 (the EL7041 variant without terminals for an encoder) to run stepper motors without feedback. When using the softmotion drivers for the EL7041 (Rev22 and Rev24, even selecting external feedback type doesn't work) the device log shows warnings for the corresponding hardware: "SDO write error 0x1 -> 0x8012:0x08 eError 0x1 AbortCode 0x6090011". 0x8012:0x08 is the register for the Feedback Type. My best guess was setting the the register value in the start parameters to zero, but the result is the same. What else can I try to get the hardware to work? I have screenshots attatched showing the running fieldbus and the log messages. EDIT: One clarification: the "device log" that shows the error is the PLC, not the ethercat terminal. The log of the terminal itself shows neither errors nor warnings. BR Robert
Last updated: 2023-11-29

Post by nizrahel on OpC UA server on Raspberry Pi 64 SL runtime ^{CODESYS Forge talk (Post)}
Hi all! I'm working on an home project using a Raspberry Pi 3 device with Codesys for Raspberry Pi 64 SL runtime. I would like to create the HMI interface with Siemens WinCC Unified (or Advanced) configuring the Raspberry as OPC UA server. I tryed everything, but I didn't find the way to let the OPC UA connection works using UaExpert. I tryed to use anonymous connection, authenticated connection and the ip address instead of the server name in the path connection. There is no way to connect to the OPC UA server and I was asking myself if this feature is really supported for the runtime version used. Another strange thing I noted, is that is not possible to quickly create an OPC UA certificate in the Security Screen, as show in any tutorials. I have correctly created the Symbol Configuration enabling the OPC UA feature. I attach to this topic some printscreen of the actual configuration (sorry for the italian language interface, but I didn't find the way to switch to english). Thank you very much in advance for your support and advices!
Last updated: 2023-12-03

Sort by relevance or date