Post by thysonfury on OPTO22 Groov Epic PR2 Modbus Comms Dropping out every 2 hours and 4 Mins ^{CODESYS Forge talk (Post)}
Hi after some assistance with an error on a Groov PR2 PLC. We have a few different communications set up as shown below: One Modbus TCP Slave Connection - ( Sending / Receiving Data from a PC ) Two Modbus TCP Master Connection - ( Reading Data from a UPS Panel and Reading Data Gas Chromatograph) One Modbus RTU Slave Connection 485 - (Reading Data from a fire and gas panel) One Modbus RTU Master Connection 485 - (Sending Data to a Telemetry Unit) All Licenses have been installed as per OPTO22 suggestions of the order below: Modbus TCP Master Modbus TCP Slave Modbus RTU Master Modbus RTU Slave When I check on License manager the RTU Master license seems to disappear on installing the RTU. (What ever reason I’ve been told this is “normal”). If I use Device License Read It will successfully read all the licenses correctly. Now the issue is every 2 hours and between 4. For what ever reason the communications seems to end and lock up for about 20 seconds. During this time even if I was logged into the PLC it would kick me off and I’d have to re type the password to enter. Most of the devices can handle this however the RTU flags up a communications failure at the SCADA and is raising alarms every 2 hours and 4 mins. We’ve had multiple people go through the code to check for anything obvious. Does anyone have any ideas?
Last updated: 2024-04-15

Post by anonymous on Hi, I try to send and receive data using a UDP connection via SysSocket 3.5.17.0. While sending data works fine, I have problems with the receiving part. I am able to capture the received data of client side in wireshark But unable to capture it on the codesys ^{CODESYS Forge talk (Post)}
Hi, I try to send and receive data using a UDP connection via SysSocket 3.5.17.0. While sending data works fine, I have problems with the receiving part.I am able to capture the data of client side in wireshark but i am unable to capture it in the codesys. Heres the below part of code of client side. PROGRAM POU_udpclient_program VAR istep : INT := 1;//step variable for state machine xStart: BOOL;// Flag to start the UDP protocol iecSocketId: syssocket_interfaces.RTS_IEC_HANDLE;//socket handle for receiving iecCreateResult: syssocket_interfaces.RTS_IEC_RESULT; ipAddr: syssocket.SOCKADDRESS;//Socket address structure for receiving sIpAddress : STRING := '192.168.0.2'; wPort: WORD:= 12346; iecConnectResult : syssocket_interfaces.RTS_IEC_RESULT;//connect paramters sDataRec : STRING[255];//Buffer for received data xiRecBytes : __XINT;//number of bytes received iecRecResult : syssocket_interfaces.RTS_IEC_RESULT;//receive data parameters iecCloseResult : syssocket_interfaces.RTS_IEC_RESULT; END_VAR syssocket.SysSockInetAddr(sIpAddress,ADR(ipAddr.sin_addr)); ipAddr.sin_family := syssocket.SOCKET_AF_INET; ipAddr.sin_port := syssocket.SysSockHtons(wPort); CASE istep OF 1: //create socket IF xStart THEN iecSocketId:= syssocket.SysSockCreate(syssocket.SOCKET_AF_INET,syssocket.SOCKET_DGRAM,syssocket.SOCKET_IPPROTO_IP,ADR(iecCreateResult)); IF iecSocketId = syssocket_interfaces.RTS_INVALID_HANDLE THEN xStart := FALSE; istep := 1; ELSE istep := 2; END_IF END_IF 2: //connect to socket server using setoption iecConnectResult := syssocket.SysSockSetOption(iecSocketId,syssocket.SOCKET_SOL,syssocket.SOCKET_SO_REUSEADDR,ADR(ipAddr),SIZEOF(ipAddr)); istep := 3; 3: //receive data xiRecBytes := syssocket.SysSockRecvFrom(iecSocketId,ADR(sDataRec),SIZEOF(sDataRec),0,ADR(ipAddr),SIZEOF(ipAddr),ADR(iecRecResult)); istep := 4; 4: //close socket iecCloseResult:= syssocket.SysSockClose(iecSocketId); xStart := FALSE; istep := 1; END_CASE
Last updated: 2024-06-03

