Post by tcarlbom on Read tag values using external program ^{CODESYS Forge talk (Post)}
This is my first time posting in this forum and I am new to codesys. I am a fullstack developer and I am trying to figure out how the following. What would be the best approach to create a own/custom tag browser? Either directly in codesys ide or using a separate custom program (perhaps a winforms application). 1.a. Shall I parse the .project xml file to get a list of all tags in the project? 1b. Shall I use python scripting in codesys ide to get a list of tags? Once one have selected some tags. These tags shall be exposed to a python program which will be acting as a edge computer. It’s fine to be able to import a file. 2a. I found a library called codesys plchandler which (as I understand) acts a rest api server. Is this correct? If so, can I query the api from a custom python script, ie can query what tags exist in project and or read tag values? My research so far. From earlier projects I know that using opc ua would be perfect for this but from my opinion it’s bloating the plc since it’s resource intensive. So opc ua is not an option. Codesys automation server is neat. But I don’t want to rely on some cloud services and subscription based pricing. There seem to be several interesting codesys libraries like mqtt, tcp server and NVL sender which would help me expose plc tags. But all have a common problem. One have to manually write what tags which will be used in these function blocks. I want a similar experience like “selecting” tags in the opc ua or the codesys tracing, ie a tag browser.
Last updated: 2024-06-28

Post by youness on No source code available (cip object) ^{CODESYS Forge talk (Post)}
Hi yotaro, hope your problem was resolved. I had the same, but with an other library title. This exception is not detected during compilation, but rather at a given position in the program (when switching to a given visualization). Although the exception is generated at this point, it does not involve the visualization in question. This error is due to one of 3 reasons: 1) A division by zero somewhere: The program is able to detect divisions by zero at compile time. But in the case of a variable, which takes a valid value at init and changes to 0 at a later stage. 2) An invalid pointer: (either because it has a value of 0, or because it points outside the memory reserved for the program) is being dereferenced. Locate any pointers or interfaces you have in the code and check them - you should also be wary of mixing inline modifications and pointers. 3) Array overflow: Generally when a processing operation is executed outside the array's definition range. Example: a write loop with n iterations is executed on an array of dimmension n-1. On the other hand, the error message may not appear. In the latter case, the error may have fatal consequences, as the overflow has induced writing to potentially forbidden memory areas. This problem can be explained by the fact that it's not always the adjacent memory areas of PLC_PRG that are overwritten, but the memory areas that are randomly allocated to the array during compilation. In this case, however, there is no entry in the log, so you need to integrate the "Implicit Check function", which checks the line of code generating the error. To integrate this functions, click on Application --> POU for implicit controls Regards,
Last updated: 2024-07-16

Post by fmon on Modbus : dis- / re-connect cable: modbus does not re-start ^{CODESYS Forge talk (Post)}
Hello, I am using codesys Modbus TCP client (4.4.0.0) to communicate with a python modbus server (package pyModbusTCP). I first start my python server on the distant machine. After a fresh codesys compilation, a plc connection/transfer and a PLC run, the modbus connection is OK. Every time in this context the connection is created correctly. When I shut down the server, the modbus connection falls, that is normal. When I restart the python server, impossible to recreate the modbus connexion. With the client autoreconnection, I see on my server that the client tries to connect but unsuccesfully. I have the following message : DEBUG:pyModbusTCP.server:accept new connection from ClientInfo(address='192.168.1.20', port=33476) DEBUG:pyModbusTCP.server:Exception during request handling: NetworkError('recv return null') I tried to stop the codesys client and to restart it with these commands : Modbus_TCP_Client.xStop := True; // Or False Modbus_TCP_Client.Enable := True; // Or False Modbus_TCP_Server.Enable := True; // Or False I tried to confirm the error manually to force reconnection with: Modbus_TCP_Server_Motors.xConfirmError := TRUE; I tried also this command to STOP/RESET/START client and server (codesys side) but nothing happens : status_client := Modbus_TCP_Client.SetCommunicationState(eRequestedState := DED.DEVICE_TRANSITION_STATE.STOP); // .RESET & .START The answer of this function when executed is "status_client = NOT_SUPPORTED" It seems that is a socket problem, but I do not understand if it is on the client or server side. I tried a modbus simulator called "ananas.exe" and the result is the same. Impossible to get a modbus reconnection. What is different at the first connection and at a reconnection attempt ? Thanks for your help
Last updated: 2025-03-14

