Search talk: password for user group

 
<< < 1 .. 121 122 123 124 > >> (Page 123 of 124)

Post by shaunvdm on Canbus Slave SDO Read from Object CODESYS Forge talk (Post)
Busy testing a solution to use Canbus Slave to replace a physical device and convert to Ethercat device but keep the Canbus Master in place. Master needs to Read SDO object 5FA2. In the Master PLC if i send the SDO with 8 bytes in message IE: 60B 40 A2 5F 00 00 00 00 00 i get my expected 58B 43 A2 5F 00 00 68 36 02 containing data back. Problem is if we issue a 4 byte command can send 60B 40 A2 5F. Surely the canbus slave should respond with a 58B 43 A2 5F 00 00 68 36 02 but it comes back as 80 A2 5F 00 00 00 00 08 - meaning this OBJECT does not exist. Is there a setting in the canbus slave driver for Canbus to allow the 4 byte command to read the SDO OBJECTS ?
Last updated: 2025-05-27

Post by laurits on Max lines of code, codesys CNC ? CODESYS Forge talk (Post)
Hi, okay here's the project, it's a modified version of "CNC Example 10: Programming Dynamic CNC Paths", no need for G Code text file (i have also tried with G code text file, same problem) in "PROGRAM PLC_PRG" you can set bStart to true, and the program should start running, go to "PROGRAM CNC" and you can see axis moving. lrXpos := IoConfig_Globals.XAixs.fSetPosition; lrYpos := IoConfig_Globals.YAxis.fSetPosition; Now you can can change the number of movements in the the "PROGRAM PLC_PRG" From this number of movements in "program PLC_PRG" BUF : ARRAY[0..32010] OF SMC_GEOINFO; xp : ARRAY[1..32000] OF REAL; yp : ARRAY[1..32000] OF REAL; to this number to this number of movements BUF : ARRAY[0..132010] OF SMC_GEOINFO; xp : ARRAY[1..132000] OF REAL; yp : ARRAY[1..132000] OF REAL; Now if you start the program again you should see an error in the "sMC_Interpolator: SM3_CNC.SMC_Interpolator;" function block Let me know if you can not get it running.
Last updated: 2025-06-03

Post by sbhaskarla on WebVisu File Transfer Error CODESYS Forge talk (Post)
I’m encountering an issue when downloading CSV files via the WebVisu button input config -> file-transfer option: ‱ Custom directory: /plcdata/csv_logs/filename.csv o Error: Error 4 – Error during file transfer ‱ Sandbox directory: /var/opt/codesys/PlcLogic/plcdata/csv_logs/filename.csv o Result: Download succeeds without error. Actions taken so far: 1. Added /plcdata/csv_logs to codesyscontrol.cfg (see attached). 2. Enabled file-transfer services in codesyscontrol_user.cfg (see attached). 3. Confirmed that the PLC writes CSV files correctly to /plcdata/csv_logs/. Despite these settings, WebVisu still returns Error when accessing the custom path 1. Using the placeholder file path '$$CSVLOGS$$/filename.csv' and it returns Error 6. 2. Using the literal path /plcdata/csv_logs/filename.csv and it returns Error 4 Could someone please help me determine what additional configuration or troubleshooting steps are required to serve files from /plcdata/csv_logs/? Please find screenshots attached for better understanding and I have also attached the config files
Last updated: 2025-06-13

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 manuknecht on Opening a Dialog on a specific Client from ST CODESYS Forge talk (Post)
I managed to find a solution that seems to work reliably. As the VU.Globals.CurrentClient-filter accesses the CURRENTCLIENTID or at least a similar, internal variable it can only be used if called from a certain client (e.g. from a button in a visualization). My solution works by implementing a new client filter that compares the client ID of all clients to the ID of the last client that was used. The variable containing the data of the last client is defined as: G_LastClient : VU.IVisualizationClient; // Copy of last client that detected click This last client is then updated every time a button is pressed using the Execute ST-Code input configuration of the button: G_LastClient := VU.PublicVariables.Clients.Current; Next, I created a function block that implements the client filter interface as so: FUNCTION_BLOCK FB_LastClientFilter IMPLEMENTS VU.IVisualizationClientFilter VAR_INPUT END_VAR VAR_OUTPUT END_VAR VAR END_VAR Then i added a method to the FB called IsAccepted which is used to filter out the client. When creating the method, it should automatically be filled with the according variable declaration, as it is defined in the interface: (* For every client can be desided, if it is accepted. ``TRUE``: Client is accepted*) METHOD IsAccepted : BOOL VAR_INPUT (* The client, to check*) itfClient : VU.IVisualizationClient; END_VAR Now the client can be compared to the last used client as such: // check if clientID corresponds to clientID of last recorderd client IF itfCLient.ClientId = G_LastClient.ClientId THEN IsAccepted := TRUE; ELSE IsAccepted := FALSE; END_IF To make use of this custom client filter, initialize a variable with the client filter: LastClient : FB_LastClientFilter; // Client filter to find last used client Then use this client filter when opening or closing a dialog from ST: fbOpenMyDialog(itfClientFilter:=LastClient,xExecute:=TRUE,sDialogName:='VIS_MyDialog_DLG');
Last updated: 2023-09-27