Post by maldus512 on How to adapt Codesys Control SL to custom board ^{CODESYS Forge talk (Post)}
Hello everyone, I have been given the task to develop I/O drivers for a custom made, Linux based board to allow for Codesys applications to run and control the hardware. I have successfully installed Codesys Control SL for ARM/Linux and tested it with a simple demo application. Now I should start interfacing the runtime to the actual hardware; I should be able to interact with 2 RS485 serial ports, a few GPIOs and an I2C port, all of which already have the corresponding /dev/ interface in the Linux system. I am having trouble understanding how it should be approached. I have found sporadic references that fail to lead to a really comprehensive documentation. For example: The store page (https://store.codesys.com/en/codesys-control-for-linux-arm-sl-1.html#options) mentions a "runtime package" that should allow "Integration of existing C code" and "Usage of local I/Os", which seems exactly what I need to interact with custom peripherals. I have found no further reference to Codesys-C interpop. The Codesys Help page for the runtime package has a page on the "Development of Drivers" (https://content.helpme-codesys.com/en/CODESYS%20Control/rtsllinuxrbpdriverdevelopment.html) that suggests to either "Implement a function block" or "Implement I/O drivers". Those in turn lead to this page (https://forge.codesys.com/drv/io-drivers/doc/Generic/) which describes briefly an XML schema to describe new devices; unfortunately, it doesn't mention what to do with such a description (i.e. how does the runtime know about it) or how it is in any way connected to the actual hardware. Could anyone give me some pointers? I should also mention I have no prior experience with Codesys, so maybe I'm missing an obvious answer.
Last updated: 2024-08-09

Post by jeffg on ERROR: GetNetLinkSockAndInfoByMac(): could not open netlink socket: Too many open files ^{CODESYS Forge talk (Post)}
I just installed codesys runtime on a raspberry pi Cortex-A72 (ARM v8) 64-bit SoC @ 1.5GHz (Compute Module 4) I am running on Codesys control for raspberry pi 64 SL ver 4.13.0 and I keep getting a crash after about five to ten minutes. This program was running fine on a 32bit system with runtime 4.8 previously but they upgraded the panel PC cause it got smashed. Looking at the logs I see this error "ERROR: GetNetLinkSockAndInfoByMac(): could not open netlink socket: Too many open files" at the time of crash. I do have a UDP socket open for a serial to ethernet adapter and im wondering if maybe its opening a bunch of sockets and while receiving messages, Im not sending anything to the device only receiving. Below is the code used for the UDP VAR // Scale Comm fbPeerServer : NBS.UDP_Peer; ipAddress : NBS.IPv4Address; fbReceive : NBS.UDP_Receive; xPeerActiv : BOOL := TRUE; abyReceive : ARRAY [0..255] OF BYTE; sLastValidReceive : STRING(255); udiIndex : UDINT; END_VAR IF xPeerActiv AND NOT fbPeerServer.xBusy THEN ipAddress.SetInitialValue(ipAddress := gvlSettings.sIPAddres); fbPeerServer(xEnable := TRUE, itfIPAddress := ipAddress, uiPort := gvlSettings.uiPort); END_IF fbPeerServer(); fbReceive(xEnable := fbPeerServer.xBusy, itfPeer := fbPeerServer, pData := ADR(abyReceive), udiSize := SIZEOF(abyReceive)); IF fbReceive.udiCount > 0 THEN IF fbReceive.udiCount < SIZEOF(sLastValidReceive) THEN SysMem.SysMemCpy(pDest := ADR(sLastValidReceive), pSrc := ADR(abyReceive), udiCount := fbReceive.udiCount); // Set End of String sLastValidReceive[fbReceive.udiCount] := 0; END_IF END_IF If anyone as seen this I could really use some help figuring it out. I included the Log report
Last updated: 2024-09-19

Post by paulg on RasPi CAA Serial example - unexpected behavior during debug ^{CODESYS Forge talk (Post)}
I've trimmed down the CAA Serial Codesys example to only listen on one port but, when stepping through the Case structure in debug mode, it jumps out of the structure during a specific point in every scan (I'll point it out below after describing the setup and listing the code). I'm using a Pi 4 Model B, and I have an Arduino Nano Every plugged in via USB which is streaming the following serial message at 1 Hz: Time since opening connection: 1 s Time since opening connection: 2 s ...and so on. The Pi shows the Nano at /dev/ttyACM0 so I edited CODESYSControl_User.cfg to read: Linux.Devicefile=/dev/ttyACM The code in my PLC_PRG is (ignore some of the comments, I hadn't deleted them out from the original example): PROGRAM PLC_PRG VAR xStartTest : BOOL:= TRUE; iState : INT; xTestDone : BOOL;(* True, when the test was done succesfully *) (* Settings to communicate with the COM Port *) aCom1Params : ARRAY [1..7] OF COM.PARAMETER; como1 : COM.Open; comc1 : COM.Close; comw1 : COM.Write; comr1 : COM.Read; //sWrite : STRING := 'Test String!'; sRead : STRING(25); szRead : CAA.SIZE; xCom1OpenError : BOOL; xCom1CloseError : BOOL; xCom1WriteError : BOOL; xCom1ReadError : BOOL; END_VAR //This example shows the communication of two COM Ports with each other. //The first one writes a string of characters, which is read by the second one. //After successful execution, the two COM Ports are closed and the test is done. IF xStartTest THEN CASE iState OF 0: //The parameters are set for the COM Port aCom1Params[1].udiParameterId := COM.CAA_Parameter_Constants.udiPort; aCom1Params[1].udiValue := 1; // the correct Port should be adapted aCom1Params[2].udiParameterId := COM.CAA_Parameter_Constants.udiBaudrate; aCom1Params[2].udiValue := 115200; aCom1Params[3].udiParameterId := COM.CAA_Parameter_Constants.udiParity; aCom1Params[3].udiValue := INT_TO_UDINT(COM.PARITY.NONE); aCom1Params[4].udiParameterId := COM.CAA_Parameter_Constants.udiStopBits; aCom1Params[4].udiValue := INT_TO_UDINT(COM.STOPBIT.ONESTOPBIT); aCom1Params[5].udiParameterId := COM.CAA_Parameter_Constants.udiTimeout; aCom1Params[5].udiValue := 0; aCom1Params[6].udiParameterId := COM.CAA_Parameter_Constants.udiByteSize; aCom1Params[6].udiValue := 8; aCom1Params[7].udiParameterId := COM.CAA_Parameter_Constants.udiBinary; aCom1Params[7].udiValue := 0; //The first Port is opened with the given parameters como1(xExecute := TRUE, usiListLength:=SIZEOF(aCom1Params)/SIZEOF(COM.PARAMETER),pParameterList:= ADR(aCom1Params)); IF como1.xError THEN xCom1OpenError := TRUE; iState := 1000; END_IF //After a successful opening, the next state is reached IF como1.xDone THEN iState := 15; END_IF 15: // the reading process is started comr1(xExecute := TRUE,hCom:= como1.hCom, pBuffer:= ADR(sRead), szBuffer:= SIZEOF(sRead)); IF comr1.xError THEN xCom1ReadError := TRUE; END_IF //After completion the size of the written bytes are saved IF comr1.xDone OR comr1.xError THEN szRead := comr1.szSize; iState := 20; END_IF 20: // If everything was successful the ports are closed and the handles are released comc1(xExecute := TRUE,hCom:= como1.hCom); IF comc1.xError THEN xCom1CloseError := TRUE; END_IF IF comc1.xDone OR comc1.xError THEN iState := 25; END_IF 25: // The first port is closed and the used handle released xTestDone := TRUE; xStartTest := FALSE; iState := 0; como1(xExecute := FALSE); comw1(xExecute := FALSE); comc1(xExecute := FALSE); ELSE iState := 0; END_CASE END_IF I realize as I write this that the .udiPort should be 0 and not 1, but that shouldn't be causing the issue I'm seeing. I'm forcing xStartTest:=TRUE every scan so that I can step into each line and observe what's happening. What I see is that the port parameters are set and the port is opened with no errors, but the code jumps out of the case structure to the last line every time it reaches (and I step into) the iState:=15 line (at the end of the iState:=0 block). So every scan cycle it goes through the block for iState=0 and jumps out at the same spot. I'm a little new to PLC programming so I may be misunderstanding the flow, but shouldn't this case structure keep moving down in the same scan? If it only handles one case per scan, why doesn't the value of iState persist? Thanks! Update: I restarted the Codesys control today and I was then able to see an error for como1.eError of "WRONG_PARAMETER". I tried doing some digging and another post made me think I should add another line to CODESYSControl_User.cfg, so I now have: [SysCom] Linux.Devicefile=/dev/ttyACM portnum := COM.SysCom.SYS_COMPORT1 So now when I set .udiPort to 1, I get "NO_ERROR" but I also don't read anything from the port (i.e. szRead = 0 always). If I try setting the port to 0 (which I'm confused about, because I added a COMPORT1 line but the device shows on the Pi as ACM0), I get the "WRONG_PARAMETER" error again. Is there an easier way to troubleshoot the Pi and view what ports the Codesys runtime is actually able to see while the Pi is running?
Last updated: 2024-06-06

