Data Source Limit ^{CODESYS Forge talk (Thread)}
Data Source Limit
Last updated: 2024-03-06

Post by testlogic on Sending Sequential Modbus TCP Packets ^{CODESYS Forge talk (Post)}
I have a Modbus TCP slave device where I need to do sequential writes to the same register. The register I'm writing to is kind of like a command line, each packet is a command word encoded in Hexadecimal. I am having difficulty implementing this system in CoDeSys 3.5 SP19. I feel like the structure of the program should be something along the lines of (Pseudocode): ModbusTCPSend(Command Register, Command1) ModbusTCPSend(Command Register, Command2) ModbusTCPSend(Command Register, Command3) I have tried to implement this with a rising edge trigger wMot1OPCode := 16#E1; //Stop Motor & Kill Program xMot1SendOP := TRUE; //Send OP on rising edge xMot1SendOP := FALSE; //Reset wMot1OPCode := 16#9E; //Disable Motor xMot1SendOP :=TRUE; //Send OP on rising edge xMot1SendOP := FALSE; //Reset Where "wMot1OPCode" is the IO map for writing to the command register, and "xMot1SendOP" is the rising edge trigger for that modbus channel. However, this doesn't work. The device never responds to the modbus commands. It seems like the trigger variable is switched too quickly for modbus to send the packet. I know the modbus register is working, because I can set the channel to cyclic and the device will respond. However, I can't use this reliably because I need each command to be sent once, in order. Cyclic keeps re-sending the commands and seems like it could miss a command as well if one was sent in-between cycle time. I have also trying using the Application trigger as described by https://faq.codesys.com/pages/viewpage.action?pageId=24510480, but this is also not working for me. See attached picture for my FBD code. This seems like a simple function, I can't tell what I'm doing wrong here. Thanks for the help.
Last updated: 2024-03-06

Post by rstt on Codesys v3.5 on WAGO 750-8202 ^{CODESYS Forge talk (Post)}
Wago have documented that v3.5 is supported on their 821x controllers but not their 820x ones. Is it possible to import a device description and get it to run?
Last updated: 2024-03-07

Post by rckalex on Codesys v3.5 on WAGO 750-8202 ^{CODESYS Forge talk (Post)}
You can use C3.5 by using the 3S firmware on the 8202 https://us.store.codesys.com/codesys-control-for-pfc200-sl-1.html
Last updated: 2024-03-07

Codesys v3.5 on WAGO 750-8202 ^{CODESYS Forge talk (Thread)}
Codesys v3.5 on WAGO 750-8202
Last updated: 2024-03-07

Post by rckalex on Codesys v3.5 on WAGO 750-8202 ^{CODESYS Forge talk (Post)}
You can use C3.5 by using the 3S firmware on the 8202 https://us.store.codesys.com/codesys-control-for-pfc200-sl-1.html
Last updated: 2024-03-07

Post by miodusy on File transfer via visu and codesys automation server ^{CODESYS Forge talk (Post)}
I have a problem with the file transfer library. Namely, it does not work via the codesys server. (error 5; overtime, and visualization resets). They operate mostly in local chains. I tested different browsers and VPN from the router. It works everywhere, except through access from the codesys automation server. The client, having many machines under one account, prefers to keep it that way rather than use an individual VPN just to download a backup. Does anyone have an idea what the problem is? Sylwester M.
Last updated: 2024-03-07

Post by manuknecht on High Cycle Times for SoftMotion_PlanningTask when using AxisGroup ^{CODESYS Forge talk (Post)}
Hello all I am using an AxisGroup with the Gantry2 Kinematics to move a 2D-Gantry system. When creating the AxisGroup, the SoftMotion_PlanningTask is created automatically with a cycle time of 2 ms in my case. I realized that the maximum cycle time of this task can spike to very high values (up to 60 ms) at lower speeds of the motion, leading to synchronization issues and errors on the axes. The same behaviour - though not as drastic - can be observed with virtual axes too. Is this behaviour intended or to be expected? Can the cycle time or type of the SoftMotion_PlanningTask be changed to prevent these errors? Or is there another fix for this issue? I tried changing the cycle type to Freewheeling, which solved the synchronization issues, but caused an error on the AxisGroup after a while, reading SMC_CP_QUEUE_UNDERRUN. Thanks in advance and best regards Manuel
Last updated: 2024-03-07

File transfer via visu and codesys automation server ^{CODESYS Forge talk (Thread)}
File transfer via visu and codesys automation server
Last updated: 2024-03-07

Post by i-campbell on Not able to see input data coming from eip adapter on codesys ^{CODESYS Forge talk (Post)}
Hello, I think you can try to change the Connection from Multicast to Point to Point. Please also make sure your windows firewall is allowing the correct UDP ports inbound for ethernet IP. You might also need to increase the RPI, so it times out slower.
Last updated: 2024-03-07

Post by eschwellinger on File transfer via visu and codesys automation server ^{CODESYS Forge talk (Post)}
Hi, this will be possible with 1.33.0.0 release! Regards Edwin
Last updated: 2024-03-07

Memory Address Overlap ^{CODESYS Forge talk (Thread)}
Memory Address Overlap
Last updated: 2024-03-07

