Post by aliazzz on Unable to deploy Virtual Control SL on ARM64 (Raspberry Pi5) ^{CODESYS Forge talk (Post)}
Hi, I have successfully deployed "Virtual Control SL" on a few x86/64 machines now. However, I'd now like to deploy this to a Raspberry Pi (ARM64). To do this I prepared the Raspberry Pi5 with the following prereq's; * Minimal PREEMPT Debian * Latest Bootfirmware * full SSH access via non-root account * Podman * RedHat Cockpit with CODESYS LicensServer plugin up and running However, I can't seem to resolve copying the correct (deploy) Images as they wont show up in the CODESYS IDE I have added CODESYS Virtual Control for Linux SL and the CODESYS LicenseServer for Linux SL via the CODESYS installer on my DevBox. I open CODESYS > Tools > Deploy Control SL Next I enter the SSH targets IP and Credentials and for my RPi5 and it shows "Connected". In the next tab, Deployment, the dropdown box only shows one (1) image, which also is the incorrect CPU architecture. Only Virtual Control AMDx64 shows up (!?) while I expect to see the ARM64 based images for both Edge and Control. Has someone encountered this too? I'd like to hear other people experiences with Virtual Control deployment on ARM based architecture. attachment 1: AMD64 based deployment pulldown menu (correct images) attachment 2: ARM64 based deployment pulldown menu (incorrect images) regards,
Last updated: 2024-07-28

Post by kleeswi on Visualization scaling problem with B&R T30 panel ^{CODESYS Forge talk (Post)}
The probelm arises for the B&R T30 panel after updating Codesys from 3.5.17 to 3.5.19 patch 5. We have to use 3.5.19 for other reasons so we cannot downgrade the version. The scaling problem only exists for the B&R 6PPT30.0702.20F025 panel, the B&R T50 panel and a esa lumia panel work. When we choose a fixed resolution it looks also good, however we also want to support the esa lumia panel with a different resolution. The images show the anisotropic and isotropic option. In the anisotropic option it scales the hight correctly but not the width and in the isotropic option is scales both hight and width false, it also does not start in the top left corner. Does someone have any suggestion why it does not work anymore with the new codesys version and are there workarounds? I added all versions with visualization packages as an image, visuElems is 4.4.0.0.
Last updated: 2024-07-29

Post by karel-bas on Loosing connection to emulation running on Linux ^{CODESYS Forge talk (Post)}
Hello, I am trying to emulate my code but for some reason my Codesys IDE keeps loosing connection to the emulator. I am constantly pinging virtual machine on which its running and its running fine, but codesys refuses to reconect to it, and is not able to rediscover it. Codesys 3.5 SP20 Patch 1 I have linux installed like image in attachment.(using version 4.12) Linux VM is set up to use up to 4 cores and 8gb of ram, with nothing else runing on it. I dont have a license so I am aware that the emulation shouldnt run for more then 120 minutes I am able to, login, get sysinfo, reboot etc from codesys IDE for certain period of time (5minutes) then my connection gets lost, sometimes I can login again, but sometimes i have to reboot the VM. Any suggestions what might be the issue ?
Last updated: 2024-09-19

Post by elektron785 on Dongle von Linux-Modul (ARM64) nicht erkannt ^{CODESYS Forge talk (Post)}
Ich hatte noch einmal Zeit das mit der Lizenz zu probieren und habe dazu über den Codesys Installer das Virtual Control SL runtergeladen und ausprobiert, aber leider ohne Erfolg. Zunächst habe ich "Docker_codesyscontrol_virtuallinuxarm64_4.13.0.0_arm64.tar.gz" aufs Board geladen und das Image mit docker load geladen. Mit dem Befehl docker run --rm -dt --name codesys --network host -v /dev:/dev -v /tmp:/tmp -v /run/udev/:/run/udev/ --device-cgroup-rule='c 13: rmw' --privileged 470a708f17a2 hab ich dies dann ausgeführt, aber das Problem, dass ich das Board im Netzwerk dann nicht finden konnte. Damit ich die Verbindung herstellen konnte, habe ich die Datei "DockerRuntimeStart.sh" so verändert, dass ich den Teil: -p 11740:11740/tcp \ -p 443:443/tcp \ -p 8080:8080/tcp \ -p 4840:4840/tcp \ gegen --net host \ ersetzt habe. Das Skript habe ich dann aufs Board geladen und bash DockerRuntimeStart.sh -i codesyscontrolvirtuallinuxarm64:4.13.0.0 -c codesys -H verdin-imx8mp- ausgeführt. Nun konnte ich in Codesys wieder eine Verbindung zu dem Board aufbauen, aber der Dongle wird leider immer noch nicht im Lizenz-Manager erkannt. Wie kann ich denn prüfen, dass auf den USB-Stick vom Container aus zugegriffen werden kann?
Last updated: 2024-09-23