Post by dwpessoa on CNC Jumps G20 - SMC_NCInterpreter and long time to process ^{CODESYS Forge talk (Post)}
I am studying and developing a Softmotion+CNC system for a machine that executes multiple pieces. The G code program is written by the machine operator and each cycle execute 1 piece. The programs are large, exceeding 1000 lines and using up to 8 axes (X, Y, Z, A, B, C, P and Q). The machine needs to run cyclically, executing N pieces (selected by the Operator)... so I tested it using Looping and counters (G36 G37 and G20) and it worked, but it takes a long time to process, and the more pieces I need, the longer the processing time and this is totally impracticable. I found this solution which was very good, and for a few cycles it works well, but for 99999 pieces of a program with 1000 lines, it doesn't work very well... Another solution I tested is to maintain the interpolator with an automatic restart, that is, I load the program without looping (without G20) and give it another start as soon as it finishes. This partially resolved it, but there is still a delay in processing SMC_NCInterpreter in each restart :(. Another solution I thought of is to manually create the SMC_GEOINFO structure and then reuse it, avoinding the Interpreter, but reading the documentation and checking the structure filled by standard blocks, I noticed that there doesn't seem to be a "JUMP" function in the structure! In other words, the SMC_NCInterpreter actually keeps copying and copying the program section for each jump (G20)... If I repeat a 10-line program 1000 times, I will have a structure with more than 10000 lines... possibly this is the cause of take so long to process. Has anyone ever had a problem like this? I believe the same thing happens with typical applications with manipulator robots using Codesys in continuous cycles, and I would like to know if there is any solution, or even if I am misinterpreting the G20 question in SMC_GEOINFO. Thanks!
Last updated: 2023-09-20