Post by acc00 on Redundancy Codesys Runtime, Synchronization CODESYS Forge talk (Post)
Hi, I’m currently testing the Codesys Redundancy application with 2 Raspberry Pi, with the idea is of using in my project 2 Wago PFC200 and 1 Ethercat Master with 2 Remote IO. After I configure the redundancy, and one Pi is Active and the other is Passive, if I disconnect the Ethernet cable of the Active, the Passive become Standalone, which is good, but the problem is the following: -When I recover the Ethernet connection, both stay Standalone. They will NOT Sync until I do it manually in the Codesys environment. How to make the synchronization automatically? -If both Pi/PLC stays Standalone, who is managing the IO? (Ethercat and Serial) I have done a test with an Modbus Slave, where I am sending a counter that increase every second. And I see that when both PLC are standalone, they both keep an active connection with the Slave, and both write values. This does not seem good, since according to this in my project both PLC would try to control the IO at the same time. Note: The Codesys have an option (greyed out, not possible to select) which says “Auto Sync”. What is the purpose, and why I’m not able to select it? I'm using Codesys Control for Rapsberry Pi 64SL Runtime in my test environment (2xRaspberry Pi 4), with the idea of using Codesys Control PFC 200 Runtime in my project (2xWago PFC200 and 1 Ethercat Master with 2x Wago 750-354 Ethercat Fieldbus Coupler). Using the last Codesys 3.5 version (SP19 PAtch 5). I'd appreciate a lot any help on this questions!
Last updated: 2024-01-22

Post by micik on Using Codesys example problems CODESYS Forge talk (Post)
Hello to all, I'm totally new to Codesys, but I do have some PLC programming experience, mosty with Siemens TIA and STEP7. I have just installed Codesys 3.5. sp19 and I have downloaded example with Ethernet Rockwell 1734AENT. The example can be found here: https://forge.codesys.com/prj/codesys-example/rockwell-1734-c/home/Home/ After opening, I had to manually update devices (Device, Ethernet, IP Scanner, EthernetIP adapter). However, when trying to build the project, I get the following errors: [WARNING] CODESYS_EtherNetIP_Rockwell1734AENT: Library Manager [Device: PLC Logic: Application]: C0100: Library System_VisuElemXYChart has not been added to the Library Manager, or no valid license could be found [WARNING] CODESYS_EtherNetIP_Rockwell1734AENT: Library Manager [Device: PLC Logic: Application]: C0100: Library system_visuinputs has not been added to the Library Manager, or no valid license could be found [ERROR] iodrvethernetip, 4.4.1.0 (3s - smart software solutions gmbh): ServiceCycle [IoDrvEtherNetIP]: C0040: Function 'ProcessUpdateConfigurationQueue' requires exactly '1' inputs [ERROR] iodrvethernetip, 4.4.1.0 (3s - smart software solutions gmbh): IoDrvStartBusCycle [IoDrvEtherNetIP]: C0040: Function 'GenerateRandomUINT' requires exactly '2' inputs [ERROR] iodrvethernetip, 4.4.1.0 (3s - smart software solutions gmbh): Cyclic [GenericServiceUnConnected]: C0040: Function 'GenerateRandomUINT' requires exactly '2' inputs [ERROR] cip object, 4.4.1.0 (3s - smart software solutions gmbh): ForwardOpenService [ConnectionManager]: C0040: Function 'GetAssemblies' requires exactly '3' inputs [ERROR] iodrvethernetipadapter, 4.4.0.0 (3s - smart software solutions gmbh): ServiceCycle [IoDrvEtherNetIPAdapter]: C0040: Function 'GenerateRandomUINT' requires exactly '2' inputs [ERROR] iodrvethernetip, 4.4.1.0 (3s - smart software solutions gmbh): SetupStructuredIOMapping [RemoteAdapter]: C0040: Function 'MallocData' requires exactly '1' inputs [ERROR] iodrvethernetip, 4.4.1.0 (3s - smart software solutions gmbh): SetupStructuredIOMapping [RemoteAdapter]: C0040: Function 'MallocData' requires exactly '1' inputs Compile complete -- 7 errors, 13 warnings Build complete -- 7 errors, 13 warnings : no download possible! What could be the reason for this errors and how to rectify them? Thank you!
Last updated: 2024-02-01

Post by duvanmoreno24 on Modbus writing on value change CODESYS Forge talk (Post)
Hi all, I want to know if someone has an idea of how I can write on value change in Modbus Codesys. I have a Wago PLC and I was used to work with E-cockpit which it was quite easy to do that without the necessity to trigger any value when there was a change in the variable ( I will put how easy is ). how you can see just changing the trigger in "On value Change" will do that channel writing automatically when It detects a change in those arrays. On the other hand, in Codesys if I enable the rising edge in Codesys It ask me to put a bool variable and if triggers is going to write that value. That is making me that I have to create a function or a logic to detect the change, the problem I have is that doing that is very tedious. I first approach I got it was to create a Function who returns a bool when the value change, but I tried to keep the old value but what is happening is that in Functions all the data is erased every cycle so I can not keep any Old value. so in the Main program the trigger is going to be TRUE all the time due, the old value is cero every cycle. The second approach I got it was using a function Block (POU_1) and it works but I dont want to instance that function for every Channel or value that I want to check if the value change, Basically if I have 200 values to write trhough modbus I have to create 200 instances of that function which I think it is not practicall at all. It should be a better way to implement this as e-Cockpit from Wago Does. However, I haven't been able to know how.
Last updated: 2024-03-26