Post by naps on cant install runetime on 750-8202 ^{CODESYS Forge talk (Post)}
Hello, im trying to install the 3.5 Runtime on a a fresh image on my 750-8202. Product Description: WAGO 750-8202 PFC200 CS 2ETH RS Firmware Revision: 03.10.08(22) ~~~ df -h Filesystem Size Used Available Use% Mounted on ubi0:rootfs.1 82.5M 66.5M 11.8M 85% / devtmpfs 117.8M 16.0K 117.8M 0% /dev none 118.3M 12.0K 118.3M 0% /tmp none 118.3M 0 118.3M 0% /media none 4.0M 136.0K 3.9M 3% /var/log none 118.3M 112.0K 118.2M 0% /var/run none 118.3M 0 118.3M 0% /var/lock none 118.3M 0 118.3M 0% /var/tmp none 118.3M 0 118.3M 0% /sys/fs/cgroup tmpfs 118.3M 48.0K 118.2M 0% /run /dev/ubi0_1 58.6M 3.4M 52.2M 6% /home /dev/ubi0_1 58.6M 3.4M 52.2M 6% /settings /dev/ubi0_1 58.6M 3.4M 52.2M 6% /log ~ After installation and reboot i have still the wago webinterface. No runtime on Information Tab and the Runtime button from the configuration tab is lost. iv try it with firmware 22 and 21. Same problem. What can i do?
Last updated: 2024-09-29

Post by z870623 on About CPU Loading ^{CODESYS Forge talk (Post)}
I am running a runtime environment on an ARM A35 dual-core processor (1.5GHz) and have encountered some issues. The CPU load (both CPU0 and CPU1) occasionally spikes above 50% before returning to normal, and this happens around 2-3 times per minute. At the same time, I’ve noticed that the Max Cycle Time in the Codesys monitoring screen shows much worse performance compared to the A53 (1.2GHz), with nearly double the cycle time. The optimizations I have made so far are as follows: Set the CPU to performance mode. Isolated CPUs: CPU0 is dedicated to running Linux services and the runtime itself, while CPU1 runs the EtherCAT task and the MainTask. Despite CPU1 only running these two tasks, the utilization still increases above 50%, which I find unreasonable. Additionally, I performed tests using cyclictest both without and with the runtime running. The performance is shown in the following image: From the results, I believe the CPU performance should be fine, but I am unsure why the monitoring results are not as expected. The testing outcomes should ideally be as close as possible to the cyclictest results. Does anyone have related solutions to this issue?
Last updated: 2024-10-14

Post by koerbejm on Probleme beim aktivieren von Lizenzen ^{CODESYS Forge talk (Post)}
Liebe Codesys-Gemeinde, ich habe folgendes Problem und bitte um Hilfe: Um eine auf meinem dem Raspberry Pi laufende Steuerung ohne große Mühe duplizieren zu können, habe ich mir ein Image der SD Karte mit Win32 Diskimager erstellt. Dieses konnte ich bisher ohne weitere Probleme auf eine weitere Micro-SD karte ausrollen. Anschließend habe ich mich via Putty auf den PI geschaltet, die vorherige Lizenz (die ja für den vorheringen PI zulässig war) gelöscht über - sudo su - rm -r /var/opt/codesys/cmact_licenses/ - reboot Um dann via Codesys 3.5 SP16 Patch 4 eine neue Lizenznummer ">>Tools>Lizenzmanager>Lizenz aktivieren" zu aktivieren und das wars. Durch die Umstellung des Lizensierungsverfahrens klappt diese Variante nun nicht mehr. Ich habe mir neue Lizenzen von Codesys gekauf, doch sobald ich diese in die Ticket-ID eintrage und aktivieren möchte bekomme ich folgende Fehlermeldung: ReturnCode: 403046401, An internal error has occured. Please try it again later. (siehe Bild im Anhang "Fehler_Codesys3.5V16.png") Ich habe dann meine Codesys-Version auf Version 3.5 SP20 geupdated und das selbe versucht mit dem Resultat, dass ich nun folgende Fehlermeldung erhalte: "Der ausgewählte Container "...." paßt nicht zu Ihrem Ticket. Bitte wählen Sie einen passenden aus." --> Siehe Bild im Anhang "Fehler_Codesys3.5V120.png" Was genau kann/muss ich tun, damit ich einfach wie bisher meine Steuerungen duplizieren kann? Verwendete Hardware: Raspberry Pi 3 Model B+ Verwendete Lizenz: Codesys Control Basic L Viele Grüße und Danke, Jan
Last updated: 2024-10-23