Post by gilbert-mh on CAA net base TCP client cause PLC to crash - Kernel message : N0HZ_local_softirq_pending 80 ^{CODESYS Forge talk (Post)}
Hello all, I have been trying to implement a TCP client on a Festo PLC (CPX-E-CEC-M1) and it looks like it works well except that after some time (greatly varies between a few hours to more than 100h) my PLC crash. When I look into the log file the only thing I see is that before the crash happens a few kernel warnings : N0HZ_local_softirq_pending 80 and then the crash. I've looked into this warning and from what I could find on the net it seems that this is warning is triggered when the ethernet link is down. I've tried to correct this bug for quite some time and what I know is that : - The crash is caused by my TCP client, when I remove it from my code I see no crash - The crash happens more quickly the more the TCP client is used. - The time before the crash is not directly proportional to the number of communications or their size. But it looks like it is just more likely to happen if the client connect to the server at a higher frequency. - The precedent observation makes it seem unlikely that the crash is caused by some memory overflow because then the crash speed would be more proportional to the amount of data exchanged. SO from these observations, I believe that the crash could be caused by the PLC trying to connect to a server while there is some kind of issue with the ethernet link resulting in the PLC getting stuck in some indefinite state and making it crash. This still seems a bit unlikely to me because if the ethernet is down it simply shouldn't be able to contact the server and the communication would just fail which doesn't cause my PLC to crash. Has anyone encountered the same kind of problem (with the same kernel message) ? I am pretty sure the warning is not the direct cause of the crash but just an indicator that something is wrong with my PLC. Thanks in advance
Last updated: 2024-01-12