Post by wildcard on Modbus Client Request Not Processed CODESYS Forge talk (Post)
Hi, does anyone has a solution for this issue. I've the same problem. I've implemented a very simple client based on the Modbus Examples and connected the soft PLC to a Modbus Simulator. PROGRAM ModbusClient VAR initDone : BOOL := FALSE; errorID : ModbusFB.Error; client : ModbusFB.ClientTCP; timeout : UDINT := 500000; replyTimeout : UDINT := 200000; aUINT : ARRAY [0..8] OF UINT; clientRequestReadHoldingRegisters : ModbusFB.ClientRequestReadHoldingRegisters; clientRequestsCnt : UINT := 0; clientRequestsProcessCnt : UINT := 0; ipAddress : ARRAY[0..3] OF BYTE := [10,54,0,72]; END_VAR IF NOT initDone THEN initDone := TRUE; client(aIPaddr:=ipAddress, udiLogOptions:=ModbusFB.LoggingOptions.All); client(xConnect:=TRUE, ); clientRequestReadHoldingRegisters(rClient:=client, udiTimeOut:=timeout, uiUnitId:=1, uiStartItem:=0, uiQuantity:=4, pData:=ADR(aUINT[0]), udiReplyTimeout:=replyTimeout); clientRequestReadHoldingRegisters.xExecute := TRUE; clientRequestsCnt := 0; END_IF clientRequestReadHoldingRegisters(rClient:=client, udiTimeOut:=timeout, uiUnitId:=1, uiStartItem:=0, uiQuantity:=4, pData:=ADR(aUINT[0]), udiReplyTimeout:=replyTimeout, xExecute := TRUE); IF clientRequestReadHoldingRegisters.xError THEN clientRequestsCnt := clientRequestsCnt +1 ; errorID := clientRequestReadHoldingRegisters.eErrorID; END_IF clientRequestReadHoldingRegisters(rClient:=client, udiTimeOut:=timeout, uiUnitId:=1, uiStartItem:=0, uiQuantity:=4, pData:=ADR(aUINT[0]), udiReplyTimeout:=replyTimeout, xExecute := NOT clientRequestReadHoldingRegisters.xExecute); When the system is running I do get the following on the logs: 2024-05-13T10:18:07.443Z: Cmp=MODBUS lib, Class=1, Error=0, Info=0, pszInfo= Client.RequestProcessed ClientRequest,16#0164ADC561A0 unitId=1 fc=ReadHoldingRegisters id=2070 state=Error 2024-05-13T10:18:07.443Z: Cmp=MODBUS lib, Class=1, Error=0, Info=0, pszInfo= ClientRequest,16#0164ADC561A0 unitId=1 fc=ReadHoldingRegisters id=2070 change state Error -> None timestamp=63843421226 2024-05-13T10:18:08.444Z: Cmp=MODBUS lib, Class=1, Error=0, Info=0, pszInfo= ClientRequest,16#0164ADC561A0 unitId=1 fc=ReadHoldingRegisters id=2071 change state None -> Init timestamp=63844421420 2024-05-13T10:18:09.444Z: Cmp=MODBUS lib, Class=1, Error=0, Info=0, pszInfo= ClientRequest,16#0164ADC561A0 unitId=1 fc=ReadHoldingRegisters id=2071 change state Init -> Error timestamp=63845421675 But the errorID is jumping between OK and RequestNotProcessed. Any help is very appreciated which gives me a hint what I'm doing wrong. Thanks
Last updated: 2024-05-13

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 yannickasselin on MQTT QoS 1 & 2 CODESYS Forge talk (Post)
Hello, I am using Codesys sp20p3 and IIoT library 1.11. I am trying to test QoS 1 & 2 and I have some issues. I am using mosquitto as the broker. I am also using some other MQTT clients like Node-Red and TwinCAT. They all work as expected for every QoS levels. I only have issues with Codesys MQTT client. In the Codesys client, if I subscribe to a topic as QoS 1 or 2, and a client publishes to this topic, I receive the message. But if I disconnect the Codesys client from the network and a client publishes to the subscribed topic, when I reconnect Codesys client to the network, I don't receive the messages as expected. Also there does not seem to be an auto-reconnect feature. So I have to manually set the mqttClient.xEnable bit to FALSE then back to TRUE in order to reconnect to the broker, then I also have to set the subscribe.xEnable to FALSE and back to TRUE in order to re-subscribe to the topic, but even then, I don't receive the messages that were published while I was disconnected. What am I doing wrong? I set the cleanSession bit to FALSE and I give my client a clientID. With the TwinCAT MQTT Client, I do the same thing and everything works as expected. It even auto-reconnects to the broker. I would expect Codesys MQTT Client to be as reliable as TwinCAT. Maybe I am doing something wrong? I also noticed that when trying to publish a QoS 1 or 2 message while disconnected from the broker, it does not work. In TwinCAT, I am still able to publish. The messages are stored in the client and published once reconnected to the broker. I would expect to be able to do the same thing in Codesys. Is this all possible? Am I doing something wrong? Thank you
Last updated: 2024-10-26