Post by etienneneu on loading delay with the option "check client animations and overlay of native elements" ^{CODESYS Forge talk (Post)}
Hey NicolaG_89, thanks for the tip. But I have seen in the developer tools of the Webclient that a multiple fetching of the image and script data occurs when changing frames (HTTP code 304 NOT Modified), although these are already in the clients cache, which leads to unnecessary loading of resources from the web server. This behavior can also be found if the option “Support client animations and overlay of native elements” is deactivated, but this does not lead to such long delays. I had already tested loading all Visu elements so that everything was fetched once before they could be used. But that didn't help either. To prevent this behavior (permanent fetching), I have used a different way of switching the Visu elements in the VisuDemo Project, which also uses HTML5 control elements. I implemented this with the visibility of entire Visu elements. As a result, it only has to be fetched once and does not have to be fetched again when reloading. But I am still unsure about this implementation if the scope of the visualization becomes larger, as the Codesys visualization documentation advises against using many invisible elements. Best regards Etienne
Last updated: 2024-11-19

Post by atcprojectteam on Modbus Function Code 15, writing multiple coils ^{CODESYS Forge talk (Post)}
Hi all, I am using an RSTI-EP I/O card along with the EPXMBE101 Modbus/TCP network adapter. I have a Control Standard L license. I successfully connected to the I/O card via Modbus and can read inputs without any issues. However, when I try to write to the digital output modules using function code 15, I am unable to make any changes. Here’s what I have done so far: I created a small project using Structured Text. I set up Modbus channels (as shown in the attached image) and mapped the pins. When I use cyclic mode, the connection results in an error. However, when I use the rising edge, the connection works, but I don’t see any changes on the I/O card. For the output module, I assigned one bit to high. After that, I ran CODESYS Control Win V3. (Should I be running the PLC as well?) I built the program, but I am not receiving any response from the I/O card. Could you please advise on what might be causing this issue?
Last updated: 2025-02-26

Post by atcprojectteam on Modbus Function Code 15, writing multiple coils ^{CODESYS Forge talk (Post)}
Hi all, I am using an RSTI-EP I/O card along with the EPXMBE101 Modbus/TCP network adapter. I have a Control Standard L license. I successfully connected to the I/O card via Modbus and can read inputs without any issues. However, when I try to write to the digital output modules using function code 15, I am unable to make any changes. Here’s what I have done so far: I created a small project using Structured Text. I set up Modbus channels (as shown in the attached image) and mapped the pins. When I use cyclic mode, the connection results in an error. However, when I use the rising edge, the connection works, but I don’t see any changes on the I/O card. For the output module, I assigned one bit to high. After that, I ran CODESYS Control Win V3. (Should I be running the PLC as well?) I built the program, but I am not receiving any response from the I/O card. Could you please advise on what might be causing this issue?
Last updated: 2025-02-26