Post by fmon on Modbus TCP client reconnection problem ^{CODESYS Forge talk (Post)}
Hello, I am using codesys Modbus TCP client (4.4.0.0) to communicate with a python modbus server (package pyModbusTCP). I first start my python server on the distant machine. After a fresh codesys compilation, a plc connection/transfer and a PLC run, the modbus connection is OK. Every time in this context the connection is created correctly. When I shut down the server, the modbus connection falls, that is normal. When I restart the python server, impossible to recreate the modbus connexion. With the client autoreconnection, I see on my server that the client tries to connect but unsuccesfully. I have the following message : DEBUG:pyModbusTCP.server:accept new connection from ClientInfo(address='192.168.1.20', port=33476) DEBUG:pyModbusTCP.server:Exception during request handling: NetworkError('recv return null') I tried to stop the codesys client and to restart it with these commands : Modbus_TCP_Client.xStop := True; // Or False Modbus_TCP_Client.Enable := True; // Or False Modbus_TCP_Server.Enable := True; // Or False I tried to confirm the error manually to force reconnection with: Modbus_TCP_Server_Motors.xConfirmError := TRUE; I tried also this command to STOP/RESET/START client and server (codesys side) but nothing happens : status_client := Modbus_TCP_Client.SetCommunicationState(eRequestedState := DED.DEVICE_TRANSITION_STATE.STOP); // .RESET & .START The answer of this function when executed is "status_client = NOT_SUPPORTED". Is it normal ? It seems that is a socket problem, but I do not understand if it is on the client or server side. I tried a modbus simulator called "ananas.exe" and the result is the same. Impossible to get a modbus client reconnection. What is different at the first client connection and at a reconnection attempt ? Thanks for your help
Last updated: 2025-03-17