Post by pruwetbe on Profinet IO-link master - IODD files CODESYS Forge talk (Post)
Hello, we have the same problem here. Our configuration in the following: Codesys V3.5 SP19 running on Exor Exware700Q Profinet network connected on Eth1 IOLink Master Turck TBEN-S2-4IOL version 3.5.9.0 IOLink sensors E+H & Sick (Pressure, T°) We installed the codesys IO link package and have the codesys IO Link SL licence activated (on a dongle) Our problem is the following: we got the IODD files from E+H & Sick we add the devices in the codesys device repository with success They appear in the devices tree under IODD branch We added the TBEN IOLink master under the Profinet IO . The IO link master are ok and display online. The IO-Link SL package datasheet indicate that there would be a way to scan the IOLink device from the network but we did not find any way to trigger this scan. (we expect to get this from a right click on each IO-Link Master module but the only possibility there is "Plug device") When clicking on Plug Device, we get a browse window with profinet IO modules. The IODD devices are not there so we cannot select them. But other devices for other brands are available and can be plugged. Our question are : 1) how do we update the Profinet IO Module catalogue in order to be able to plug the E+H & Sick Sensors that we have to work with? 2) how do we activate the Scan IOLlink device that is supposed to be included in the Codesys IO-link package? 3) where can we find the manual explaining how to use this package?
Last updated: 2024-11-12

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 trusty-squire on SysProcessCreate2 on Linux runtime CODESYS Forge talk (Post)
Hi, I'm trying to launch a continuously running python script from Codesys and monitor the script status inside the Codesys runtime (running on a Linux enviroment). For now I'm testing with the below to emulate a continuously running Python script: #test.py i = 0 while True: i += 1 I'm able to successfully run the script using SysProcessExecuteCommand2 (I can see the Python process running in the task manager). However, this "freezes" the Codesys execution of the task - it sits on that command and will not continue until the Python script ends. I've proven this works by using the task monitor to kill the process, then Codesys continues on happily through the task. What I want to do is use SysProcessCreate2 to set up the Python script as a background task and monitor the process using SysProcessGetState. This always results in the error "ERR_OPERATION_DENIED". I know that I'm able to execute commands (as above), so my config should be correct. Is SysProcessCreate2 functional on a Linux environment? Is there something in the config file I'm missing? Here's my "working" code that uses SysProcessExecuteCommand2: VAR bTest : BOOL; sCommand : STRING := '/usr/bin/python3 /var/opt/codesys/PlcLogic/Application/test.py'; refCommand : REFERENCE TO STRING REF= sCommand; sOutput : STRING; refOutput : REFERENCE TO STRING REF= sOutput; result : RTS_IEC_RESULT; END_VAR IF bTest THEN SysProcessExecuteCommand2( pszCommand:= refCommand, pszStdOut:= refOutput, udiStdOutLen:= SIZEOF(sOutput), pResult:= ADR(result) ); bTest:= FALSE; END_IF And here's the code that always results in the ERR_OPERATION_DENIED error: VAR bTest : BOOL; sApp : STRING := '/usr/bin/python3'; sCommand : STRING := '/var/opt/codesys/PlcLogic/Application/test.py'; refApp : REFERENCE TO STRING REF= sApp; refCommand : REFERENCE TO STRING REF= sCommand; hResult : SysProcess.RTS_IEC_RESULT; hHandle : SysProcess.RTS_IEC_HANDLE; END_VAR IF bTest THEN hHandle := SysProcessCreate2( pszApplication:= refApp, pszCommandLine:= refCommand, ulFlags:=SYSPROCESS_CREATEFLAG_HIDDEN, pResult:= ADR(hResult) ); bTest:= FALSE; END_IF Here's the relevant section from the config file at /etc/codesyscontrol/CODESYSControl.cfg: [SysProcess] Command=AllowAll Appreciate any support or ideas. Thanks!
Last updated: 2025-03-16

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 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 solidlogicguy on Little endian to Float from Modbus RTU CODESYS Forge talk (Post)
Hello, I got a device from which I require to read values from I am using a WAGO PLC 750-8212 and I am communicating through Modbus Master FUNCTION BLOCK from library WagoAppPLCModbus in Codesys 3.5 to this device. I already receive data from the device that is a CVM to monitor voltage from a fuel cell. The technical support of the company that makes these devices says that the data is sent in little endian form. And I want to convert it to a float value. The tech support sent me the next instructions of how to do it but I am new using codesys, so any advice or help I will really appreciate so much. Message from tech support: The process is complicated, better to do it with already implemented library in the language/program you use. Basically the process should be next: To convert the two Modbus registers containing parts of a 32-bit float in little-endian byte order to a floating-point number using mathematical operations, you first need to combine the two 16-bit integers (assuming reg1 is the lower word and reg2 is the higher word) and then interpret the result according to the IEEE 754 standard. Given: - Register 192 (reg1) = 4096 - Register 193 (reg2) = 14884 Step 1: Combine the two registers. Since we are dealing with little-endian byte order, reg2 is the high word, and reg1 is the low word: combined = reg2 * 2^16 + reg1 combined = 14884 * 65536 + 4096 combined = 975175680 + 4096 combined = 975179776 Step 2: Convert the combined value to binary: combined_binary = '1110101101011100000000000000000' Step 3: Split the binary into IEEE 754 components: Sign bit (1 bit): 0 Exponent (8 bits): 11101011 Mantissa (23 bits): 01011100000000000000000 Step 4: Convert the binary exponent to decimal and subtract the bias (127 for 32-bit floats): exponent = int('11101011', 2) - 127 exponent = 235 - 127 exponent = 108 Step 5: Calculate the mantissa as a fraction: The mantissa in IEEE 754 format is the fractional part after the leading 1 (which is implicit). Therefore, we need to convert the binary mantissa to decimal and add the implicit leading 1: mantissa_fractional = 1 + int('01011100000000000000000', 2) / 2^23 mantissa_fractional = 1 + 18688 / 8388608 mantissa_fractional = 1 + 0.002227783203125 mantissa_fractional ≈ 1.002227783203125 Step 6: Combine the sign, exponent, and mantissa to get the float value: float_value = (-1)^0 * mantissa_fractional * 2^exponent float_value = 1 * 1.002227783203125 * 2^108 Because the exponent is quite large, the resulting float value is a very large number.
Last updated: 2023-12-15