Post by sumit on Not able to see input data coming from eip adapter on codesys ^{CODESYS Forge talk (Post)}
dhumphries, I changed the datatype this time from BYTE to USINT (because that's what my adapter is sending: array of uint8_t). The text "New Help String" you saw in previous screenshots is just the description of the input/s (it can be anything). I also looked into the logs (see attached) for that ! sign next to the device, I found that connection is being timeout. I tried some suggestions from online such as increase the RPI but still got connection timeout issue, also by changing the datatype, I still don't see incoming data from the adapter, although its visible on wireshark. thanks,
Last updated: 2024-03-07

Post by comingback4u on Memory Address Overlap ^{CODESYS Forge talk (Post)}
Hello, We use a controller that comes with a bunch of predefined faults. These faults are considered active and historic. They are a 32 byte array but only take up 26 bytes of data. Because of this the historic faults start at address 26 instead of 31. Active faults variable take up address location 0 to 31. Historic faults variable take up address location 26 to 57. Because of this overlap I get an error that these overlap and it wont allow me to download to my controller. This isn't an issue in 3.5.5.4 but becomes an issue in newer version. Is there a way to turn this off? If I change the address location, the historic faults then become broken without doing some manipulation in the code. The software will build just fine. Thank you for your time.
Last updated: 2024-03-07

Post by sumit on Error IoDrvEthernetIP: Connection Failure. (16#1) How to solve ^{CODESYS Forge talk (Post)}
harinator, I am facing the the issue. Were you able to find the solution. thanks,
Last updated: 2024-03-07

Post by sumit on Not able to see input data coming from eip adapter on codesys ^{CODESYS Forge talk (Post)}
i-campbell, Thank you the suggestion, issue was the windows firewall not allowing the UDP traffic to pass through for EIP. thanks again
Last updated: 2024-03-07

Not able to see input data coming from eip adapter on codesys ^{CODESYS Forge talk (Thread)}
Not able to see input data coming from eip adapter on codesys
Last updated: 2024-03-07

Post by acc00 on Main Task cycle too long leading to PLC Fail ^{CODESYS Forge talk (Post)}
I have 2 Wago PFC200 PLC, running with Runtime SP19 Patch 5, with the Redundant application. The PLC communicates as Modbus Master with at this moment 15 Modbus Slaves -later there will be 28 in total- (Drives, Power management units,...). These devices are connected in 2 rings (1 ring of Drives, 1 ring of Power Management units), with 2 Managed Moxa Switches being part of the ring. Each PLC is connected to one of these switches. The issue I'm encountering is that the Cycle time of the Active PLC goes very high when I'm closing the Drive ring (simulating an issue on one Cabinet supply, resulting in that one Drive shut down, which can happen on field quite often). As a result of this long cycle, the PLC fails and goes to Exception, and the Passive PLC does not take control of the system. A normal cycle is around 30ms for the Main task, and a few ms for the Ethercat task. When I monitor with Profiler, I see that in this Maximum Cycle, the main Task is only taking 13ms, so I'm not sure where the PLC is hanging for so long. Is the remaining cycle time the Redundant management/sync or something else? Thank you in advance.
Last updated: 2024-03-08

OPC UA Client certificate for datasource link ^{CODESYS Forge talk (Thread)}
OPC UA Client certificate for datasource link
Last updated: 2024-03-08

Main Task cycle too long leading to PLC Fail ^{CODESYS Forge talk (Thread)}
Main Task cycle too long leading to PLC Fail
Last updated: 2024-03-08

Post by ryusoup on OPC UA Client certificate for datasource link ^{CODESYS Forge talk (Post)}
Hello, I'm looking for a way to set my client certificate, not one which self-signed cert generated with CODESYS, for OPC UA connection via datasource linking. Does anyone know how to archive that? BR,
Last updated: 2024-03-08

Post by bschraud on Zielsystem stimmt nicht mit dem verbundenen Gerät überein ^{CODESYS Forge talk (Post)}
Hallo, nach einer Umrüstung des RPi auf SSD habe ich den RPi neu aufgesetzt. Nach dem Installieren der Runtime (4.11.0.0 raspberry, all) auf den RPi kann ich das Gerät nicht mehr verbinden. Die Fehlermeldung lautet "Das gewählte Zielsystem 'Codesys Control for Raspberry Pi MC SL' stimmt nicht mit dem verbundenen Gerät 'Codesys Control for Raspberry Pi 64SL' überein. ID-Diskrepanz: Ausgewählt=000 0011, Online=0000 0012" Bei der Konfiguration des Laufzeitsystems kann man nur Multicore 64-bit (Aarch64) auswählen. Beim Aktualisieren des Gerätes im Gerätebaum habe ich Raspberry Pi MC SL in der Version 4.11.0.0 ausgewählt. Diese Version habe ich auch ausgewählt, weil nur diese Version für den produktiven Einsatz zugelassen ist. Die codesys Version ist frisch installiert, also 3.5.19.60 Vielen Dank für Ihre Hilfe
Last updated: 2024-03-08

Post by ph0010421 on Sending Sequential Modbus TCP Packets ^{CODESYS Forge talk (Post)}
Hello You'll need to write a proper sequence to send, then wait for confirmation, and then move on to the next step. Use the CASE statement in ST. It's perfect for creating a sequence.
Last updated: 2024-03-08

Post by eschwellinger on Zielsystem stimmt nicht mit dem verbundenen Gerät überein ^{CODESYS Forge talk (Post)}
in /etc/CODESYSControl.Usr.cfg [CmpRasPi] Architecture=aarch64 eintragen und im Projekt in CODESYS den Pi64 verwenden.
Last updated: 2024-03-08

Sending Sequential Modbus TCP Packets ^{CODESYS Forge talk (Thread)}
Sending Sequential Modbus TCP Packets
Last updated: 2024-03-08

Sort by relevance or date