Post by mgabryel on Problems with CAN 2.0 comunication on Wago PLC (Codesys 3.5) ^{CODESYS Forge talk (Post)}
Hello, I am trying to program CAN Bus comunication on WAGO PLC (more precisely on WAGO Touch Monitor model TP600). I am using for this purpose library "WagoAppCanLayer2" from Wago company. My IDE for programming this device is CODESYS V3.5 SP19 Patch 2 + (64-bit). My program is written in Structured text using function blocks from previously mentioned library. Here is code of this program: 1) Variables declarations: PROGRAM PLC_PRG VAR oOpenInterface : WagoAppCanLayer2.FbCanL2Open :=( udiBaudrate := 125000 ); xInterfaceIsOpen : BOOL; sInterfaceInfo : STRING; oReceive : WagoAppCanLayer2.FbCanRx29BitFrame :=( xBufferMode := FALSE, wCanId := 16#181 ); xRecv : BOOL; sReceiveInfo : STRING; oSend : WagoAppCanLayer2.FbCanTx29BitFrame :=( dwCanId := 16#100, //was 16#201 xRtrFrame := FALSE ); xSend : BOOL; sSendInfo : STRING; oCanDiag : WagoAppCanLayer2.FbCanErrorInfo; xRst : BOOL; aSendData : ARRAY [1..8] OF BYTE; bSendLen : BYTE; TON_0 : TON; TON_1 : TON; END_VAR 2) Program body: oOpenInterface( xEnable := NOT xInterfaceIsOpen, I_Port := IoConfig_Globals.WAGO_CAN_LAYER2_DEVICE ); sInterfaceInfo := oOpenInterface.oStatus.GetDescription(); xInterfaceIsOpen S= oOpenInterface.xValid AND NOT oOpenInterface.xError; oReceive( xEnable := xInterfaceIsOpen, I_Port := IoConfig_Globals.WAGO_CAN_LAYER2_DEVICE, xRxTrigger := xRecv ); sReceiveInfo := oReceive.oStatus.GetDescription(); IF NOT xRecv THEN IF oReceive.bRxNBytes > 0 THEN oReceive.aRxBuffer[1]; oReceive.aRxBuffer[2]; oReceive.aRxBuffer[3]; oReceive.aRxBuffer[4]; oReceive.aRxBuffer[5]; oReceive.aRxBuffer[6]; oReceive.aRxBuffer[7]; oReceive.aRxBuffer[8]; END_IF xRecv := TRUE; END_IF aSendData[1] := 224; aSendData[2] := 13; aSendData[3] := 14; aSendData[4] := 15; aSendData[5] := 222; aSendData[6] := 13; aSendData[7] := 14; aSendData[8] := 15; bSendLen := 8; TON_0(IN:= NOT TON_1.Q, PT:= T#2S , Q=>xSend, ET=> ); TON_1(IN:= TON_0.Q, PT:= T#2S , Q=>, ET=> ); oSend( xEnable := xInterfaceIsOpen, I_Port := IoConfig_Globals.WAGO_CAN_LAYER2_DEVICE, aTxBuffer := aSendData, bTxNBytes := bSendLen, xTxTrigger := xSend ); sSendInfo := oSend.oStatus.GetDescription(); oCanDiag( xEnable := TRUE, I_Port := IoConfig_Globals.WAGO_CAN_LAYER2_DEVICE, xTriggerResetCounter := xRst, xValid=> , xError=> , oStatus=> , wBusState=> , wBusDiag=> , uiRxOverflowsL2=> , uiTxOverflowsL2=> , uiRxOverflows=> , uiMsgTimeouts=> , uiBusOffs=> , uiBusWarnings=> ); Program first opens comunication on CAN 2 device and then periodically try send one CAN data frame. After starting program CAN 2 interface is properly open. The xSend variable is toggling with period 2s. When program sends data an "Tx overflow" error appears. When I am watching CAN_H line on DSub 9 socket i am not able to see proper CAN frames - see screenshot attached to this message. Could somebody help me determine what is wrong with this program. Best regards
Last updated: 2024-08-02

Post by alex-at-xana on EThercat Dynamic configuration ^{CODESYS Forge talk (Post)}
Hi Everyone, For a fast monitoring system I am using Ethercat oversampling and timestamping inputs. As the customers has a lot of different configurations out in the field, we went for a dynamic Ethercat configuration. Already got the whole detection chain working but now I am stuck since two days in debugging the configuration. Here are my quesitons: I extended the dynamic config example for the EL3632 16#0E303052: //EL3632 pSlave^.SetDCSettings(TRUE,TRUE,80,80,TRUE,4000,0,0); pSlave^.AddSyncManager(16#1000,128,16#26,TRUE,3); pSlave^.AddSyncManager(16#1080,128,16#22,TRUE,2); pSlave^.AddSyncManager(16#1100,0,16#4,TRUE,1); pSlave^.AddSyncManager(16#1110,214,16#20,TRUE,0); pSlave^.AddFMMU(0,214,0,7,16#1110,0,1,1); pSlave^.AddFMMU(0,1,0,0,16#80D,0,1,1); xKnown := TRUE; This leads to a PLL Error for these devices. I double and triple checked the configuraton, but cannot find the issue. There seems to be one difference: the config dialog creates a startup parameter: 16#10F3:16#05, Name: Command_0, Value:0. Bitlen: 16, Stop on fault: false, jumpt at fault: false: next line: 0 a) I do not find information on how to set this in my code. Can you help me there? b) Without trying to set the value, I get a PLL error for these devices in the master log. Is the config wrong? c) Do I need to set the Master to Autoconfigure or Manual? I used autoconfigure for my tests. The stack creates input data addresses for the slaves input data range (pSlaves[i].InputData) which are different from those created when I use the Engineering tools dialogs to configure Ethercat. Specifically, the addresses seem to be aligned at 16 byte boundaries when they are created using the engineering tool, but may appear at uneven addresses when I use the script in dynamic config. I did not try to access ULINT at uneven addresses yet, but I am suspecting this may be a problem. Do I need to manually align the addresses ? Any help is appreciated...
Last updated: 2024-09-10

Post by thn-power on Updating OPC UA Core Nodeset on PLS ^{CODESYS Forge talk (Post)}
Hi After much trail and error I think I found the root cause to my OPC UA problem. The problem is that I cannot manage to build and download a program with a a custom OPC UA Information model. We use a Weidmueller WL2000 PLS, but the problem also exsist on the Win V3 PLC. Our custom information model is based on the latest versions of the OPC UA Core Nodeset v 1.05.03 (2023-09-20) and UA/DI nodeset 1.04.0 (2022-11-03) Those nodesets are installed in the Codesys Information Model Repository (3.5.19.6) However, when trying to build I get the following error. [ERROR] Untitled1: Communication Manager [Device: PLC Logic: Application]: The information model http://opcfoundation.org/UA/ is required by http://bos.org/ with a minimal publication date from 15.12.2023 but the device has only a model from 15.09.2021 installed. Probably the information model from 15.09.2021 is missing in the information model repository. [ERROR] Untitled1: Communication Manager [Device: PLC Logic: Application]: The information model http://opcfoundation.org/UA/DI/ is required by http://bos.org/ with a minimal publication date from 03.11.2022 but the device has only a model from 09.03.2021 installed. Probably the information model from 09.03.2021 is missing in the information model repository. Build complete -- 2 errors, 1 warnings : No download possible I think the problem is that the UA Core nodeset is implemented in the PLC firmware (at least that in Siemens S7), and that only includes the "old" nodeset from 2021-09-21 etc. So the question is, how (or if?) can I transfer the new nodeset to the PLS? I have created separate Information models under Communication manager with the newer code nodesets (UA and DI). But it seems that the compiler does not recognize them being excising, neither in the Codesys IDE or on the PLC. Would have guessed that this is a common issue, sine many manufacturers use the latest versions of the OPC UA standard, and that it would be a solution to the problem.
Last updated: 2024-09-20

Post by mondinmr on Frustration-Fueled Feedback on Project File Management and Git Integration ^{CODESYS Forge talk (Post)}
Good day, I’m writing this message out of frustration regarding the current way project files are saved as encrypted XML and single-file format in CODESYS. I find this approach to be quite tedious for several reasons: Limited Access to Structured Text: Not being able to access Structured Text (ST) externally makes it impossible to work with alternative editors like VSCode. Tools like VSCode are incredibly responsive and feature advanced systems such as GitHub Copilot, which would be a real game-changer when working with ST IEC. While CODESYS works well for small code snippets or debugging, when the codebase grows, switching to VSCode to boost productivity becomes essential, and copy-pasting between environments is a cumbersome workaround. Poor Integration with Git: This file format also makes it very difficult to integrate effectively with Git. I have tested the internal demo, but for advanced merges, it is unusable. Without properly formatted plain text, it’s impossible to leverage the vast ecosystem of external tools around Git that allow smooth merges in heterogeneous teams. File Corruption on Network Drives: I often work from multiple locations with shared network drives. When the development environment saves a file and something goes wrong midway (which can occasionally happen when using VPNs and network drives), the entire project becomes irrecoverable. There’s no way to cancel the save process, and the development environment freezes. This has happened to me at least four times over the past two weeks, and one of those incidents cost me an entire day of work. All of this is particularly disappointing because I truly believe that the libraries, runtime, and overall work done by CODESYS are exceptional. I find it fantastic that there is a platform allowing development of PLCs and control systems using OOP, which is a huge advantage in modern control engineering. I apologize for the rant, but this issue has been extremely frustrating. Best regards.
Last updated: 2024-10-15

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

Post by scoob on ModbusFB - Slow Response Time ^{CODESYS Forge talk (Post)}
Hello, I have been trying to use the ModbusFB functions so I can put some code into libraries, but it seems to be very slow for me. I have a Modbus device with 100ms registers. I previously setup 10 channels in the 'traditional' Modbus Slave with channels and mappings - and set a cyclic trigger at 100ms - this worked fine. I then tried the ModbusFB example, and setup reading the same 10 blocks of modbus addresses, copying the example and putting all of the requests into an array and triggering the requests sequentially. I timed how long the requests are taking to get round to each one, and it is around 1s 450ms. How do I speed this up to match the cyclic time? IF NOT(init) THEN init := TRUE; // Set the required IP address: ipAddress[0] := 192; ipAddress[1] := 168; ipAddress[2] := 1; ipAddress[3] := 10; // Pass the required IP address to the clinet FB: client_NetworkSwitch.aIPaddr := ipAddress; client_NetworkSwitch.udiLogOptions := (ModbusFB.LoggingOptions.ClientConnectDisconnect OR ModbusFB.LoggingOptions.ClientReceivedValidReplies); // Try to connect the client client_NetworkSwitch(xConnect:=TRUE); // Configure all the channels to read connecting them to the client: portStatus_Request(rClient := client_NetworkSwitch, uiStartItem := 4096, uiQuantity := 32, pData := ADR(portStatus), udiReplyTimeout := udiReplyTimeout); portSpeed_Request(rClient := client_NetworkSwitch, uiStartItem := 4352, uiQuantity := 32, pData := ADR(portSpeed)); flowControl_Request(rClient := client_NetworkSwitch, uiStartItem := 4608, uiQuantity := 32, pData := ADR(flowControl)); linkUpCounter_Request(rClient := client_NetworkSwitch, uiStartItem := 5888, uiQuantity := 32, pData := ADR(linkUpCounter)); txPacketCounter1_Request(rClient := client_NetworkSwitch, uiStartItem := 8192, uiQuantity := 100, pData := ADR(txPacketCounter1)); txPacketCounter2_Request(rClient := client_NetworkSwitch, uiStartItem := 8292, uiQuantity := 28, pData := ADR(txPacketCounter2)); rxPacketCounter1_Request(rClient := client_NetworkSwitch, uiStartItem := 8448, uiQuantity := 100, pData := ADR(rxPacketCounter1)); rxPacketCounter2_Request(rClient := client_NetworkSwitch, uiStartItem := 8548, uiQuantity := 28, pData := ADR(rxPacketCounter2)); txErrors_Request(rClient := client_NetworkSwitch, uiStartItem := 8704, uiQuantity := 64, pData := ADR(txErrors)); rxErrors_Request(rClient := client_NetworkSwitch, uiStartItem := 8960, uiQuantity := 64, pData := ADR(rxErrors)); // Trigger all client requests initially FOR clientRequestsCnt := 0 TO (SIZEOF(clientRequests)/SIZEOF(clientRequests[0]))-1 DO pClientRequest := clientRequests[clientRequestsCnt]; pClientRequest^.xExecute := TRUE; END_FOR // Prepare sequential trigger / control of client requests. clientRequestsCnt := 0; pClientRequest := clientRequests[clientRequestsCnt]; END_IF // Call the client to do request processing: client_NetworkSwitch(); // Now we trigger client request sequentially ... IF NOT pClientRequest^.xExecute AND NOT pClientRequest^.xDone AND run AND client_NetworkSwitch.xConnected THEN pClientRequest^.xExecute := TRUE; END_IF // .. and check result/error IF pClientRequest^.xExecute AND run AND client_NetworkSwitch.xConnected THEN IF pClientRequest^.xDone THEN // Prepare next trigger of client request (a rising edge of xExecute) pClientRequest^.xExecute := FALSE; IF clientRequestsCnt < SIZEOF(clientRequests)/SIZEOF(clientRequests[0])-1 THEN // next client request clientRequestsCnt := clientRequestsCnt + 1; ELSE clientRequestsIterationCounter := clientRequestsIterationCounter + 1; clientRequestsCnt := 0; END_IF pClientRequest := clientRequests[clientRequestsCnt]; END_IF END_IF I did try a semi-coded way using the IoDrvModbusTCP library, and setting the slave com settings, then 10 commands and 10 requests, then using a TP on xDone as a pause, before triggering another request - this is time the delay is around 120ms - so the device is fine with the speed, just something I am doing wrong in the ModbusFB method I am sure.
Last updated: 2024-04-26

Post by mubeta on Some 'pathetic' errors in SoftMotion program ^{CODESYS Forge talk (Post)}
Hello everyone, I have a very simple program for the process, but it's driving me crazy and I can't see the problems I'm left with: Short topological description: Dual Core Berghof controller with softmotion runtime version 3.5.19.30; Two axes with servodrive on canopen bus, clocked distributed from master; Ethercat I/O node; 2 ms ethercat task, 2 ms canopen bus cycle time; I/O objects of the canopen master and canopen drives connected to the ethercat task cycle; Problem 1: Two separate programs each manage their own axis and drive, with separate state machines. A first axis moves primarily in velocity, except having to position itself absolutely at a predetermined point at the end of the job; the second axis, on the other hand, is a paper unwinder that changes, for each job cycle, from actions in absolute, relative, and cam displacement with the master axis. Well, the state machine of both axes was written in such a way as to call running the useful FB and change it on state change in this way: CASE i_stateMachine OF 0: o_Power(Enable := TRUE, bRegulatorOn := FALSE, bDriveStart := FALSE, Axis := o_PaperUnwinderAxis); o_MoveAbs(Execute := FALSE, Axis := o_PaperUnwinderAxis); o_MoveRel(Execute := FALSE, Axis := o_PaperUnwinderAxis); o_CamSelect(Execute := FALSE, Master := o_MachineAxis, Slave := o_PaperUnwinderAxis, CamTable := cam_PaperUnwinder); o_CamIn(Execute := FALSE, Master := MachineEncoder, Slave := o_PaperUnwinderAxis); o_CamOut(Execute := FALSE, Slave := o_PaperUnwinderAxis); o_SetPosition(Execute := FALSE, Axis := o_PaperUnwinderAxis); IF ... THEN i_StateMachine := 10; END_IF; 10: o_Power( Enable := TRUE, bRegulatorOn := TRUE, bDriveStart := TRUE, Axis := o_PaperUnwinderAxis ); IF o_Power.Status THEN i_StateMachine := 20; END_IF; 20: (* Avanzamento carta *) o_MoveAbs( Execute := TRUE, Position := o_Somewhere, Velocity := 25.0, Acceleration := 3666.7, Deceleration := 3666.7, Jerk := 48000.0, Direction := MC_DIRECTION.positive, Axis := o_PaperUnwinderAxis ); IF o_MoveAbs.Done THEN o_MoveAbs(Execute := FALSE, Axis := o_PaperUnwinderAxis); i_StateMachine := 30; END_IF 30: d_HomingPosition := ...; o_SetPosition( Execute := TRUE, Position := d_HomingPosition, Mode := FALSE, Axis := o_PaperUnwinderAxis ); (* ... *) IF o_SetPosition.Done = TRUE THEN o_SetPosition(Execute := FALSE, Axis := o_PaperUnwinderAxis ); o_LogServer.Append(sMessage := '...', lscClass := LOGSERVER_CLASS.ALWAYS, sdt := o_CommonsMgrData.systime.sdtLocal); i_StateMachine := 40; END_IF; 50: ... The code above is a sketchy example of what I wanted to write. But it gives me a spot problem: in some, the state change results in a drive error, which is unrecoverable except with a reinitialization via SM3_ReinitDrive(). Things are improved a little if in the program I always run the call of all softmotion blocks in this way: o_Power(Axis := o_PaperUnwinderAxis); o_Jog(Axis := o_PaperUnwinderAxis); o_Halt(Axis := o_PaperUnwinderAxis); o_MoveAbs(Axis := o_PaperUnwinderAxis); o_MoveRel(Axis := o_PaperUnwinderAxis); o_CamIn(Master := MachineEncoder, Slave := o_PaperUnwinderAxis); o_CamOut(Slave := o_PaperUnwinderAxis); If I don't execute all the calls of all the motion FBs used, when exchanging machine state often (but not always), the axis goes into error with event id THE_FB_WASNT_CALL... Done a little diagnostics it seems that the FBs return the bDone, before they are completely terminated. I tried doing the machine state exchange not with the bDone bit of the FBs, but with the 'standstill' state of the axis. It didn't seem to change anything. Problem 2: During the use SM3_ReinitDrive() I get the erro in the log: "NetID 0: SDO read error for object 16#607C..." Assuming that the device involved it's one of the two servodrive, (no others device are present in the network), I don't found any object 0x607C in the 'possible object list in/out' of the two drive, and I don't understand where this object can be listed. So any ideas and suggestions regarding these two issues will be very, very welcome. If you need the source project, I am willing to send it.
Last updated: 2024-07-17

Post by r-niedermayer on OPC UA subscriber not operational ^{CODESYS Forge talk (Post)}
Hi. As far as projects in "old version"s are concerned, these can be upgraded to newer versions at any time. To do this, the device must be updated accordingly and the copilers and library versions must be adapted. You can find instructions on how to proceed in the online help/FAQ: https://content.helpme-codesys.com/en/CODESYS%20Development%20System/_cds_changing_compiler_version.html https://content.helpme-codesys.com/en/CODESYS%20Development%20System/_cds_cmd_update_device.html See also 4.3.22.4 "How to open an Example Project" within the following pdf for more details on the single steps: https://forge.codesys.com/lib/counit/tickets/_discuss/thread/3e991befbc/ca97/attachment/Public%20FAQ-v13-20240610_075228.pdf Regaring your OPCUA connection state always showing just "DISABLED", without knowing both sides of the assembly in detail, one can only approach the problem theoretically. We can give a chekclist on how to proceed: Fist, please recheck the communication settings in the OPC UA connection function block to ensure that the server URL, endpoint URL, and other settings are correct and match the configuration of the OPC UA server. Verify that the OPC UA server is running and accessible. -You can try to connect to the OPC UA server using a separate client, such as UAExpert, to ensure that the issue is not related to the OPC UA server itself. Test the security settings in the OPC UA connection function block to ensure that the correct security policy and certificate are selected. If you are using a dynamic connection to the OPC UA server, probe that the connection settings are correctly configured and that the OPC UA client is able to establish a connection to the OPC UA server. Also, please loock into the log files for any errors related to the OPC UA connection function block, these should be listet there. The log files may also provide additional information about the issue and help you to further troubleshoot the problem. FYI - Please see https://content.helpme-codesys.com/en/CODESYS%20Communication/_cds_obj_data_source_communication_opc_ua_server.html: Her you can finde the Communication settings via OPC UA Server -> layout Browse Live Server: The client connects to the server and detects the existing variables and types. From Information Model The client reads the data structure (layout) of the OPC UA Server from the information model set here and as a result receives the information about available variables and types. A connection to the server is not required. The list contains the information models installed in the OPC UA Information Model Repository. "Read Connection" Settings from IEC Variable (option set): - The connection settings used by the device are not read here from the dialog, but at runtime from the IEC variable specified here. - For this possibility, please see the Using a Dynamic Connection to an OPC UA Server (https://content.helpme-codesys.com/en/CODESYS%20Communication/_comm_use_dynamic_opc_ua_server_comm_settings.html) The settings for the communication of a Client-data source to an OPC UA Server can also be dynamically configured from the IEC code and can also be changed at runtime. For such a purpose, a structure is available in the DatasourceOpcUAServer library (For a description of the OPC UA Server, there is one included in the standard installation of CODESYS, https://content.helpme-codesys.com/en/CODESYS%20Communication/_cds_encrypt_communication_data_sources_opc_ua_client.html)
Last updated: 2024-11-04

Sort by relevance or date