Post by spiessli on Raspberry Pi 4 with Legacy Drivers and Codesys 3.5.19 Patch 4 CODESYS Forge talk (Post)
Thanks for the suggestion, I have tried it eagerly: I have updated all packages to latest version with Codesys Installer and installed newest runtime and gateway on Raspberry Pi. Unfortunately, the error is still there. As soon as I add the SM_Drive_Servo to the device tree, I get the error below when generating the code. Reverting SM3_Basic to version 4.14 makes the error disappear. ------ Übersetzungslauf gestartet: Applikation: Device.Application ------- Code typisieren... Code erzeugen... [FEHLER] sm3_drive_servo, 4.10.0.0 (codesys): GetStandardConfigParams [AXIS_REF_SERVO]: C0032: Typ 'Unbekannter Typ: 'ConfigGetParameterValueLREAL(pParam, 0)'' kann nicht in Typ 'LREAL' konvertiert werden [FEHLER] sm3_drive_servo, 4.10.0.0 (codesys): GetStandardConfigParams [AXIS_REF_SERVO]: C0046: Bezeichner 'ConfigGetParameterValueLREAL' nicht definiert [FEHLER] sm3_drive_servo, 4.10.0.0 (codesys): GetStandardConfigParams [AXIS_REF_SERVO]: C0035: Programmname, Funktion oder Funktionsbausteinstanz an Stelle von 'ConfigGetParameterValueLREAL' erwartet [FEHLER] sm3_drive_servo, 4.10.0.0 (codesys): GetStandardConfigParams [AXIS_REF_SERVO]: C0032: Typ 'Unbekannter Typ: 'ConfigGetParameterValueLREAL(pParam, 0)'' kann nicht in Typ 'LREAL' konvertiert werden [FEHLER] sm3_drive_servo, 4.10.0.0 (codesys): GetStandardConfigParams [AXIS_REF_SERVO]: C0046: Bezeichner 'ConfigGetParameterValueLREAL' nicht definiert [FEHLER] sm3_drive_servo, 4.10.0.0 (codesys): GetStandardConfigParams [AXIS_REF_SERVO]: C0035: Programmname, Funktion oder Funktionsbausteinstanz an Stelle von 'ConfigGetParameterValueLREAL' erwartet [FEHLER] sm3_drive_servo, 4.10.0.0 (codesys): GetStandardConfigParams [AXIS_REF_SERVO]: C0032: Typ 'Unbekannter Typ: 'ConfigGetParameterValueLREAL(pParam, 0)'' kann nicht in Typ 'LREAL' konvertiert werden [FEHLER] sm3_drive_servo, 4.10.0.0 (codesys): GetStandardConfigParams [AXIS_REF_SERVO]: C0046: Bezeichner 'ConfigGetParameterValueLREAL' nicht definiert [FEHLER] sm3_drive_servo, 4.10.0.0 (codesys): GetStandardConfigParams [AXIS_REF_SERVO]: C0035: Programmname, Funktion oder Funktionsbausteinstanz an Stelle von 'ConfigGetParameterValueLREAL' erwartet [FEHLER] sm3_drive_servo, 4.10.0.0 (codesys): GetStandardConfigParams [AXIS_REF_SERVO]: C0032: Typ 'Unbekannter Typ: 'ConfigGetParameterValueLREAL(pParam, 0)'' kann nicht in Typ 'LREAL' konvertiert werden [FEHLER] sm3_drive_servo, 4.10.0.0 (codesys): GetStandardConfigParams [AXIS_REF_SERVO]: C0046: Bezeichner 'ConfigGetParameterValueLREAL' nicht definiert [FEHLER] sm3_drive_servo, 4.10.0.0 (codesys): GetStandardConfigParams [AXIS_REF_SERVO]: C0035: Programmname, Funktion oder Funktionsbausteinstanz an Stelle von 'ConfigGetParameterValueLREAL' erwartet [FEHLER] sm3_drive_servo, 4.10.0.0 (codesys): GetStandardConfigParams [AXIS_REF_SERVO]: C0032: Typ 'Unbekannter Typ: 'ConfigGetParameterValueLREAL(pParam, 0)'' kann nicht in Typ 'LREAL' konvertiert werden [FEHLER] sm3_drive_servo, 4.10.0.0 (codesys): GetStandardConfigParams [AXIS_REF_SERVO]: C0046: Bezeichner 'ConfigGetParameterValueLREAL' nicht definiert [FEHLER] sm3_drive_servo, 4.10.0.0 (codesys): GetStandardConfigParams [AXIS_REF_SERVO]: C0035: Programmname, Funktion oder Funktionsbausteinstanz an Stelle von 'ConfigGetParameterValueLREAL' erwartet Übersetzung abgeschlossen -- 15 Fehler, 0 Warnungen : Kein Download möglich
Last updated: 2023-12-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 pppn on Issue with Forward Open Connections in Ethernet/IP Protocol Stack in Codesys CODESYS Forge talk (Post)
Hello, I am facing an issue with my Ethernet-based project in Codesys. My product was functioning well until I modified the protocol stack and uploaded it to my device. Here are the details of my problem: Project Setup: I am working on an Ethernet-based project to test my product. The project was running without issues before modifying the protocol stack. Issue: After modifying the protocol stack and uploading it to my device, I am encountering an error in Codesys related to the forward open connections. Error status: connection failure, extended: connection in use or duplicate forward open. According to the Ethernet/IP protocol in codesys, there are three forward open connections that need to be established. The first two connections are opening without any issues. The third connection, which is an input-only connection, is causing problems. The error message indicates that the connection is already open. Debugging Attempts: I have extensively debugged the protocol stack and found no issues. The product works well when tested with EIP tools but not with Codesys. Exclusive owner connections are working correctly, and only the input-only connection is problematic. Wireshark Traces: Wireshark traces show that the third connection attempts to open but reports that it is already open. Steps to Reproduce: Modify the protocol stack and upload it to the device. Attempt to establish three forward open connections in Codesys. Observe the error on the third connection (input-only). Request: I would appreciate any suggestions or guidance on how to resolve this issue. If there are specific settings or configurations in Codesys that I need to check, please let me know. Additionally, if there are known issues or workarounds related to this problem, I would be grateful for the information. Attachments: Wireshark traces showing the connection attempts and errors Screenshots of the error messages in Codesys codesys version: CODESYS V3.5 SP16 Patch 3 + 64 bit
Last updated: 2024-06-25

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