Post by laurits on Max lines of code, codesys CNC ? ^{CODESYS Forge talk (Post)}
Hi, yes now its working, to get "QUEUE.bFull" to work, I've had to set the "QUEUE.nNumReservedEntries" to 3. (I tried different values here, only effect for larger values i can see is the the queue capacity gets smaller.) I've noticed the movement is slowing down when it reaches the end of the "fill Up", must be because of the "checkVelocity" can only see the current "QUEUE". Any way of solving this ? BUF : ARRAY[0..20000] OF SMC_GEOINFO; xp : ARRAY[1..100000] OF REAL; yp : ARRAY[1..100000] OF REAL; CASE iState OF 000: IF R_TRIG_bStart.Q THEN iState := iState + 1; END_IF bReady := FALSE; //initialize Queue GEO.dT1:=0; GEO.dT2:=1; GEO.dToolRadius := 0; GEO.dVel := 15000; GEO.dVelEnd := 15000; GEO.dAccel := 2000; GEO.dDecel := 2000; GEO.iObjNo := 0; GEO.piDestPos.dX := 0; GEO.piDestPos.dY := 0; QUEUE.bEndOfList := FALSE; QUEUE.nPastMarker := -1; QUEUE.nWritePos := 0; QUEUE.pbyBuffer := ADR(BUF[0]); n := 0; sMC_CheckVelocities(bExecute:= FALSE); SM3_CNC.SMC_SetQueueCapacity(ADR(QUEUE), SIZEOF(BUF)); QUEUE.nNumReservedEntries := 3; 001: FOR i := 1 TO SIZEOF(xp)/SIZEOF(xp[1]) DO xp[i] := UDINT_TO_REAL(i) * 0.01; yp[i] := UDINT_TO_REAL(i) * 0.01; END_FOR iState := iState + 1; 002: WHILE NOT QUEUE.bFull DO // when the Queue is full, wait until it has been processed by the following FBs n := n + 1; GEO.iSourceLine_No := n; GEO.piStartPos := GEO.piDestPos; // copy last destination GEO.iMoveType := LIN; // generate linear movement GEO.iObjNo := GEO.iObjNo + 1; // calculate number GEO.piDestPos.dX := xp[n]; // generate position GEO.piDestPos.dY := yp[n]; SMC_CalcLengthGeo(pg := ADR(GEO)); // calculate length of object with the help of the standard function SMC_AppendObj(poq:=ADR(QUEUE), pgi:=ADR(GEO)); //append object to queue IF n = UDINT_TO_DINT( SIZEOF(xp)/SIZEOF(xp[1])) THEN // all target positions processed QUEUE.bEndOfList := TRUE; iState := iState + 1; EXIT; END_IF END_WHILE sMC_CheckVelocities(bExecute:= TRUE, poqDataIn:= ADR(QUEUE)); bReady := TRUE; // Send message to smc_interpolator to start 003:
Last updated: 2025-06-04

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 rkohser on Scripted Git clone / checkout being blocked by "Project Environment" popup ^{CODESYS Forge talk (Post)}
Hi, I am trying to build a CI/CD pipeline around our codesys projects. The only entry point if the git url and branch, as we do not put our project file under source control, so we needed to find a way to git clone from the python scripting engine. This is currently how we do this : system.commands["Git", "Clone"].execute( "ProjectLocation=" + project_dir, "ProjectName=" + project_file_name, "RemoteUrl=" + project_git_remote_url, "GitProjectStoragePath=" + project_git_local_dir, ) system.commands["Git", "Checkout", "Branch"].execute( "PrimaryProjectHandle=0", "BranchName=origin/" + project_git_branch ) This works fine, except that, depending on the environment and the project, the "Project Environment" popup gets displayed to suggest for some updates, and waits for a user interaction, even with the "--noUI" flag injected as parameter. I investigated the VersionUpdateFlags, but the problem is that the git clone is an atomic operation that clones and directly opens the generated project without the possibility to inject any updateFlags argument (only used in the ScripProjects.open() function. I also tried to simulate some keyboard events acknowledge the window from script but I did not find the right location for the SendKeys statement, I think before the git clone call is too early and after is too late. So I am wondering if there would be some other way to do that. Is there some more proper scripting api for the git add on ? Is there a global configuration of the VersionUpdateFlags that would allow the popup to be disabled outside from any project context ? Is there some way to automatically acknowledge this kind of messages in a "--noUI" mode ? What do you suggest ? Thanks for your help, Roland Edit : I managed to solve my problem by following these steps in my pipeline : - create a template of a project and opt file preconfigured not to open the popup - open this project - initialize an empty git repo - add the remote, fetch and checkout the needed branch -> no popup is displayed, hourra Edit2 : The initial question was raised on a CODESYS V3.5 SP18 Patch 2 profile. Since CODESYS 3.5.19.30 a scripting API is available for Codesys Git that allows cloning a project with the support of VersionUpdateFlags https://content.helpme-codesys.com/en/CODESYS%20Git/_git_using_scripting.html
Last updated: 2024-01-19

Post by greenwood on CODESYS Control Raspberry Pi mit Servotreiber T6 von StepperOnline ^{CODESYS Forge talk (Post)}
Hallo, ich versuche, eine Modbus-RTU-Kommunikation zwischen meinem Raspberry Pi mit CODESYS Control für Raspberry Pi 64 SL und einem Servotreiber von StepperOnline, Typ T6, herzustellen. Die Verbindung ist wie folgt: RJ45-Stecker am Servotreiber -> Kabel mit RJ45 an einem Ende und USB-A-Stecker am anderen Ende -> Seriell-zu-USB-Konverter -> Raspberry Pi. Der Seriell-zu-USB-Konverter und die Kabel habe ich zusammen mit dem Motor und Treiber von StepperOnline gekauft und sie sind dafür gedacht, den Servotreiber mit einem Computer zu verbinden, auf dem deren Setup-Software läuft. dmesg | grep tty auf dem Pi sagt mir, dass der USB-zu-Seriell-Konverter auf ttyusb0 ist. Ich weiß nicht, wie man das in einen COM-Port übersetzt, ich habe COM 1 genommen. Ich habe ein Projekt in Codesys erstellt und ein Modbus_COM-Gerät hinzugefügt, einen Modbus_Master_COM_Port und einen Modbus_Slave_COM_Port angehängt. Auf der Registerkarte "Allgemein" des Modbus_COM habe ich die folgenden Werte eingestellt: Slave address 1 Baud rate 9600 Parity None Data bits 8 Stop bits 2 Ich habe den Servotreiber auf die gleichen Werte eingestellt. (Ich habe auch andere Werte getestet, aber mit dem gleichen Ergebnis). Auf der Registerkarte "Modbus Slave Channel" des Modbus_Slave_COM_Port habe ich einen Kanal hinzugefügt und die folgenden Werte eingetragen: Access type Read Holding Registers (Function Code 3) Read Register offset 0x0000 Length 1 Ich habe noch keinen Code geschrieben, weil ich noch nicht herausgefunden habe, wie man die Kommunikation programmiert. Wenn ich das Projekt zum Raspberry Pi herunterlade scheint der Modbus_Master_COM_Port zu laufen (grünes Symbol), aber der Modbus_Slave_COM_Port nicht (rotes Dreiecksymbol). Wenn ich einen anderen COM-Port eintrage, haben sowohl der Master als auch der Slave das rote Dreiecksymbol. Ich habe dies auch mit meinem Windows-PC unter Verwendung von Codesys Control Win 64 versucht und die gleichen Ergebnisse bekommen. Ich wäre dankbar für jede Hilfe oder Tipps, wie ich den Grund dafür herausfinden kann, warum der Servotreiberreiber nicht reagiert.
Last updated: 2024-05-31

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 patrik on Wish: CODESYSControl.cfg - again ^{CODESYS Forge talk (Post)}
Really good post. I hope that it gets seen by CoDeSys staff. I often find the documentation lacking when it comes to using CoDeSys in more complex ways. If using standard "basic PLC functionality", then it's fine and functions are documented in a sufficient way. Once you go outside of that bubble then I find the documentation not enough. CODESYSControl.cfg is a good example of this. And why isn't more of this integrated in the IDE. like changing port of the webserver. Why is it hidden in this file and not accessible through the IDE. It feels like a layer of complexity purposely left in so you don't change it if you don't know what you are doing. Like the argument is if you have the know-how to find the file you have the know-how to edit it. I find the documentation lacking when it comes to more complex libraries too. Like the element collections library. there is parameters I still don't quite know what they do. I can't find any documentation about them. There is an example project to download from CoDeSys so you can see how you are supposed to set your factories up. I leave some parameters like it is in the example. Should I? I don't know. Does it work. Yes. But I could perhaps create memory leaks if I get something wrong and I don't see that until way later. In the create method of your element factory you have a function called __vfinit and you just have to accept that it works. Why can't I get insight in what it does through documentation? Don't CoDeSys want us to know how these work so we can't use them to accidentally break something? I find the error logging lacking too. I've had the CoDeSys service crash but it doesn't say why. I've seen windows noticing the crash but no error code was sent or error message. Also in my current issue where the application fails to start after power outage. I can see in the log that it fails to load retain in the application as one log entry and application failing to start as another. But why? Why does loading the retain fail? give me more information! Is it just a skill issue with me? I don't know. If it is then I'd still want CoDeSys to step up their game when it comes to documentation. I'm sorry if a lot of frustration comes though in this post. I really like the product and what I can do with it compared to other PLC brands.
Last updated: 2024-11-21

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 darko7417 on When running as a service, CodesysControl doesn't write log files to the disk (and other CmpLog related issuess) ^{CODESYS Forge talk (Post)}
I run CODESYS runtime as a service and use CmpLog (the LogAdd2 function) to log different events to a file. I have done this many times before on various projects and hardware, and it works fine. On this particular system, I have CODESYS 3.5.20.40 running on a Windows 11 PC. The CODESYSControlService autostarts (with Local System credentials, the default), and the application runs fine. However, the configuration file is not read (or at least not the one that should be, or not the CmpLog section), and log files are not written to the disk. I would be thankful if anyone knew why this is happening and how to fix it. A note to CODESYS people: you must provide more information on the codesys configuration file, CODESYSControlService.exe and other major components and system behaviour. You created the service and various features (i.e. logging), but haven't explained how they work, which, in my opinion, is below standard for industrial automation software. These are my observations: - When running as a service, the config file is not read (none of them), or at least the CmpLog section is not read. I checked the log using Codesys IDE, and the CmpLog parameters are not the ones I have set in any of the config files. Which CmpLog config values does the service use, and where does it read them from? I have no idea, but it's not the config files. Here are the codesys config files I located on the PC's disk: o C:\Program Files (x86)\CODESYS 3.5.20.40\GatewayPLC\CODESYSControl.cfg (only 2 lines in this config) o C:\Program Files (x86)\CODESYS 3.5.20.40\GatewayPLC\AppDataFiles\CODESYSControlWinV3\CODESYSControl.cfg o C:\Users\SRV\AppData\Roaming\CODESYS\CODESYSControlWinV3\C4DBB537\CODESYSControl.cfg o C:\Program Files (x86)\CODESYS 3.5.20.40\GatewayPLC\tempCFG\CODESYSControl.cfg - When I run codesys as an app (e.g. by clicking the icon), this config file is read C:\Users\SRV\AppData\Roaming\CODESYS\CODESYSControlWinV3\C4DBB537\CODESYSControl.cfg and log files are written ok. The icon target is "C:\Program Files (x86)\CODESYS 3.5.20.40\GatewayPLC\CODESYSControlService.exe" -d o the -d option, I think, starts a cmd-like window showing service debug output (the output shown in log in the IDE) o the -i option, again I think, means install the service - I tried adding -d to service start parameters in the registry, but it started only once and after that it refused to start. Knowing what -d does and which other options are available would be great (e.g. can I make the service read a different config file). - Syslog UDP logging works fine in any case. - These are my CmpLog parameters ~~~ [CmpLog] Logger.0.Name=PlcLog3 Logger.0.Filter=0xFFFFFFFF Logger.0.Enable=1 Logger.0.MaxEntries=10003 Logger.0.MaxFileSize=50003 Logger.0.MaxFiles=33 Logger.0.Backend.0.ClassId=0x0000010B ;sends logger messages to SysOut Logger.0.Backend.1.ClassId=0x00000104 ;writes logger messages in a file Logger.0.Backend.2.ClassId=0x00000135 ;sends logger messages as UDP syslog Logger.0.Type=0x314 ;Set the timestamp to RTC ~~~
Last updated: 2025-02-27

Post by drbuzz on Communication Error (#0) for IFM controller ^{CODESYS Forge talk (Post)}
Hi Folks, Every time I use an IFM controller I always seem to run into a problem connecting to it. I get the Communications Error (#0). So I thought I would share some tips and tricks. Once the CANfox Cable (EC2112) cable driver is installed, you can use the yellow app in the sys tray to blink the lights on the cable. Confirm the cable works in the IFM maintenance software by connecting to the controller and reading the information on it. Make sure to download an OS into the controller (the light will go from a fast blink to solid green). In Codesys V2.3, the communication settings for the CR0401 is 250kBaud by default and Node ID 127. What got me, was I needed to reboot the computer after the cable driver install. Also if your application has canbus settings in it which are changed from default, after the controller is power cycled, the new Node ID and Baud will be in effect. I made a handy guide because too much time has been wasted on this. Programming IFM CR0401 Serial/Can Programming Cable • Connect IFM EC2112 CanFox programming cable with connector adapter. • Make sure cable is linked to VM (if using VM). • Install drivers for cable if not installed. o Download from IFM EC2112 site. https://www.ifm.com/ca/en/product/EC2112 • Once Installed, reboot computer. • In system tray, there should be a yellow icon that you can open and check on programming cable. Select the cable in the list and flash the lights to confirm it is working. Maintenance Software • Install IFM Maintenance Tool Software. o Download from IFM Site. https://www.ifm.com/ca/en/download/eco100_MaintenanceTool • Open IFM Maintenance software • Select Basic System • Select CAN cable • It will tell you if you don’t have a cable connected. • Use Wizard if needed. • Read Channel Parameter on the Settings page, or get Identity in the System Information > Identity. • Default Node is 127 on a new unit. Baud is 250kBaud (bits/sec) • Controller information should populate. • Controller green light should be blinking at 5hz (meaning OK but no OS, just bootloader). • Click Software > Load. • Open the OS file. Should match Codesys version selection (for CR0401 this is version 3). o Download OS file from IFM Website. https://www.ifm.com/ca/en/product/CR0401 o It is located at the top of the download under “software for CR0401”. o Select the file and load it… this will take a minute. • Once completed the unit should now have a solid green light o Solid green means the controller has an OS but no application is running. Codesys V2.3 Application • Codesys needs to be downloaded and installed from the IFM website as it has the IFM libraries and license to use the software. o Download from the IFM CR0401 page. o https://www.ifm.com/ca/en/product/CR0401 • Create new application with the correct IFM controller or Open Codesys application. • Keep in mind that the PLC Configuration on the Resources tab can be changed for the CAN communication interface… so changes to node and baud will take effect after the first download and reboot of the controller. • Go to “Online” in the top menu and change “Communication Parameters” o The Local dropdown shows the last configuration used. All other interfaces will show below it and need to be updated when changed or used. o Confirm Node ID is 127 for the first download.  The NodeID will change to whatever the program has after (in my case 125).  Node Send Offset should be default at 1536  Node Recv Offset should be default at 1408  Can bus Baudrate should be 250 kbaud.  Yes to Motorola Byte Order  Block Transfer should be false and note used (60 is default setting).  Can Card Driver should match the systray item which is Sie_USB. • If the system populated the other one, just update and relay the communication parameters. The software will usually bring up the available cable and driver. • Go to “Online” and Login to download. o Press Yes to Download Application. I hope this helps!
Last updated: 2025-03-21

Post by struccc on Inheritence of struct, ^{CODESYS Forge talk (Post)}
Strangely reminds me to my struggles... Want to do something "Elegant", reusable, universal, practical... In CODESYS??? 🙃 First of all, before you get too deep into this: If you could find a way, to make a "universal" log entry object, containing the variable length data itself, you wouldn't be able to store them in an array, or access them like an array, or pass them by value as a type. (please correct me, if I'm wrong, incorrect, or not precise). Because... Basically you can't declare a type with variable memory footprint. This is a very deeply embedded characteristic of CODESYS, and all IEC 61131-3 systems, and it has many reasons behind. And yes, it is a very common trap / mistake, to forget about. So, with a log entry - I guess - it's pretty much the purpose: store data and metadata together, and then handle it in a uniform way. There are ways to handle this, really depends on what is the purpose. For example: 1. Entries with fixed length (Maybe it is not as evil as it looks for the first time. Depends on the situation, but definitely the fastest and easiest code) You can have your base object, with an internal, fixed length string or byte array variable. I would go with a string, and call it _Data.; And then you can make properties, like As_Bool, As_Int, As_Real... In the 'set' accessors, you can do like: pReal := ADR(_Data); // POINTER TO REAL As_Real := pReal^; In the 'get' accessors, evidently: pReal := ADR(_Data); // POINTER TO REAL pReal^ := AS_Real; Or, can use ANY type, if you are not obsessed with variable / property like access: 2. Fixed length, but nicer First, some disadvantage to any values: - You can only assign values with write access. No literals, constants, etc... - Can only be used as input variable of function or function_block - Therefore, stg you could reach: LogEntry.Initialize (stVariable|rVariable|iVariable|xVariable); Just a quick example (it's funny to play with ANY): Be careful it was not tested. I'm sure can be done better, please feel free to comment FUNCTION_BLOCK FB_LogEntry VAR_INPUT MsgClass : UDINT; // Like DEBUG, WARN, ERR... MsgCode : UDINT; // Like Errors.ERR_FAILED MsgTS : DT; // The timestamp END_VAR VAR _Data : STRING(80); // Our data container... _Descr : __SYSTEM.AnyType; // A standard descriptor for our data, containing TYPE_CLASS, address and size END_VAR METHOD SET_Value : BOOL VAR_INPUT anyValue : ANY; END_VAR VAR I : DINT; diSize : DINT; pStr : POINTER TO STRING; END_VAR // Check what did we receive in anyValue. diSize := anyValue.diSize; // We use constant __SYSTEM.TYPE_CLASS to identify the received data type CASE anyValue.TypeClass OF // Maybe we don't want to store references, pointers... and who knows what else... __SYSTEM.TYPE_CLASS.TYPE_REFERENCE, __SYSTEM.TYPE_CLASS.TYPE_POINTER : SET_Value := FALSE; // For the planned types we will be just fine. TYPE_CLASS.TYPE_BOOL, TYPE_CLASS.TYPE_INT, TYPE_CLASS.TYPE_REAL : SET_Value := TRUE; // Optionally string can be handled separately, maybe we have received STRING(255), but practically it is shorter than 80 bytes... TYPE_CLASS.TYPE_STRING : pStr := anyValue.pValue; diSize := MIN(anyValue.diSize, LEN(pStr^) + 1); // Get the actual size, and rewrite the received structure member diSize := MIN(SIZEOF(_Data), diSize); // Can chop down the received string to our length... SET_Value := TRUE; // Maybe want to play a little bit more here, to narrow down or convert datatypes, etc... // Or just reject any other datatype ELSE SET_Value := FALSE; RETURN; END_CASE // Fail, if the received value is still larger than our container... IF diSize > SIZEOF(_Data) THEN SET_Value := FALSE; END_IF // Here we should be ok, just set up the _DataType structure, and copy store the data IF SET_Value THEN THIS^._Descr.TypeClass := anyValue.TypeClass; // The typeclass is already filtered THIS^._Descr.diSize := diSize; // Set the (adjusted) size THIS^._Descr.pValue := ADR(_Data); // This will not change, just to be sure {IF defined (pou:SysMem.SysMemCpy)} SysMem.SysMemCpy(_DataType.pValue, anyValue.pValue, TO_UDINT(anyValue.diSize)); {ELSE} // An ugly replacement MemCpy FOR I:=0 TO diSize - 1 DO _Descr.pValue[I] := anyValue.pValue[i]; END_FOR {END_IF} // Otherwise, in case of failure maybe better set an empty value (overwrite the former data descriptor) ELSE THIS^._Descr.TypeClass := TYPE_CLASS.TYPE_NONE; THIS^._Descr.pValue := ADR(_Data); THIS^._Descr.diSize := 0; END_IF METHOD GET_Value : BOOL VAR_INPUT anyValue : ANY; END_VAR VAR I : DINT; END_VAR // We just have to serve the data, using the __System.AnyType structure received // Roughly we can say: IF anyValue.TypeClass = _Descr.TypeClass AND anyValue.pValue <> 0 // This should not be possible, already taken care of by Codesys (?) THEN {IF defined (pou:SysMem.SysMemCpy)} SysMem.SysMemCpy(anyValue.pValue, _DataType.pValue, TO_UDINT(MIN(anyValue.diSize, _Descr.diSize))); {ELSE} // An ugly replacement MemCpy FOR I:=0 TO MIN(anyValue.diSize -1, _Descr.diSize - 1) DO anyValue.pValue[I] := _Descr.pValue[I]; END_FOR {END_IF} // Just to make sure, that our string is terminated... IF anyValue.TypeClass = TYPE_CLASS.TYPE_STRING THEN anyValue.pValue[anyValue.diSize -1] := 0; END_IF GET_Value := TRUE; RETURN; END_IF // ... But can play more CASE anyValue.TypeClass OF TYPE_CLASS.TYPE_WSTRING : ; // Could do conversion TYPE_CLASS.TYPE_XSTRING : ; // Wow, I have to figure this out TYPE_CLASS.TYPE_PARAMS : ; // BTW, what is this, how to use? TYPE_CLASS.TYPE_ANYNUM : ; // ... END_CASE Be careful it was not tested. I'm sure can be done better, please feel free to comment 3. If you really want to do entries with variable size In a standard environment, it would be similar to the previous, except you dont have the container variable _Data, just use a pointer, practically _Descr.pValue At Initialize (SET_Value), you have to allocate the memory, would be easy with SysMem.SysMemAlloc - nowadays with SysMem.SysMemAllocData -, and you make sure to release it after use with SysMem.SysMemFreeData... SysMemAlloc was already hidden. The problem with this, that sooner or later your application will totally fragment the dynamic memory, and fail... So should look for some form of dynMaybe MemUtils.MemoryManager (I am not sure what is the status and the future of it). 4. You will end up by a LogEntry Factory ... 5. You could still have a look at this IEC Snippets BTW, Standard Codesys Logger is not a bad choice either. If you are really interested, I share some more code / library.
Last updated: 2025-03-09

Sort by relevance or date