Post by toffeebonbon on Die richtige CODESYS-Runtime auf dem Raspberry Pi ausrollen (3.5 SP18) ^{CODESYS Forge talk (Post)}
Guten Morgen, wie der Titel verrät soll es hier um das Ausrollen der CODESYS Runtime auf einem Raspberry Pi gehen. Ob ein klassischer Raspberry Pi aus dem Consumer-Bereich oder ein Compute-Modul spielt in dem Fall keine Rolle. Ich möchte nur anderen Nutzern Hilfestellung geben, die vielleicht ein vergleichbares Problem haben wie ich: Auf Raspberry Pi lief bei mir eine Anwendung, die mit Lizenzen auf einem CODESYS-Dongle lizenziert waren (Multicore-Support und Softmotion). Nach einem Hardware-Defekt habe ich meinen Rasperry Pi gegen eine robustere Lösung getauscht. Ich wollte auf der neuen Hardware die Runtime ausrollen und habe ständig den Fehler gezeigt bekommen, dass die Target- oder Zielsystem-ID nicht stimmt. Für den Raspberry Pi gibt es ja drei verschiedene Optionen der Runtime: 32bit Singlecore (armv6l) 32bit Multicore (armv7l) 64bit Multicore (aarch64) Entscheidend dafür, ob die 32 oder 64 Bit Runtime benötigt wird ist das auf der dem Raspberry Pi installierte Betriebssystem. In meinem Fall hatte ich durch die neue Hardware auch ein aktuellen Betriebsystem-Image aufgespielt, weshalb sich da der Umstieg von 32 auf 64Bit eingeschlichen hatte. In der Entwicklungsumgebung kann über Tools -> Control SL ausrollen das Fenster geöffnet werden, um die richtige Laufzeitumgebung auf dem Steuerungsrechner zu installieren. Bei kleinen Bildschirmen (bei mir ein 15" Laptop) kann der rechte Bereich "abgeschnitten" und das Dropdown-Menü als solches nicht auf den ersten Blick erkennbar sein. Mein Fehler war, dass ich den Scrollbalken nicht gesehen habe! (Bild im Anhang mit freundlicher Genehmigung von Herrn Heberle vom CoDeSys-Support) Nach dem auswählen der jeweils passenden Version kann die Runtime installiert und das Programm wieder geladen werden. Die Lizenzen sind bei mir wieder korrekt erkannt worden und alles läuft wie vorher (nur mit neuer Hardware). Vielen Dank an der Stelle noch mal an die schnelle Hilfe vom Support. Das hat wirklich top funktioniert.
Last updated: 2025-02-27

Post by jeindhoven on Deploying to raspberry pi 5 hangs ^{CODESYS Forge talk (Post)}
Yep sure, though now that i think of it, its a pi 4. My bad. The whole ordeal was necessary to use the VGA666 adapter. That needs the old graphical system and GPIO directly on the CPU. Edit: Putty on the virtual development machine connects fine. But i did change the login/pw. The account is still a sudo'er so that should be all right. Edit2: Sorry i get a "Comment rate limit exceeded" from the forum. Then i'll add it as edit here. So i have tried the stock raspberry pi image on a different pi5 (truly 5 this time). Packages updated. Standard password. Same symptoms, no runtime deployed and long hang time. Versions of this pi: pi@raspberrypi:~ $ uname -a Linux raspberrypi 6.12.25+rpt-rpi-2712 #1 SMP PREEMPT Debian 1:6.12.25-1+rpt1 (2025-04-30) aarch64 GNU/Linux pi@raspberrypi:~ $ lsb_release -a No LSB modules are available. Distributor ID: Debian Description: Debian GNU/Linux 12 (bookworm) Release: 12 Codename: bookworm pi@raspberrypi:~ $ apt list --installed | grep openssh-server openssh-server/stable,now 1:9.2p1-2+deb12u6 arm64 [installed,automatic] Attached is the Device information and error text that Codesys comes up with. Edit 3 (Comment rate limit, otherwise it would be a new post) Now i have tried booting an older native Windows 10 machine (no virtualization), and it just works as expected. I have now a raspberry pi 4 and raspberry pi 5 with version 4.16.0.0 of the control application. Windows 10 native: build 19045 (same as virtualised Win 10), same .NET version, same CODESYS version. It seems that running CODESYS virtualized somehow messes with the deployment?
Last updated: 2025-06-23

Post by thommy54 on Lizenz wiederherstellen SP20 ^{CODESYS Forge talk (Post)}
Hallo Edwin, ich bräuchte mal eine schnelle Hilfe. ich testete einen zweiten Raspberry Pi 4 mit meinem Lizenzdongle eines laufenden Raspberry. Der 2. Raspberry ist als Redundanzlösung bei einem Crash gedacht. DIe Schwierigkeiten begannen, als ich mit dem Raspberry 4 V1.5 nicht mehr mit SP16 weiterarbeiten konnte. Ich updatede auf SP20.1. und die Schwerstarbeit begann. Das Image wurde rübergeschoben und alles auf dem zweiten Rechner soweit zum Laufen gebracht. Der Dongle wurde ebenfalls am 2. Rechner eingesteckt. Ob er überhaupt wirkte, kann ich nicht sagen, da für diesen Testfall Codesys so oft rauf und runter gefahren wurde, das die 2h-Grenze kaum erreicht wurde. Problem: Beim Zurückstecken des Dongles in den ursprücnglichen Rechner ist alles an Lizenzen weg. Der Lizenzmanager hat keinen Container mehr und der Befehl "lsusb" bringt nichts zurück. ich war der Meinung, das der Dongle genau für diesen Zweck gedacht war - die Lizenz von einem Rechner zum anderen mitzunehmen. Liege ich da falsch ? Wie komme ich nun wieder zu einem funktionfähigen Dongle ?? Weitere Versuche unternahm ich mit dem Wiederherstellen des Dongels. Dabei steckte ich ihn in meinen PC (Workstation) und siehe da, es werden noch 3 von ehemals (2020) 6 Lizenzzeilen angezeigt: (siehe Bild Problem_Lizenzen_Raspberry.jpg) Dann versuchte ich das Wiederherstellen über eine Lizenzaktualisierungsdatei vom Lizenzserver. Da kommt aber eine Datei mit anderem Dateityp (..WibuCmRaC) als im Lizenzmanager gesucht (WibuCmRaU). Die Datei ist dem Lizenzmanager auch nicht genehm (Bild Problem_Lizenzen_Raspberry_2.jpg). Nun steht Codesys auf besagtem Raspberry alle 2h still. Das soll die Lizenz doch verhindern. Angeblich soll seit SP13 auch kein eigenes Backup mehr nötig sein. Bis zum Erhalt des nicht brauchbaren Linzenzfiles hat da sja geklappt. Ich kann auch im Lizenzmanager keinen Punkt "Lizenz wiederherstellen" finden. Hat sich da mit SP20 etwas geändert? Wenn ich mir eine neue Lizenz hole - wie bringe ich sie auf den Dongle (der ja jetzt nicht "nagelneu" ist). Ich fürchte, das geht auch bloß schief. Im Voraus vielen Dank Thomas
Last updated: 2024-07-02

Post by jari-koivuluoma on Problem trying Net Base Services 3.5.15.0 TCP connection ^{CODESYS Forge talk (Post)}
I have a need to send messages between 2 PLCs and I cant use network variables (because of size limit) so I tried writing this simple test program. This seems to work fine. I can send messages back and forth when a first "Start server" and then "Connect client". See the attached image. However, if I disconnect the client by setting ClientConnect to false and try to re-connect then the TCP_Client just gives me TIMEOUT error. When I stop and start the server again, then Im able to reconnect. How is this supposed to work? Why reconnecting wont work. There is not other way of disconnecting the client than setting xEnable of the TCP_Client to false. This is just a testing program and I will try it on 2 seperate devices once this works. PROGRAM PLC_PRG VAR CONSTANT mySize : UDINT := 255; END_VAR VAR Server: NBS.TCP_Server; ServerIpStr: STRING := '127.0.0.1'; ServerIP: NBS.IP_ADDR; ServerPort: UINT := 50000; ServerConnection: NBS.TCP_Connection; Client: NBS.TCP_Client; ServerRead: NBS.TCP_Read; ServerWrite: NBS.TCP_Write; ServerSend: STRING(mySize); ServerReceive: STRING(mySize); ServerConnect: BOOL; bServerSend: BOOL; IP: NBS.INADDR; ConnectedClientIP: STRING; ClientPort: UINT := 50000; ClientIpStr: STRING := '192.168.1.49'; ClientIP: NBS.IP_ADDR; ClientRead: NBS.TCP_Read; ClientWrite: NBS.TCP_Write; ClientSend: STRING(mySize); ClientReceive: STRING(mySize); ClientConnect: BOOL; bClientSend: BOOL; Error: BOOL; Message: BOOL; END_VAR // Server ServerIP.sAddr := ServerIpStr; Server( ipAddr := ServerIP, uiPort := ServerPort ); ServerConnection( xEnable := Server.xEnable, hServer := Server.hServer, ); IP := ServerConnection.IPAddress; ConnectedClientIP := F_Concat7( BYTE_TO_STRING(IP.S_un_b.s_b1),'.', BYTE_TO_STRING(IP.S_un_b.s_b2),'.', BYTE_TO_STRING(IP.S_un_b.s_b3),'.', BYTE_TO_STRING(IP.S_un_b.s_b4)); ServerRead( xEnable := ServerConnection.xActive, hConnection := ServerConnection.hConnection, szSize := SIZEOF(ServerReceive), pData := ADR(ServerReceive) ); IF ServerRead.xReady AND ServerRead.szCount > 0 THEN Message := TRUE; END_IF IF ServerRead.eError > 0 THEN Error := TRUE; END_IF ServerWrite( xExecute := ServerConnection.xActive AND bServerSend, hConnection := ServerConnection.hConnection, szSize := LEN(ServerSend)+1, pData := ADR(ServerSend) ); IF ServerWrite.xDone THEN bServerSend := FALSE; END_IF IF ServerWrite.eError > 0 THEN Error := TRUE; END_IF // Client ClientIP.sAddr := ClientIpStr; Client( xEnable := ClientConnect, ipAddr := ClientIP, uiPort := ServerPort, udiTimeOut := 10000000 ); ClientRead( xEnable := Client.xActive, hConnection := Client.hConnection, szSize := SIZEOF(ClientReceive), pData := ADR(ClientReceive) ); IF ClientRead.xReady AND ClientRead.szCount > 0 THEN Message := TRUE; END_IF IF ClientRead.eError > 0 THEN Error := TRUE; END_IF ClientWrite( xExecute := Client.xActive AND bClientSend, hConnection := Client.hConnection, szSize := LEN(ClientSend)+1, pData := ADR(ClientSend) ); IF ClientWrite.xDone THEN bClientSend := FALSE; END_IF IF ClientWrite.eError > 0 THEN Error := TRUE; END_IF
Last updated: 2024-10-03

Post by smeitink on Timeout Error in Modbus Communication with WAGO PFC200 and iEM2050 Meter using 750-652 Module ^{CODESYS Forge talk (Post)}
Hi all, I'm looking for help with an issue I've come across while trying to facilitate Modbus communication between a WAGO PFC200 PLC using a 750-652 communication module and an iEM2050 Series Single Phase Energy Meter. I believe to have everything wired and setup correcty, but I keep running into a "Error time out" message, and by now I don't really know what else to try. My setup is as follows: A PFC200 Wago PLC, which has 2 750-652 Serial Interfaces extension modules connected to its field bus. I'm using one of these to talk to a Schneider iEM2050 - kWh-meter over modbus. I have connected terminal 23 (A) of the iEM2050 to connector 6 (A) on the 750-652. I have connected terminal 24 (B) of the iEM2050 to connector 2 (B) of the 750-652. I'm using 200mm of twisted together wires to connected them both, and I have placed a 120 ohm resistor between A and B at both ends. I've attached relevant pinout images to this post. I then wrote a simple program that configures the Mobus port, as per the datasheet of the iEM2050. You can find an image of the relavent page attached to this post too. This is my program: PROGRAM PLC_PRG VAR Master: FbMbMasterSerial; xIsConnected: BOOL; xError: BOOL; iIndex: INT := 1; xTrigger: BOOL; utQuery : typMbQuery := ( bUnitId := 1, // The Modbus unit or slave address bFunctionCode := 4, // Function code for reading input registers uiReadAddress := 1829, // adress for the Power on off counter uiReadQuantity := 1 // Quantity of registers to read ); iStep: INT; oStatusModbus: WagoSysErrorBase.FbResult; utResponseModbus: typMbResponse; xConnect: BOOL := FALSE; delayTimer: TON; END_VAR Master( xConnect:= xConnect, I_Port:= _750_652_24_1, udiBaudrate:= 9600, usiDataBits:= 8, eParity:= WagoTypesCom.eTTYParity.Even, eStopBits:= WagoTypesCom.eTTYStopBits.One, eHandshake:= WagoTypesCom.eTTYHandshake.None, ePhysical:= WagoTypesCom.eTTYPhysicalLayer.RS485_HalfDuplex, xIsConnected=> xIsConnected, xError=> xError, oStatus=> oStatusModbus, eFrameType:= WagoAppPlcModbus.eMbFrameType.RTU, tTimeOut:= T#5S, utQuery:= utQuery, xTrigger:= xTrigger, utResponse:= utResponseModbus); delayTimer(IN := TRUE, PT := T#3S); // Use the Q output of the timer to set xConnect after the delay IF delayTimer.Q THEN xConnect := TRUE; END_IF CASE iStep OF 0: //Wacht totdat de master de poort geopend heeft IF xIsConnected THEN iStep := 1; END_IF 1: //Stuur request naar de slave xTrigger := TRUE; iStep := 2; 2: //Wacht totdat de master klaar is met het afhandelen van de request IF NOT xTrigger THEN iStep := 3; END_IF END_CASE The TON delay before opening the port is due to a an error I encountered when opening it straight away. This seems to be a bug, as described here. However, the TON solved that particular issue. I tried reading multiple registers, but like I said, I still always end up with the "Error time out". What else can I test or try at this point?
Last updated: 2024-02-24

Sort by relevance or date