Post by gustavocsw on MQTT memory leak problem CODESYS Forge talk (Post)
Hello everyone, I'm using the IoT Library to implement the MQTT communication with my local broker server in order to publish and subscribe at specifics topics to share and consume information about my application. But, it seems that are occurring some memory leak problem in a "high" frequency (more than 10 Hz) subscribe process. I follow the same method as in IoT Lib exemples, and at first looks perfect but my PLC was rebooting frequently and when I check its memory usage that was increasing as fast as the subscribe massage was sent. I'm using a WEG PLC410 and a WEG PLC500, and this error occurred in both of them (including in CODESYS Control Win x64). The application sends to the system a message JSON with the float payload Ex. {"data" : 0.8500}, but this happens with a INT, or BOL as well. I use the follow code in my application to find the value: //FindFirstValueByKey VARs PROGRAM JSON_VELO VAR //------Setting the JSON Subscriber to Set the Relay Value jsonDataVelo : JSON.JSONData; jsonByteArrayReaderVelo : JSON.JSONByteArrayReader; xST1okVelo : BOOL; FindFirstValueByKeyVelo : JSON.FindFirstValueByKey; jsonElementVelo : JSON.JSONElement; xDoneReaderVelo : BOOL; xDoneFindVelo : BOOL; //STRING and WSTRING for Subscribe the massage sPayloadJsonVelo : STRING := 'opa'; psPayloadJsonVelo : POINTER TO BYTE := ADR(sPayloadJsonVelo); //wsPayloadJsonRelaySet : WSTRING := "opa"; wsPayloadJsonVelo : WSTRING := STRING_TO_WSTRING('opa'); pwsPayloadJsonVelo : POINTER TO WORD := ADR(wsPayloadJsonVelo); lrVelo : LREAL; xKeepAliveVelo : BOOL; xSetVelo : BOOL; RSSet : RS; LIMPAR : STRING; //Find the msg end sFindVelo : STRING := '}'; psFindVelo : POINTER TO STRING := ADR(sFindVelo); iLenVelo : INT; iSizeVelo : INT := 12; udiContMsg : UDINT; END_VAR // FindFirstValueByKey CODE // Relay Set configuration xSetVelo := MQTT_SUBSCRIBER.RSVelo.Q1; IF xSetVelo THEN xKeepAliveVelo := TRUE; END_IF IF xKeepAliveVelo THEN udiContMsg := udiContMsg + 1; iLenVelo := TO_INT(StrLenA(psPayloadJsonVelo)); iSizeVelo := iLenVelo - TO_INT(MQTT_SUBSCRIBER.udiPayloadSizeVelo); StrDeleteA(psPayloadJsonVelo,iSizeVelo,iLenVelo); wsPayloadJsonVelo := STRING_TO_WSTRING(sPayloadJsonVelo); pwsPayloadJsonVelo := ADR(wsPayloadJsonVelo); //MQTT.ConvertUTF8toUTF16(sourceStart:= ADR(sPayloadJsonVelo), targetStart:= ADR(wsPayloadJsonVelo), dwTargetBufferSize:= TAM, bStrictConversion:= 1); //Reset jsonByteArrayReader jsonByteArrayReaderVelo ( xExecute := TRUE, pwData := pwsPayloadJsonVelo, jsonData := jsonDataVelo, xDone => xDoneReaderVelo ); FindFirstValueByKeyVelo( xExecute := xDoneReaderVelo, wsKey := "data", diStartIndex:= 0, jsonData := jsonDataVelo, jsonElement => jsonElementVelo, xDone => xDoneFindVelo ); IF xDoneFindVelo THEN lrVelo := jsonElementVelo.value.lrValue; //Reset jsonByteArrayReader jsonByteArrayReaderVelo ( xExecute := FALSE, pwData := pwsPayloadJsonVelo, jsonData := jsonDataVelo, xDone => xDoneReaderVelo ); FindFirstValueByKeyVelo( xExecute := FALSE, wsKey := "data", diStartIndex:= 1, jsonData := jsonDataVelo, jsonElement => jsonElementVelo, xDone => xDoneFindVelo ); xKeepAliveVelo := FALSE; GVL.xSetVeloRead := TRUE; END_IF END_IF And this to subscribe at the topic: //SUBSCRIBE VAR: //----------------- Subscribe Velocity ----------------------- MQTTSubscribeVelo : MQTT.MQTTSubscribe;//Variable MQTTSubscriber block -X - function-X wsTopicSubscribeVelo : WSTRING(1024) := "CORE/odometry/GET/data/simp"; // Topic to publish a message sSubscribeMassageVelo : STRING; udiPayloadSizeVelo : UDINT; xSDoneVelo : BOOL; xSErrorVelo : BOOL; xReceiveVelo : BOOL; eSTypeVelo : MQTT.MQTT_ERROR; eSMQTTErrorVelo : MQTT.MQTT_ERROR; RSVelo : RS; udiCont : UDINT; //SUBSCRIBE CODE: MQTTSubscribeVelo( xEnable:= MQTT_CLIENT.xConnection_Broker AND NOT xSErrorVelo AND NOT JSON_VELO.xKeepAliveVelo, pbPayload:= JSON_VELO.psPayloadJsonVelo, udiMaxPayloadSize:= SIZEOF(JSON_VELO.sPayloadJsonVelo), udiPayloadSize => udiPayloadSizeVelo, mqttClient:= MQTT_CLIENT.ClientMQTT, wsTopicFilter:=wsTopicSubscribeVelo, xDone => xSDoneVelo, xError=> xSErrorVelo, xReceived => xReceiveVelo, eMQTTError=> eSMQTTErrorVelo ); RSVelo(SET := xReceiveVelo, RESET1 := JSON_VELO.xKeepAliveVelo);
Last updated: 2024-09-09

Post by imdatatas on MC_CamIn did not work properly with SMC_FreeEncoder on SoftMotion 4.17.0.0 CODESYS Forge talk (Post)
Hello, I am facing a problem with the new Softmotion 4.17.0.0 version. Has anyone encountered a similar problem, what is the solution? I would be happy if you could share it. Problem description: -- "SMC_FreeEncoder" encoder axis is the master, -- The motor of the servo driver on the EtherCAT bus is the slave axis. -- When the MC_CamIn block executed, the InSync output is activated. However, although the master encoder axis position value changes, there is no movement in the slave servo axis! Test steps: 1-) EtherCAT servo axis installed, configured and motion test was performed with MC_Jog. No problem. 2-) Softmotion general axis pool > SMC_FreeEncoder was added and pulse amount configuration was performed. No problem. 3-) Incremental encoder actual count value was transferred to the "SMC_FreeEncoder.diEncoderPosition" variable as DINT under the ethercat task in every cycle and the encoder axis position value was observed. No problem. 4-) A simple CAM table with a 1:1 ratio was created under the project tree. (For example: Simply, when the encoder rotates 1 turn, the motor will rotate 1 turn.) 5-) The SMC_FreeEncoder axis enabled with MC_Power and brought to the StandStill state. 6-) The MC_CamTableSelect block was run with default input values ​​(all absolute) and only the Cam table name was specified. The Done output was seen successfully. No problem. 7-) The MC_CamIn block was activated with default input values ​​(absolute) and only the master encoder axis name, slave servo axis name, CamTableID input pins was specified and then "Execute" input set to TRUE. 8-) The InSync output information of the MC_CamIn block observed as TRUE. However, although the encoder axis value changed, the position value of the slave axis did not change at all, it did not move. It always remained at 0.0mm. 9-) When I repeated the same steps above, only changing the master axis to SM_Drive_Virtual instead of FreeEncoder and gave movement to the virtual axis, this time the slave axis moved successfully. However, when the same steps and operations are performed with the same IDE just downgrade SoftMotion version from 4.17.0.0 to 4.10.0.0, everything works normally and without problems as expected in MC_CamIn block with FreeEncoder master. (By the way, The used IDE version is Codesys V3.5 SP20patch3.) Best Regards Imdat
Last updated: 2024-11-11

Post by bschraud on Speicherbegrenzung fĂŒr lokale Variablen CODESYS Forge talk (Post)
Aufgrund einer SchnittstellenĂ€nderung muss ich meine Messagebuffer erheblich vergrĂ¶ĂŸern. U.g. Konstante bestimmt die GrĂ¶ĂŸe einer Byte-Array-Definition, die in einer Struktur fĂŒr 9 Botschaften verwendet wird. Ich benötige also 177372byte zusĂ€tzlichen Speicher in dem Modul in dem die Struktur als lokale Variable angelegt wird. Dynamisches Allokieren zur Laufzeit möchte ich vermeiden, damit ich nicht wĂ€hrend des Betriebes Fehler aus dem Allokieren behandeln muss. FĂŒr ein Reservieren des Speicherbereiches habe ich in Codesys keine Einstellmöglichkeiten gefunden. Die Applikation lĂ€ĂŸt sich ohne weitere Modifikation kopilieren, scheitert aber bei der AusfĂŒhrung. Welche Lösungs- oder Einstellmöglichkeiten gibt es? Bei c_w_process_result_content_len_max: WORD := 292; [INFORMATION] GrĂ¶ĂŸe des lizenzierten Benutzercodes: 363304 Bytes [INFORMATION] Speicherverbrauch auf dem GerĂ€t, nicht fĂŒr Lizenzierung verwendet: [INFORMATION] Speicherbereich 0 enthĂ€lt Daten, Eingang, Ausgang, Speicher und Nicht-sichere Daten: GrĂ¶ĂŸe: 2807632 Bytes , höchste verwendete Adresse: 2159712, grĂ¶ĂŸte zusammenhĂ€ngende SpeicherlĂŒcke: 647920 Bytes (23 %) [INFORMATION] Speicherbereich 3 enthĂ€lt Code: GrĂ¶ĂŸe: 7267784 Bytes , höchste verwendete Adresse: 5590600, grĂ¶ĂŸte zusammenhĂ€ngende SpeicherlĂŒcke: 1677184 Bytes (23 %) Übersetzung abgeschlossen -- 0 Fehler, 10 Warnungen : Bereit fĂŒr Download SpeicherprĂŒfung: [WARNUNG] PAC: MC0006: Pointeradresse außerhalb des verwalteten Speichers fĂŒr Eintrag GVL.htFactory._itfInstList.__Interface in Area 0, Offset 0x000033BC (0x71C15414) [WARNUNG] PAC: MC0006: Pointeradresse außerhalb des verwalteten Speichers fĂŒr Eintrag __datasourcesInstancesGVL.__datasourcesInstances.dsInst._allItemsHashtable._ht.__Interface in Area 0, Offset 0x00128904 (0x71D3A95C) [WARNUNG] PAC: MC0009: Pointer to Interface zeigt nicht auf die erwartete Schnittstelle in einer FB-Instanz fĂŒr Eintrag IoConfig_Globals.PiXtend_V2_L_Instance._IIoDrv.__Interface in Area 0, Offset 0x0018EC00 (0x71DA0C58) [WARNUNG] PAC: MC0009: Pointer to Interface zeigt nicht auf die erwartete Schnittstelle in einer FB-Instanz fĂŒr Eintrag IoConfig_Globals.PiXtend_V2_S_DAC_Instance._IIoDrv.__Interface in Area 0, Offset 0x0018F090 (0x71DA10E8) [INFORMATION] PAC: ÜberprĂŒfter Speicher fĂŒr 21336 Objekte. 4 PrĂŒfung(en) fehlgeschlagen. [INFORMATION] PAC: Check took 00:00:13.9743220. Applikation lĂ€sst sich downloaden und funktioniert auf dem GerĂ€t. Nach der VergrĂ¶ĂŸerung: c_w_process_result_content_len_max: WORD := 20000; [INFORMATION] GrĂ¶ĂŸe des lizenzierten Benutzercodes: 363304 Bytes [INFORMATION] Speicherverbrauch auf dem GerĂ€t, nicht fĂŒr Lizenzierung verwendet: [INFORMATION] Speicherbereich 0 enthĂ€lt Daten, Eingang, Ausgang, Speicher und Nicht-sichere Daten: GrĂ¶ĂŸe: 4114264 Bytes , höchste verwendete Adresse: 3164816, grĂ¶ĂŸte zusammenhĂ€ngende SpeicherlĂŒcke: 949448 Bytes (23 %) [INFORMATION] Speicherbereich 3 enthĂ€lt Code: GrĂ¶ĂŸe: 7267832 Bytes , höchste verwendete Adresse: 5590640, grĂ¶ĂŸte zusammenhĂ€ngende SpeicherlĂŒcke: 1677192 Bytes (23 %) Übersetzung abgeschlossen -- 0 Fehler, 10 Warnungen : Bereit fĂŒr Download SpeicherprĂŒfung: (gleiches Ergebnis wie vorher) [WARNUNG] PAC: MC0006: Pointeradresse außerhalb des verwalteten Speichers fĂŒr Eintrag GVL.htFactory._itfInstList.__Interface in Area 0, Offset 0x000033BC (0x71C15414) [WARNUNG] PAC: MC0006: Pointeradresse außerhalb des verwalteten Speichers fĂŒr Eintrag __datasourcesInstancesGVL.__datasourcesInstances.dsInst._allItemsHashtable._ht.__Interface in Area 0, Offset 0x0021DF38 (0x71E2FF90) [WARNUNG] PAC: MC0009: Pointer to Interface zeigt nicht auf die erwartete Schnittstelle in einer FB-Instanz fĂŒr Eintrag IoConfig_Globals.PiXtend_V2_L_Instance._IIoDrv.__Interface in Area 0, Offset 0x00284238 (0x71E96290) [WARNUNG] PAC: MC0009: Pointer to Interface zeigt nicht auf die erwartete Schnittstelle in einer FB-Instanz fĂŒr Eintrag IoConfig_Globals.PiXtend_V2_S_DAC_Instance._IIoDrv.__Interface in Area 0, Offset 0x002846C8 (0x71E96720) [INFORMATION] PAC: ÜberprĂŒfter Speicher fĂŒr 21336 Objekte. 4 PrĂŒfung(en) fehlgeschlagen. [INFORMATION] PAC: Check took 00:00:14.0491831. Applikation lĂ€sst sich downloaden. AusfĂŒhren mĂŒndet in Ausnahmefehler Die Applikation lĂ€uft auf der Runtime CODESYS Control for Raspberry Pi MC SL. Die Codesys Version ist 3.5 SP20 mit allen Updates. Kennt jemand eine Speichergrenze fĂŒr lokale Variablen bzw. eventuelle Einstellmöglichkeiten? Vielen Dank
Last updated: 2024-05-06

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

<< < 1 .. 121 122 123 124 > >> (Page 123 of 124)

Showing results of 3079

Sort by relevance or date