Post by umdee on Error when monitoring LAD programs ^{CODESYS Forge talk (Post)}
System Information from the computer being used: OS Name Microsoft Windows 11 Pro Version 10.0.22631 Build 22631 Other OS Description Not Available OS Manufacturer Microsoft Corporation System Manufacturer Dell Inc. System Model Latitude 5500 System Type x64-based PC System SKU 08B9 Processor Intel(R) Core(TM) i7-8665U CPU @ 1.90GHz, 2112 Mhz, 4 Core(s), 8 Logical Processor(s) BIOS Version/Date Dell Inc. 1.3.11, 6/11/2019 SMBIOS Version 3.2 Embedded Controller Version 255.255 BIOS Mode UEFI BaseBoard Manufacturer Dell Inc. BaseBoard Product 0M14W7 BaseBoard Version A00 Platform Role Mobile Secure Boot State On PCR7 Configuration Elevation Required to View Windows Directory C:\WINDOWS System Directory C:\WINDOWS\system32 Boot Device \Device\HarddiskVolume1 Locale United States Hardware Abstraction Layer Version = "10.0.22621.2506" User Name CARDASSIA-IX\Engineer Time Zone Eastern Daylight Time Installed Physical Memory (RAM) 16.0 GB Total Physical Memory 15.8 GB Available Physical Memory 4.67 GB Total Virtual Memory 18.5 GB Available Virtual Memory 2.52 GB Page File Space 2.63 GB Page File C:\pagefile.sys Kernel DMA Protection Off Virtualization-based security Not enabled Windows Defender Application Control policy Enforced Windows Defender Application Control user mode policy Off Device Encryption Support Elevation Required to View Hyper-V - VM Monitor Mode Extensions Yes Hyper-V - Second Level Address Translation Extensions Yes Hyper-V - Virtualization Enabled in Firmware Yes Hyper-V - Data Execution Protection Yes
Last updated: 2024-03-19

Post by tomast on Codesys and Siemens SINAMICS 20 modbus RTU "Response CRC Fail" ^{CODESYS Forge talk (Post)}
Hi everyone, I'm currently working on a project involving the control of 5 VFDs via Modbus RTU, this time using the WAGO 750-8212 CPU. So far, I've managed to make progress, but I've encountered an issue. While I can successfully read and write to all the registers I need, I consistently encounter a "Response CRC Fail" error when attempting to write the value 1151 to the STW register at address 40100. I'm able to set the frequency via register 40101 and adjust all other parameters using different registers. Setting STW to 1150 results in the drive ready boolean from the ZSW-bit being received instantly. However, the moment I attempt to send 1151 to register 40100, I immediately receive the "Response CRC Fail" error for all channels. I've also attempted to use combined control, employing Modbus for frequency control and starting from a digital input. Everything seems to function properly until I send the start command to the VFD. Interestingly, I consistently encounter the same error the moment I send the start command, regardless of whether I use register 40006 (high) or 40100 (1151). Could someone please assist me in resolving this issue?
Last updated: 2024-03-21

Post by sanacfu on looking for v2.3 libraries on v3.5.19 ^{CODESYS Forge talk (Post)}
Hi all, I'm new to Codesys and Wago but well versed in Rockwell. I've been tasked with upgrading old Wago 750-880 PLCs that run Codesys v2.3. All I was giving is the original PLC program in v2.3 and the currently running machine. I've spec out to what I believe is a suitable upgrade, the PFC100 2ndGen, 750-8111. As I'm rewriting this code on the Codesys I can't find the same library functions blocks for ethernet settings PLC functions. Currently I'm working on code to get/set the PLC ethernet IP address and HMI IP addresses from the HMI screen. One other function I'm looking for is a warm reset function to the PLC. When googling for this stuff I see a lot of code not in ladder logic. Are these functions now not available to implement in ladder logic? Where can I get more information on finding and implementing this functions? Do I have to buy a license from Codesys to use these functions? The PLC I ordered should be arriving in 2-3 weeks.
Last updated: 2024-03-25

Post by ahuckphin on Issues with Modbus Slave with Raspberry Pi ^{CODESYS Forge talk (Post)}
I have a DFRobot RS485 temperature & humidity sensor (SEN0438) connected to my Raspberry Pi via a USB to RS485 adapter. I am able to connect and read the sensor data when running a python code locally. However in Codesys, I encounter this error "A bus error has occurred." and "There was no response in time". Could this be because of Modbus Server Channel and Modbus Server Init configuration on my part? Admittedly I am new to Codesys. To get to this stage, I: 1. added some lines to CODESYSControl_User.cfg 2. added "Modbus_COM" in Codesys and set "Serial Port Configuration" under "General" 3. added "Modbus_Master_COM_Port" in Codesys and checked transmission mode is set to "RTU" 4. added "Modbus_Slave_COM_Port" in Codesys and checked server address is set to 1 (also set 1 in my sensor) 5. added 1 channel and 1 init for "Modbus_Slave_COM_Port" under "Modbus Server Channel" and "Modbus Server Init"
Last updated: 2024-07-10

Post by otbeka on CmpCrypto CryptoGenerateHash Not Outputting ^{CODESYS Forge talk (Post)}
Hi, I have been trying to use CryptoGenerateHash from the CmpCrypto Implementation library. My code is taken almost directly from the CryptoDemo.project example provided on Codesys Forge, yet the CryptoGenerateHash function does not write to the address listed in pHash. RTS_IEC_RESULT is OK, but I am getting nothing out of the function. No errors either, all my libraries are up to date. Any help would be appreicated! PROGRAM PLC_PRG VAR sMessage : MESSAGE := 'The red fox runs across the ice'; abyHashCode : HASH_CODE := [ 16#52, 16#ED, 16#87, 16#9E, 16#70, 16#F7, 16#1D, 16#92, 16#6E, 16#B6, 16#95, 16#70, 16#08, 16#E0, 16#3C, 16#E4, 16#CA, 16#69, 16#45, 16#D3 ]; xMessageOK : BOOL; END_VAR xMessageOK := CheckMessage(sMessage, abyHashCode); FUNCTION CheckMessage : BOOL VAR_INPUT sMessage : REFERENCE TO MESSAGE; abyHashCode : REFERENCE TO HASH_CODE; END_VAR VAR _hHASH : RTS_IEC_HANDLE := CryptoGetAlgorithmById(ui32CryptoID:=RtsCryptoID.HASH_SHA1, pResult:=0); Result : RTS_IEC_RESULT; bsMessage : RtsByteString := (ui32MaxLen:=SIZEOF(sMessage), pByData:=ADR(sMessage), ui32Len:=TO_UDINT(LEN(sMessage))); abyNewHashCode : HASH_CODE; bsNewHashCode : RtsByteString := (ui32MaxLen:=SIZEOF(abyNewHashCode), pByData:=ADR(abyNewHashCode)); diCmpResult : DINT; END_VAR Result := CryptoGenerateHash(hAlgo:=_hHASH, pData:=ADR(bsMessage), pHash:=ADR(bsNewHashCode)); diCmpResult := SysMemCmp(pBuffer1:=ADR(abyHashCode), pBuffer2:=ADR(abyNewHashCode), udiCount:=SIZEOF(HASH_CODE)); CheckMessage := diCmpResult = 0;
Last updated: 2024-09-06

Post by fabiodasilveira on PLC Shell commands via ST Code ^{CODESYS Forge talk (Post)}
Hello Everybody, I have created a project for an Eaton XC303 that sends lots of data to a router via UDP. It works fine. However, when there is more than one product connected to the router, then it is necessary to change the IP address of the Ethernet port 0, from e.g. 192.168.2.11 to 192.168.2.12 (second product). It is easily done via PLC Shell (setipaddr 0 192.168.2.12), but the people in production is struggling with the PLC Shell commands and I would like to create a Visualization page that will hide that. I used the instruction: eChangeIPResult:= SysSockSetIPAddress(strEthernetPort, strIPAddress); and it works, until the PLC resets. I already read some posts and it appears that I need to stop the Ethernet 0 port and Reconfigure it, but I am really struggling to find the right way to do it. Any help will be much appreciated.
Last updated: 2025-02-28

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 kevintumibay on Struggling to connect to EK1100 to Raspberry Pi ^{CODESYS Forge talk (Post)}
SUMMARIZED VERSION OF QUESTION: I'm trying to connect a Raspberry Pi running "Codesys Control for Raspberry Pi" to a Beckhoff EK1100, unfortunately, when I try to connect I get the following messages SEE FIRST PICTURE DETAILED VERSION OF QUESTION: Hi everyone, I'm a college student that is super interested in learning about PLCs. I wanted to dive into the subject and decided to follow this great Instructables article: https://www.instructables.com/Programming-Raspberry-Pi-With-CODESYS/ Thank you in advance for your help! My current setup is as follows: 1. I have Codesys Control for Raspberry Pi, version 4.14.0.0, (https://store.codesys.com/en/codesys-control-for-raspberry-pi-sl.html) installed on a Raspberry Pi 3B. 2. I am using my smartphone hotspot to create a network. 3. I have CODESYS 3.5 SP21 (64 bit) installed on my Windows 11 laptop. 4. Both the Raspberry Pi and my laptop are connected to the smartphone hotspot network (I am wirelessly connecting to the Raspberry Pi). Connecting to the Raspberry Pi from CODESYS on my laptop: 1. I launch Codesys Installer -> I install Codesys Control for Raspberry Pi (link to the software). 2. I launch Codesys 3.5 SP21 (64 bit) on my laptop. 3. I go to file --> new project --> standard project --> in the pop-up I select "Codesys Control for Raspberry Pi" and "Structured Text" 4. I click on tools -> Deploy Control SL (on older versions of Codesys you would click on "update Raspberry Pi", I got that information from this video: link) 5. Inside Deploy Control SL --> I go to the "communication" menu and I input the IP address of my Pi, the password, and click on connect. 6. Inside Deploy Control SL --> I go to the "deployment" menu and I install Codesys Control for Raspberry Pi SL and Codesys Edge Gateway for Linux 7. Now I double click on "device" in the left hand tree and put in the IP address of my Raspberry Pi and click on connect --> success! I am able to connect! SEE SECOND PICTURE Powering the EK1100 and connecting it to the Raspberry Pi: 1. I am supplying the EK1100 with 24 V across the + and - pins. 2. I have jumper wires going from the + pin to the 24V pin and from the - pin to the 0V pin. SEE THIRD PICTURE 4. I am pretty confident that the EK1100 is receiving power because the "LED Us 24 V" and "LED Up 24 V" are lighting up. 5. I then run an ethernet cable from the EK1100 to the Raspberry Pi port (the Raspberry Pi is connected to my laptop wirelessly over WiFi). I think this connection should also be good since the LINK/ACT LED lights up. Trying to connect to the EK1100: 1. Back in Codesys I right-click on "Device" in the left tree and then in the pop up I click on "add device". 2. I then click on EtherCAT Master. 3. Next in a terminal window I SSH into the raspberry Pi and run the "ifconfig" command. 4. From there I get the MAC address for eth0 --> in my case: b8:27:eb:29:a9:25 5. Then, back in Codesys I double click on "EtherCAT Master" in the left hand tree. I then paste the MAC address into the "Source Address (MAC)" field. 6. I go to the Beckhoff official website and download the XML files for EtherCAT: https://www.beckhoff.com/en-en/products/i-o/ethercat-terminals/ek1xxx-bk1xx0-ethercat-coupler/ek1100.html? 7. I unzip those files in my computer into some folder that I can remember. 8. Back in Codesys I click on "Tools" --> "Device Repository" --> "Install" --> and then on the "Beckhoff EK11xx.XML" file. 9. In theory the necessary XML file is now installed. 10. THIS IS WHERE I RUN INTO THE PROBLEM: I then click on login --> I right click on EtherCAT_Master and then scan for devices --> and nothing. 11. It just doesn't detect it. On top of this whenever I login I get those orange triangles on the left on my tree. When I check the Log I get the messages at the very first screenshot of this post. SEE FOURTH PICTURE Solutions that I have tried to resolve this problem: 1. I thought it was maybe the .XML file so I installed all the .XML files from the EtherCAT folder that I downloaded. That didn't fix it. 2. I went on the Wayback Machine and got the .XML files from 2018 as I thought maybe an older version would work. This file of EtherCAT folders had a .XML file named "Beckhoff EKxxxx.XML" I thought this would work because that's the name of the file the guy in the Instructables used (https://www.instructables.com/Programming-Raspberry-Pi-With-CODESYS/). That didn't do anything. 3. I ran the PLC on my computer instead of the Raspberry Pi and tried to connect to the EK1100, in case the issue was with the Raspberry Pi, but I still ran into the same error from the picture above: "Attention! The device was not found in the repository. Vendorcode: 0x0. Productcode: 0x0. Revision: 0x0". SEE FIFTH PICTURE 4. I reinstalled Codesys, I was originally on version 3.5 SP20 when I did this, I upgraded to 3.5 SP21 with no success. 5. I then thought the solution might be to first add the EK1100 hardware before connecting so I did the following: 6. Right click on "EtherCAT Master" on the left hand tree --> then click on "add device" --> then I added the "EK1100 EtherCAT Coupler (2A E-Bus)" MY THEORY OF WHAT IS CAUSING THE PROBLEM: I asked ChatGPT for help and it said that it might have something to do with the revision number. On the physical EK1100 it says "Rev. Nr.: 0018". I believe that this means that I need to a revision 0018 XML file but if you look in Codesys it says the version is 16 (picture above). This is confusing because I got my .XML file from the official Codesys website so it should be the most up to date version possible. I searched and I searched and I couldn't find a version 18 .XML file, I don't even now if this exists. Any help you can provide is greatly appreciated, I don't know what to do anymore and I really really want to get this working. Thank you!
Last updated: 2025-03-30

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 cdutz on Problems connecting to Codesys 4.9.0.0 runtime on my Wago PFC200 ^{CODESYS Forge talk (Post)}
Hi all. I am currently struggling to get my Wago PFC200 running the Codesys Runtime in version 4.9.0.0 working. I am using Codesys V3.5SP19. I updated the PFC200 to the firmware version 04.01.10(23) after having tried the latest version (04.03.03(25) from Wago and not being able to start the runtime. After reading version 23 was needed, I changed to that and at least was able to have it start the codesys runtime. I also installed the "Codesys Control for PFC200 SL 4.9.0.0" plugin for Codesys to install the Codesys runtime in version 4.9.0.0 as well as update the Gateway on the device. While I seem to be able to connect to the gateway on the PLC (the dot is green) and when doing a scan, I do now find my PFC200, which is a huge improvement to before, where with firmware version 25 it just failed to start the runtime and I never found any device when doing a scan. Unfortunately I don't seem to be able to connect to the PLC in codesys. I logged in via SSH and changed the password and I can see that this password is correct as the stuff in the Codesys PFC200 tools tab only works if I use my changed password. And I used those credentials to update the installed Runtime version, which the log claimed to have worked fine. Now whenever I try to connect to the device found in the scan, I get a authentication pop-up with empy device name, device address: 000A. As User I use "root" and as password the password that I changed it to. As a response I just get "Ungültige Benutzerauthentifizierung auf dem Gerät" (Eng. probably something like "Invalid user authentication on the device". What could I be doing wrong? Admittedly I'm a bit lost here :-/ Chris
Last updated: 2023-08-26

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 derpaul on Official MQTT-Client: MAX_RECEIVE_BUFFER_SIZE_EXCEEDED ^{CODESYS Forge talk (Post)}
Here is the output Codesyscontrol.log ;**************************************************************** ;<loggername>/tmp/codesyscontrol.log</loggername> ;<logoptions> ; <enable>1</enable> ; <type>normal</type> ; <timestamp>rtc</timestamp> ; <deactivatable>0</deactivatable> ; <dump>always</dump> ; <filter>0x0000000f<filter> ; <maxentries>1000</maxentries> ; <maxfiles>1</maxfiles> ; <maxfilesize>1000000</maxfilesize> ;</logoptions> ;<entries> ;Timestamp, CmpId, ClassId, ErrorId, InfoId, InfoText ;ClassId: LOG_INFO =1 ;ClassId: LOG_WARNING =2 ;ClassId: LOG_ERROR =4 ;ClassId: LOG_EXCEPTION =8 ;ClassId: LOG_DEBUG =16 ;ClassId: LOG_PRINTF =32 ;ClassId: LOG_COM =64 ;</entries> ;**************************************************************** 2023-09-12T21:11:41Z, 0x00000013, 1, 0, 0, <logoptions> 2023-09-12T21:11:41Z, 0x00000013, 1, 0, 0, <bEnable>1</bEnable> 2023-09-12T21:11:41Z, 0x00000013, 1, 0, 0, <type>normal</type> 2023-09-12T21:11:41Z, 0x00000013, 1, 0, 0, <timestamp>rtc</timestamp> 2023-09-12T21:11:41Z, 0x00000013, 1, 0, 0, <disableable>0</disableable> 2023-09-12T21:11:41Z, 0x00000013, 1, 0, 0, <Filter>0x0000000f</Filter> 2023-09-12T21:11:41Z, 0x00000013, 1, 0, 0, <MaxEntries>1000</MaxEntries> 2023-09-12T21:11:41Z, 0x00000013, 1, 0, 0, <MaxFiles>1</MaxFiles> 2023-09-12T21:11:41Z, 0x00000013, 1, 0, 0, <MaxFileSize>1000000</MaxFileSize> 2023-09-12T21:11:41Z, 0x00000013, 1, 0, 0, </logoptions> 2023-09-12T21:11:41Z, 0x00000001, 1, 0, 4, CODESYS Control for PFC200 SL 2023-09-12T21:11:41Z, 0x00000001, 1, 0, 4, OS=Linux, CPU=ARM, Arch=32Bit, Coding=C 2023-09-12T21:11:41Z, 0x00000001, 1, 0, 6, <version>3.5.16.40</version> <builddate>Mar 2 2021</builddate> 2023-09-12T21:11:41Z, 0x00000001, 1, 0, 5, Copyright (c) 3S - Smart Software Solutions GmbH 2023-09-12T21:11:41Z, 0x00000001, 1, 0, 10, System: <cmp>CM</cmp>, <id>0x00000001</id> <ver>3.5.16.40</ver> 2023-09-12T21:11:41Z, 0x00000001, 1, 0, 10, System: <cmp>CmpMemPool</cmp>, <id>0x0000001e</id> <ver>3.5.16.0</ver> 2023-09-12T21:11:41Z, 0x00000001, 1, 0, 10, System: <cmp>CmpLog</cmp>, <id>0x00000013</id> <ver>3.5.16.0</ver> 2023-09-12T21:11:41Z, 0x00000001, 1, 0, 10, System: <cmp>CmpSettings</cmp>, <id>0x0000001a</id> <ver>3.5.16.0</ver> 2023-09-12T21:11:41Z, 0x00000001, 1, 0, 10, System: <cmp>SysFile</cmp>, <id>0x00000104</id> <ver>3.5.16.40</ver> 2023-09-12T21:11:41Z, 0x00000001, 1, 0, 10, System: <cmp>SysCom</cmp>, <id>0x00000100</id> <ver>3.5.16.0</ver> 2023-09-12T21:11:41Z, 0x00000001, 1, 0, 10, System: <cmp>SysCpuHandling</cmp>, <id>0x00000101</id> <ver>3.5.16.0</ver> 2023-09-12T21:11:41Z, 0x00000001, 1, 0, 10, System: <cmp>SysDir</cmp>, <id>0x0000011b</id> <ver>3.5.16.40</ver> 2023-09-12T21:11:41Z, 0x00000001, 1, 0, 10, System: <cmp>SysEthernet</cmp>, <id>0x0000011c</id> <ver>3.5.16.10</ver> 2023-09-12T21:11:41Z, 0x00000001, 1, 0, 10, System: <cmp>SysEvent</cmp>, <id>0x00000102</id> <ver>3.5.16.0</ver> 2023-09-12T21:11:41Z, 0x00000001, 1, 0, 10, System: <cmp>SysExcept</cmp>, <id>0x00000103</id> <ver>3.5.16.0</ver> 2023-09-12T21:11:41Z, 0x00000001, 1, 0, 10, System: <cmp>SysInternalLib</cmp>, <id>0x00000107</id> <ver>3.5.16.0</ver> 2023-09-12T21:11:41Z, 0x00000001, 1, 0, 10, System: <cmp>SysMem</cmp>, <id>0x00000108</id> <ver>3.5.16.0</ver> 2023-09-12T21:11:41Z, 0x00000001, 1, 0, 10, System: <cmp>SysModule</cmp>, <id>0x00000109</id> <ver>3.5.16.40</ver> 2023-09-12T21:11:41Z, 0x00000001, 1, 0, 10, System: <cmp>SysMsgQ</cmp>, <id>0x0000010a</id> <ver>3.5.16.0</ver> 2023-09-12T21:11:41Z, 0x00000001, 1, 0, 10, System: <cmp>SysMutex</cmp>, <id>0x0000013a</id> <ver>3.5.16.0</ver> 2023-09-12T21:11:41Z, 0x00000001, 1, 0, 10, System: <cmp>SysOut</cmp>, <id>0x0000010b</id> <ver>3.5.16.0</ver> 2023-09-12T21:11:41Z, 0x00000001, 1, 0, 10, System: <cmp>SysProcess</cmp>, <id>0x0000010e</id> <ver>3.5.16.0</ver> 2023-09-12T21:11:41Z, 0x00000001, 1, 0, 10, System: <cmp>SysSem</cmp>, <id>0x0000010f</id> <ver>3.5.16.0</ver> 2023-09-12T21:11:41Z, 0x00000001, 1, 0, 10, System: <cmp>SysSemCount</cmp>, <id>0x00000139</id> <ver>3.5.16.0</ver> 2023-09-12T21:11:41Z, 0x00000001, 1, 0, 10, System: <cmp>SysSemProcess</cmp>, <id>0x00000119</id> <ver>3.5.16.0</ver> 2023-09-12T21:11:41Z, 0x00000001, 1, 0, 10, System: <cmp>SysShm</cmp>, <id>0x00000110</id> <ver>3.5.16.0</ver> 2023-09-12T21:11:41Z, 0x00000001, 1, 0, 10, System: <cmp>SysSocket</cmp>, <id>0x00000111</id> <ver>3.5.16.30</ver> 2023-09-12T21:11:41Z, 0x00000001, 1, 0, 10, System: <cmp>SysTarget</cmp>, <id>0x00000112</id> <ver>3.5.16.40</ver> 2023-09-12T21:11:41Z, 0x00000001, 1, 0, 10, System: <cmp>SysTask</cmp>, <id>0x00000114</id> <ver>3.5.16.0</ver> 2023-09-12T21:11:41Z, 0x00000001, 1, 0, 10, System: <cmp>SysTime</cmp>, <id>0x00000115</id> <ver>3.5.16.0</ver> 2023-09-12T21:11:41Z, 0x00000001, 1, 0, 10, System: <cmp>SysTimeRtc</cmp>, <id>0x00000127</id> <ver>3.5.16.30</ver> 2023-09-12T21:11:41Z, 0x00000001, 1, 0, 10, System: <cmp>SysTimer</cmp>, <id>0x00000116</id> <ver>3.5.16.0</ver> 2023-09-12T21:11:41Z, 0x00000001, 1, 0, 10, <cmp>CmpAlarmManager</cmp>, <id>0x0000007c</id> <ver>3.5.16.0</ver> 2023-09-12T21:11:41Z, 0x00000001, 1, 0, 10, <cmp>CmpApp</cmp>, <id>0x00000002</id> <ver>3.5.16.30</ver> 2023-09-12T21:11:41Z, 0x00000001, 1, 0, 10, <cmp>CmpAppBP</cmp>, <id>0x00000073</id> <ver>3.5.16.10</ver> 2023-09-12T21:11:41Z, 0x00000001, 1, 0, 10, <cmp>CmpAppForce</cmp>, <id>0x00000074</id> <ver>3.5.16.10</ver> 2023-09-12T21:11:41Z, 0x00000001, 1, 0, 10, <cmp>CmpAsyncMgr</cmp>, <id>0x0000005f</id> <ver>3.5.16.0</ver> 2023-09-12T21:11:41Z, 0x00000001, 1, 0, 10, <cmp>CmpBinTagUtil</cmp>, <id>0x00000004</id> <ver>3.5.16.0</ver> 2023-09-12T21:11:41Z, 0x00000001, 1, 0, 10, <cmp>CmpBinTagUtilIec</cmp>, <id>0x0000005c</id> <ver>3.5.16.0</ver> 2023-09-12T21:11:41Z, 0x00000001, 1, 0, 10, <cmp>CmpBitmapPool</cmp>, <id>0x00000050</id> <ver>3.5.16.0</ver> 2023-09-12T21:11:41Z, 0x00000001, 1, 0, 10, <cmp>CmpBlkDrvTcp</cmp>, <id>0x00000030</id> <ver>3.5.16.0</ver> 2023-09-12T21:11:41Z, 0x00000001, 1, 0, 10, <cmp>CmpBlkDrvUdp</cmp>, <id>0x00000007</id> <ver>3.5.16.0</ver> 2023-09-12T21:11:41Z, 0x00000001, 1, 0, 10, <cmp>CmpCAAAsyncMan</cmp>, <id>0x00004007</id> <ver>3.5.16.0</ver> 2023-09-12T21:11:41Z, 0x00000001, 1, 0, 10, <cmp>CmpCAABehaviourModel</cmp>, <id>0x00004015</id> <ver>3.5.16.0</ver> 2023-09-12T21:11:41Z, 0x00000001, 1, 0, 10, <cmp>CmpCAACallback</cmp>, <id>0x00004001</id> <ver>3.5.16.0</ver> 2023-09-12T21:11:41Z, 0x00000001, 1, 0, 10, <cmp>CmpCAACanL2</cmp>, <id>0x00004004</id> <ver>3.5.16.0</ver> 2023-09-12T21:11:41Z, 0x00000001, 1, 0, 10, <cmp>CmpCAADTUtil</cmp>, <id>0x00004013</id> <ver>3.5.16.10</ver> 2023-09-12T21:11:41Z, 0x00000001, 1, 0, 10, <cmp>CmpCAAFile</cmp>, <id>0x00004008</id> <ver>3.5.16.0</ver> 2023-09-12T21:11:41Z, 0x00000001, 1, 0, 10, <cmp>CmpCAAMemBlockMan</cmp>, <id>0x00004003</id> <ver>3.5.16.0</ver> 2023-09-12T21:11:41Z, 0x00000001, 1, 0, 10, <cmp>CmpCAANetBaseServices</cmp>, <id>0x00004018</id> <ver>3.5.16.0</ver> 2023-09-12T21:11:41Z, 0x00000001, 1, 0, 10, <cmp>CmpCAARealTimeClock</cmp>, <id>0x00004014</id> <ver>3.5.16.0</ver> 2023-09-12T21:11:41Z, 0x00000001, 1, 0, 10, <cmp>CmpCAASdoClient</cmp>, <id>0x00004011</id> <ver>3.5.16.0</ver> 2023-09-12T21:11:41Z, 0x00000001, 1, 0, 10, <cmp>CmpCAASdoServer</cmp>, <id>0x00004017</id> <ver>3.5.16.0</ver> 2023-09-12T21:11:41Z, 0x00000001, 1, 0, 10, <cmp>CmpCAASegBufferMan</cmp>, <id>0x00004019</id> <ver>3.5.16.0</ver> 2023-09-12T21:11:41Z, 0x00000001, 1, 0, 10, <cmp>CmpCAASerialCom</cmp>, <id>0x00004012</id> <ver>3.5.16.0</ver> 2023-09-12T21:11:41Z, 0x00000001, 1, 0, 10, <cmp>CmpCAAStorage</cmp>, <id>0x0000007e</id> <ver>3.5.16.30</ver> 2023-09-12T21:11:41Z, 0x00000001, 1, 0, 10, <cmp>CmpCAATick</cmp>, <id>0x00004009</id> <ver>3.5.16.0</ver> 2023-09-12T21:11:41Z, 0x00000001, 1, 0, 10, <cmp>CmpCAATickUtil</cmp>, <id>0x00004010</id> <ver>3.5.16.0</ver> 2023-09-12T21:11:41Z, 0x00000001, 1, 0, 10, <cmp>CmpCAATimer</cmp>, <id>0x00004016</id> <ver>3.5.16.0</ver> 2023-09-12T21:11:41Z, 0x00000001, 1, 0, 10, <cmp>CmpCAATypes</cmp>, <id>0x00004006</id> <ver>3.5.16.0</ver> 2023-09-12T21:11:41Z, 0x00000001, 1, 0, 10, <cmp>CmpChannelClient</cmp>, <id>0x00000008</id> <ver>3.5.16.0</ver> 2023-09-12T21:11:41Z, 0x00000001, 1, 0, 10, <cmp>CmpChannelClientIec</cmp>, <id>0x0000005d</id> <ver>3.5.16.0</ver> 2023-09-12T21:11:41Z, 0x00000001, 1, 0, 10, <cmp>CmpChannelMgr</cmp>, <id>0x00000009</id> <ver>3.5.16.0</ver> 2023-09-12T21:11:41Z, 0x00000001, 1, 0, 10, <cmp>CmpChannelServer</cmp>, <id>0x0000000a</id> <ver>3.5.16.0</ver> 2023-09-12T21:11:41Z, 0x00000001, 1, 0, 10, <cmp>CmpCharDevice</cmp>, <id>0x00000300</id> <ver>3.5.16.0</ver> 2023-09-12T21:11:41Z, 0x00000001, 1, 0, 10, <cmp>CmpChecksum</cmp>, <id>0x0000000b</id> <ver>3.5.16.0</ver> 2023-09-12T21:11:41Z, 0x00000001, 1, 0, 10, <cmp>CmpCodeMeter</cmp>, <id>0x0000007a</id> <ver>3.5.16.30</ver> 2023-09-12T21:11:41Z, 0x00000001, 1, 0, 10, <cmp>CmpCommunicationLib</cmp>, <id>0x0000000c</id> <ver>3.5.16.0</ver> 2023-09-12T21:11:41Z, 0x00000001, 1, 0, 10, <cmp>CmpCoreDump</cmp>, <id>0x00000083</id> <ver>3.5.16.0</ver> 2023-09-12T21:11:41Z, 0x00000001, 1, 0, 10, <cmp>CmpCryptMD5</cmp>, <id>0x0000006a</id> <ver>3.5.16.0</ver> 2023-09-12T21:11:41Z, 0x00000001, 1, 0, 10, <cmp>CmpDevice</cmp>, <id>0x0000000e</id> <ver>3.5.16.10</ver> 2023-09-12T21:11:41Z, 0x00000001, 1, 0, 10, <cmp>CmpDynamicText</cmp>, <id>0x00000051</id> <ver>3.5.16.0</ver> 2023-09-12T21:11:41Z, 0x00000001, 1, 0, 10, <cmp>CmpEL6751CanDrv</cmp>, <id>0x00005f0b</id> <ver>3.5.16.0</ver> 2023-09-12T21:11:41Z, 0x00000001, 1, 0, 10, <cmp>CmpEventMgr</cmp>, <id>0x0000005b</id> <ver>3.5.16.30</ver> 2023-09-12T21:11:41Z, 0x00000001, 1, 0, 10, <cmp>CmpFileTransfer</cmp>, <id>0x0000005e</id> <ver>3.5.16.10</ver> 2023-09-12T21:11:41Z, 0x00000001, 1, 0, 10, <cmp>CmpIecStringUtils</cmp>, <id>0x0000007f</id> <ver>3.5.16.0</ver> 2023-09-12T21:11:41Z, 0x00000001, 1, 0, 10, <cmp>CmpIecTask</cmp>, <id>0x00000011</id> <ver>3.5.16.40</ver> 2023-09-12T21:11:41Z, 0x00000001, 1, 0, 10, <cmp>CmpIecVarAccess</cmp>, <id>0x00000060</id> <ver>3.5.16.30</ver> 2023-09-12T21:11:41Z, 0x00000001, 1, 0, 10, <cmp>CmpIoDrvIec</cmp>, <id>0x0000005a</id> <ver>3.5.16.0</ver> 2023-09-12T21:11:41Z, 0x00000001, 1, 0, 10, <cmp>CmpIoMgr</cmp>, <id>0x00000012</id> <ver>3.5.16.0</ver> 2023-09-12T21:11:41Z, 0x00000001, 1, 0, 10, <cmp>CmpKbus</cmp>, <id>0x0000008a</id> <ver>4.0.1.0</ver> 2023-09-12T21:11:41Z, 0x00000001, 1, 0, 10, <cmp>CmpKnxStack</cmp>, <id>0x0000004d</id> <ver>3.5.16.0</ver> 2023-09-12T21:11:41Z, 0x00000001, 1, 0, 10, <cmp>CmpMonitor2</cmp>, <id>0x00000032</id> <ver>3.5.16.10</ver> 2023-09-12T21:11:41Z, 0x00000001, 1, 0, 10, <cmp>CmpNameServiceClient</cmp>, <id>0x00000015</id> <ver>3.5.16.0</ver> 2023-09-12T21:11:41Z, 0x00000001, 1, 0, 10, <cmp>CmpNameServiceClientIec</cmp>, <id>0x0000011d</id> <ver>3.5.16.0</ver> 2023-09-12T21:11:41Z, 0x00000001, 1, 0, 10, <cmp>CmpNameServiceServer</cmp>, <id>0x00000016</id> <ver>3.5.16.0</ver> 2023-09-12T21:11:41Z, 0x00000001, 1, 0, 10, <cmp>CmpOPCUAClient</cmp>, <id>0x00000096</id> <ver>3.5.16.40</ver> 2023-09-12T21:11:41Z, 0x00000001, 1, 0, 10, <cmp>CmpOPCUAProviderIecVarAccess</cmp>, <id>0x00000126</id> <ver>3.5.16.40</ver> 2023-09-12T21:11:41Z, 0x00000001, 1, 0, 10, <cmp>CmpOPCUAServer</cmp>, <id>0x00000124</id> <ver>3.5.16.40</ver> 2023-09-12T21:11:41Z, 0x00000001, 1, 0, 10, <cmp>CmpOPCUAStack</cmp>, <id>0x0000008d</id> <ver>3.5.16.40</ver> 2023-09-12T21:11:41Z, 0x00000001, 1, 0, 10, <cmp>CmpOpenSSL</cmp>, <id>0x00000033</id> <ver>3.5.16.40</ver> 2023-09-12T21:11:41Z, 0x00000001, 1, 0, 10, <cmp>CmpPfcx00</cmp>, <id>0x00000088</id> <ver>4.0.1.0</ver> 2023-09-12T21:11:41Z, 0x00000001, 1, 0, 10, <cmp>CmpPlcShell</cmp>, <id>0x00000128</id> <ver>3.5.16.0</ver> 2023-09-12T21:11:41Z, 0x00000001, 1, 0, 10, <cmp>CmpRedundancy</cmp>, <id>0x00000129</id> <ver>3.5.16.40</ver> 2023-09-12T21:11:41Z, 0x00000001, 1, 0, 10, <cmp>CmpRedundancyConnectionIP</cmp>, <id>0x0000ff03</id> <ver>3.5.16.0</ver> 2023-09-12T21:11:41Z, 0x00000001, 1, 0, 10, <cmp>CmpRetain</cmp>, <id>0x00000017</id> <ver>3.5.16.30</ver> 2023-09-12T21:11:41Z, 0x00000001, 1, 0, 10, <cmp>CmpRouter</cmp>, <id>0x00000018</id> <ver>3.5.16.10</ver> 2023-09-12T21:11:41Z, 0x00000001, 1, 0, 10, <cmp>CmpSchedule</cmp>, <id>0x00000019</id> <ver>3.5.16.30</ver> 2023-09-12T21:11:41Z, 0x00000001, 1, 0, 10, <cmp>CmpSecureChannel</cmp>, <id>0x00000090</id> <ver>3.5.16.0</ver> 2023-09-12T21:11:41Z, 0x00000001, 1, 0, 10, <cmp>CmpSecurityManager</cmp>, <id>0x0000008e</id> <ver>3.5.16.0</ver> 2023-09-12T21:11:41Z, 0x00000001, 1, 0, 10, <cmp>CmpSessionInformation</cmp>, <id>0x00000097</id> <ver>3.5.16.10</ver> 2023-09-12T21:11:41Z, 0x00000001, 1, 0, 10, <cmp>CmpSocketCanDrv</cmp>, <id>0x00005f0d</id> <ver>3.5.16.0</ver> 2023-09-12T21:11:41Z, 0x00000001, 1, 0, 10, <cmp>CmpSrv</cmp>, <id>0x0000001c</id> <ver>3.5.16.0</ver> 2023-09-12T21:11:41Z, 0x00000001, 1, 0, 10, <cmp>CmpTraceMgr</cmp>, <id>0x00000070</id> <ver>3.5.16.10</ver> 2023-09-12T21:11:41Z, 0x00000001, 1, 0, 10, <cmp>CmpUserDBFile</cmp>, <id>0x00000098</id> <ver>3.5.16.20</ver> 2023-09-12T21:11:41Z, 0x00000001, 1, 0, 10, <cmp>CmpUserGroupsDBFile</cmp>, <id>0x00000099</id> <ver>3.5.16.20</ver> 2023-09-12T21:11:41Z, 0x00000001, 1, 0, 10, <cmp>CmpUserMgr</cmp>, <id>0x00000061</id> <ver>3.5.16.40</ver> 2023-09-12T21:11:41Z, 0x00000001, 1, 0, 10, <cmp>CmpUserObjectsDBFile</cmp>, <id>0x0000009c</id> <ver>3.5.16.20</ver> 2023-09-12T21:11:41Z, 0x00000001, 1, 0, 10, <cmp>CmpVisuHandler</cmp>, <id>0x00000054</id> <ver>3.5.16.10</ver> 2023-09-12T21:11:41Z, 0x00000001, 1, 0, 10, <cmp>CmpVisuServer</cmp>, <id>0x00000057</id> <ver>3.5.16.10</ver> 2023-09-12T21:11:41Z, 0x00000001, 1, 0, 10, <cmp>CmpWebServer</cmp>, <id>0x00000071</id> <ver>3.5.16.0</ver> 2023-09-12T21:11:41Z, 0x00000001, 1, 0, 10, <cmp>CmpWebServerHandlerV3</cmp>, <id>0x00000072</id> <ver>3.5.16.0</ver> 2023-09-12T21:12:16Z, 0x00000007, 1, 0, 6, Network interface: <ipaddress>192.168.1.17</ipaddress>, subnetmask <subnetmask>255.255.255.0</subnetmask> 2023-09-12T21:12:16Z, 0x00000018, 1, 0, 4, Network interface <interface>ether 4</interface> at router <instance>0</instance> registered 2023-09-12T21:12:16Z, 0x00000009, 1, 0, 2, Running as network server 2023-09-12T21:12:16Z, 0x00000009, 1, 0, 1, Running as network client 2023-09-12T21:12:16Z, 0x0000000a, 1, 0, 0, <NumOfChannels>4</NumOfChannels> channels available, each of the size <BufferSize>100000</BufferSize> Bytes 2023-09-12T21:12:16Z, 0x00000129, 1, 0, 0, Debug Messages not activated 2023-09-12T21:12:16Z, 0x0000ff03, 1, 0, 0, Read connection settings... 2023-09-12T21:12:16Z, 0x00000030, 1, 0, 6, Local network address: <ipaddress>192.168.1.17</ipaddress> 2023-09-12T21:12:16Z, 0x00000018, 1, 0, 4, Network interface <interface>BlkDrvTcp</interface> at router <instance>2</instance> registered 2023-09-12T21:12:16Z, 0x00000124, 1, 0, 0, No certificate for the OPC UA server available. 2023-09-12T21:12:16Z, 0x00000124, 1, 0, 0, Security policy allows plain text communication. Secure communication is deactivated. 2023-09-12T21:12:16Z, 0x00000124, 1, 0, 0, ************************************************************** 2023-09-12T21:12:16Z, 0x00000124, 1, 0, 0, OPC UA Server Started: 2023-09-12T21:12:16Z, 0x00000124, 1, 0, 0, Hostname: PFC200, Port: 4840 2023-09-12T21:12:16Z, 0x00000124, 1, 0, 0, URL: opc.tcp://PFC200:4840 2023-09-12T21:12:16Z, 0x00000124, 1, 0, 0, Loopbackadapter activated. 2023-09-12T21:12:16Z, 0x00000124, 1, 0, 0, All available networkadapters are used. 2023-09-12T21:12:16Z, 0x00000124, 1, 0, 0, ************************************************************** 2023-09-12T21:12:16Z, 0x00000124, 1, 0, 0, Provider CODESYS_DefaultProvider with Version 0x3051028 registerd at the OPC UA server. 2023-09-12T21:12:16Z, 0x00000124, 1, 0, 0, Provider CmpOPCUAProviderIecVarAccess with Version 0x3051028 registerd at the OPC UA server. 2023-09-12T21:12:17Z, 0x00000126, 1, 0, 0, Valid license found for OPC UA IecVarAccess provider. 2023-09-12T21:12:17Z, 0x00000002, 1, 0, 7, Retains matched to bootproject of application [<app>Application</app>] 2023-09-12T21:12:17Z, 0x00000002, 1, 0, 6, Bootproject of application [<app>Application</app>] loaded 2023-09-12T21:12:17Z, 0x00000018, 1, 0, 1, Setting router <instance>0</instance> address to <address>(0011)</address> 2023-09-12T21:12:17Z, 0x00000018, 1, 16, 8, Network interface for mainnet=<mainnet>ether 5</mainnet> not found 2023-09-12T21:12:17Z, 0x00000018, 1, 0, 1, Setting router <instance>1</instance> address to <address>(0000)</address> 2023-09-12T21:12:17Z, 0x00000018, 1, 0, 1, Setting router <instance>2</instance> address to <address>(2ddc:c0a8:0111)</address> 2023-09-12T21:12:17Z, 0x00000002, 1, 0, 10, Application [<app>Application</app>] started 2023-09-12T21:12:17Z, 0x00000001, 1, 0, 34, CODESYS Control ready 2023-09-12T21:13:37Z, 0x00000001, 1, 0, 0, runtime licensed 2023-09-12T21:17:17Z, 0x00000002, 1, 0, 2, Application [<app>Application</app>] loaded via [OnlineChange] 2023-09-13T01:38:17Z, 0x00000009, 1, 418, 0, Channel timeout (<curtime>16012264</curtime>, <lasttime>15982259</lasttime>) 2023-09-13T01:38:17Z, 0x00000009, 1, 418, 0, Closing connection to <address>0329:032e</address> 2023-09-23T14:46:00Z, 0x00000002, 1, 0, 2, Application [<app>Application</app>] loaded via [OnlineChange] 2023-09-23T14:48:57Z, 0x00000002, 1, 0, 2, Application [<app>Application</app>] loaded via [OnlineChange]
Last updated: 2023-09-27

Post by herbasso88 on WebVisu flickering ^{CODESYS Forge talk (Post)}
Good morning, I'm new on Codesys Forge, so I'm not sure if this is the right place to talk about my problem. When I open my WebVisu pages with Microsoft Edge, or Chrome, the background and also some rectangles blinking without reason!!! The application is developed with Codesys 3.5.17.10 and run on Codesys HMI, same version (3.5.17.10). After several experiments I discover that the problem happens when I made dynamic the "End of area" property of a meter object, but I can't understand why this blinking problem happens. Also, the problem is only at the WebVisu page, the "normal" VISU pages (the ones opened when Codesys HMI start) work always perfectly. Another strange thing is that the problem happens only if on the same page, where there is the meter object, there is also a trend object!?!? Codesys HMI is running on a Virtual Machine (VMware Workstation 15 player, v.15.5.6) running Windows 10 Pro N 64-bit. The blinking problem happen also if I convert the project to Codesys 3.5.20.0. This version of Codesys and Codesys HMI are installed on a Virtual Machine running Windows Server 2019 Standard 64-bit. In attachment the archive of my project. The attached project has only one page, if "Enable Counter" is not pressed the "End of area" variable of the meter is not updated in the software, and everything work well, normal VISU and WebVisu; if "Enable Counter" is pressed, the "End of area" variable of the meter is updated in the software, and the WebVisu page start blinking. I tried also to enable the "Support client animations and overlay..." property at VisualizationManager, this seems stop the blinking problem, but that property also destroy my WebPage, moving almost all the graphical object, that also seem not working anymore. I really need help to understand what I'm doing wrong, I have to develop a bigger project and I have to understand if trend objects and animated meters cannot stay in the same page. In the final project the WebVisu will be very important because the customer will use this way to access the application to monitor the process. Regards
Last updated: 2024-05-06

Post by sturmghost on Visualization using methods and cyclic ST-calls ^{CODESYS Forge talk (Post)}
Im looking for a way to implement ST-code into the visualization element without creating a helper POU or method in my device/application tree. Like visualization properties are evaluated at each VISU_TASK cycle I want to be able to create own ST code which interacts with the visualization interface variables. To be more specific I want to have a property which executes user defined ST-code at each VISU_TASK cycle exactly like its already possible for Input Configuration on various mouse and dialog events. Also a property for initialization (so only executed once) and a timed property would be nice. With the situation right now I'll have to create a POU function which handles the ST-code and misuse a property, like the text variable, to execute this POU function at each VISU_TASK cycle. Or does it exist and I don't know it?
Last updated: 2023-10-02

Post by captaincookie on increase default string length in queue ^{CODESYS Forge talk (Post)}
Hello, I'm using Codesys V3.5 SP18 Patch 4. In the ElementCollectionExample Project from Codesys, I test the SimpleQueueExample in a Control Win V3 x64 environment. I try to add a string of 95 characters length to a queue. The default length of strings is defined as 80 characters. In the initialization of a string variable, it is possible to increase the length by the definition of e.g. STRING(1000). But when I write the string defined like this to the queue, only 80 characters are written to it and the rest is missing. I think the default length is still set in the queue definition, so it is necessary to change this, isn't it? Is there any option to increase the default length of strings in the queue? Attached you can find the used project. Thanks in advance. If any information are missing or my description unclear please let me know.
Last updated: 2023-10-05

Post by manuknecht on Persistence Manager does not save alphabetically first value ^{CODESYS Forge talk (Post)}
I have several libraries which contain values that should be saved on a PLC. As apparently no Persistent Variable List is available within Libraries, I use the Persistence Manager to create a Persistence Channel in the Project which imports the library. I then specify the persistence channel in the library using the {attribute 'ac_persist':='PersistenceChannel_CT'} specifier. This generally works very well and gives me exactly the properties I require. However, it came to my attention that the (alphabetially) first value from the library is not saved in the created ASCII file. When checking the content of the Persistence Channel, it shows all the variables as defined in the library. But the created file does not contain the first value and it is not restored after restart or reset. (see attached picture) I disabled Periodic Saving and set xSaveOnChange to TRUE and so the file usually updates immediately after changing one of the values. When changing the first value, it does not update which is consistent with this value not being saved. I also created a sample project and library from scratch which shows the same issue both using a Raspberry Pi and using a Linux machine. Does someone know what the reason for this could be or did someone make similar experiences? Looking forward to hearing your suggestions. Thanks in advance and best wishes Manuel
Last updated: 2023-10-17

Post by manuknecht on Persistence Manager does not save alphabetically first value ^{CODESYS Forge talk (Post)}
After some more digging I realized that I get an error on the PLC Logger saying PersistenceChannel: 150 (invalid type in data: SimpleLibrary). I suppose the issue could be found in the ConfigData, which is automatically generated and which looks like this: 1 9##83 SimpleLibrary#GVL.aMoreZeros.[1]#0#64512#15#0 <[2]#0#64520#15#0 <[3]#0#64528#15#0 <[4]#0#64536#15#0 <#0#64544#15#0 <[6]#0#64552#15#0 <<lrVar#0#64560#15#0 <strVar#0#64428#16#80 <uiDummy#0#64370#11#0 Perhaps the fact that the variable is stored within a library confused the compiler? I tried changing the PersistenceChannel parameters to xCompressTags := FALSE which changed the entry in the data file from _xCompressTags BOOL:TRUE _xCompressTags BOOL:FALSE but the actual content of the data file and also the config data did not change.
Last updated: 2023-10-17

Post by toby on Ethernet/IP communication with Omron NX1P2 ^{CODESYS Forge talk (Post)}
Hey guys, I'm very much a noob with networking, it's my achillies heel, and this is my first networking project using Ethernet/IP. Any help offered is GREATLY appreciated. I'm trying to network a Codesys Project with an Omron NX1P2 PLC. I'm using EIP due to hardware restrains. I've added the fieldbus, EIP scanner (as the master), and made a Network Variable List. On the Sysmac Studio end, I've made the variables and set them to network inputs/outputs, registered them in EIP settings, but when I try to set the target device (the Codesys project), I suspect I need to import an EDS file for the EIP mapping. Back in the Codesys project, I'm not sure how to: - Make an EDS file to share with Sysmac Studio - How to link the target device (Omron PLC) to the EIP fieldbus - How to map the inputs from the Omron PLC. Im sorry for my very open request for help, i'm kind of lost looking through the various forums/video/tutorials as many of them dont match what im trying to do. Any help, or sample programs would be so so greatly appreciated. If you need any further clarifications, please feel free to ask. Thanks in advance, Toby
Last updated: 2024-01-24

Post by danieldiaz on Problem with FB execution ^{CODESYS Forge talk (Post)}
Hello everyone, I've been working on a system which needs an error function, with this purpose I've created a FB programmed in LD, after debugging I run the simulation. It seems that the variable linked to a coil doesn't change the value when the contacts are associated to input variables. When I use internal variables the logic works properly. I don't know if the problem is related to the variables definition or with the logic program. As you can see in the image, I1 and I2 are variables declared on the FB, the rest are input variables. If I force the eStop and Reset signals to TRUE the coil value should change, but it doesn't. However in the second network if I1 is TRUE the coil change to TRUE as it has to be. To sum up, my doubt is why that coil doesn't change its value? I would like someone to shed a light on this. Thanks!
Last updated: 2024-04-02

Post by tama00 on GPIOs not running with Raspberry Pi 4 (and SPI connection) ^{CODESYS Forge talk (Post)}
Hello everyone, I have a working SPI connection (with transferExt) between a Raspberry master with Codesys and an ESP32 slave. I would also like to use a few GPIO pins. Is there a problem with using SPI AND GPIOs? Environment: Raspberry Pi 4+ with Raspian from Oct 23 Codesys V3.4 SP19 Patch 5 with Runtime Version 4.10.0.0 Device: GPIOs B+/Pi2 My problem: The status is displayed as “GPIOs : not running”. And also during mapping the message “The bus is not running. The values shown are perhaps not actual”. However, the variable changes that I make in my program are displayed under “Current Value”. In the Logic Analyzer, the pin toggles during transmission with small intervals of +-4us (seems to be a cyclical disorder, but I don't know where exactly it could be coming from). This applies to pins that I actually use (output) but also to the other GPIOs (not used). With GPIO 4, the line remains permanently high. Attached is a screenshot from the Logic Analyzer. Channel 1,3,5 were GPIO pin 26, 22, 17 Would be very grateful for help. Best regards
Last updated: 2024-05-06

Post by caprez95 on Deleting the trend recording history ^{CODESYS Forge talk (Post)}
Hallo Ich möchte eine laufende Trendaufzeichnung stoppen, den Inhalt löschen und Trend-Diagramm auf 0 zurücksetzen. Laut Codesys soll das mit dem folgenden Code möglich sein: You can insert an input element in the visualization which the operator can use to delete the previous value recording in the trend visualization at runtime. The curve displayed until then is removed and the display starts over. In the application (example: in the program PLC_PRG), implement the following code: itfTrendRecording : ITrendRecording; itfTrendStorageWriter : ITrendStorageWriter; itfTrendStorageWriter3 : ITrendStorageWriter3; sTrendRecordingName : STRING := 'TrendRecording'; itfTrendRecording := GlobalInstances.g_TrendRecordingManager.FindTrendRecording(ADR(sTrendRecordingName)); xClearHistoryTrend: BOOL; IF xClearHistoryTrend THEN itfTrendRecording := GlobalInstances.g_TrendRecordingManager.FindTrendRecording(ADR(sTrendRecordingName)); IF itfTrendRecording <> 0 THEN itfTrendStorageWriter := itfTrendRecording.GetTrendStorageWriter(); IF __QUERYINTERFACE(itfTrendStorageWriter, itfTrendStorageWriter3) THEN itfTrendStorageWriter3.ClearHistory(); END_IF END_IF In the visualization of the trend recording, add a button for deleting the previous curve. Configure its Toggle property with the variable PLC_PRG.xClearHistoryTrend. ⇒ When xClearHistoryTrend is set to TRUE, the previously recorded curve is deleted. The recording immediately starts again. Dies löscht auch die Daten vom Trend, aber das Diagramm wird nicht auf 0 zurückgesetzt, sondern läuft einfach da weiter wo man gestoppt hat. Braucht es für den Diagramm-Reset noch einen zusätzlichen Befehl? Gruss
Last updated: 2024-06-11

Post by sturmghost on Mimic behavior of the visualization button element with a custom button ^{CODESYS Forge talk (Post)}
Im wondering how Codesys is doing the mouse event capturing with their visualization button element? If you add such a button without configuring any input configuration event (like OnMouseDown) or button state variable and then click on the button, the button changes to the visual pressed state and back if you release the button (so they must react to an OnMouseDown event). But how? If I try to mimic this behavior with my custom button visualization element (like a basic rectangle) I need to use an input configuration event to change the color of the button (to make it look like the button was pressed on OnMouseDown event). When I try to add this button via a Frame-Element to my main visualization page I'm unable to use an input configuration event on the Frame-Element because the input configuration event on the button element won't be evaluated anymore (it seems like you can't stack input fields, e.g. invisible input elements, onto each other). Hence the button is not shown pressed anymore. How they do it?
Last updated: 2024-08-04

Post by bjarne-pagaard on Communication between applications on same device/controller/runtime (Win RTE 3.5.20.20) ^{CODESYS Forge talk (Post)}
Thanks for this - I have now been looking in to just having an extra (non-RTE) runtime on the same machine, as you suggest. I will probably proceed this way. Even though it still seems very odd to me, that variable exchange to a different runtime is easier than between applications on the same controller. There will be some fun with the licensing, it seems. Does anyone know if it is possible to specify which license container/specific license the runtime is going to use at runtime. Let's say I have two available licenses with different resources available, for example one license allows multicore and multiple EtherCAT channels, but not many visu tags (for the RTE). Another with less resources but a lot of visu tags (for the Visu controller). Let's say the program in one of the controllers could be fully licensed by either of the two available licenses, but picks the 'largest' first. A bit later, the larger application starts, but is left with the smaller license.. How can I make sure that the 2 runtimes select the right license at startup?
Last updated: 2024-10-01

Post by mubeta on Strange problem with the ‘MC_SetPosition’ function ^{CODESYS Forge talk (Post)}
CoDeSys 3.5.19.7 Target Berghof MX6 In a simple SoftMotion programme with two stepperless modular axes from CMZ, one is simply controlled in speed, but a spot must perform a positioning. I use the function MC_SetPosition() both to reference the axis at power-up and also to correct the actual position to a fixed machine reference detected with proximity. The function has only one instance and I actually use a booelan variable to control the ‘Execute’ input. Well, I cannot correctly change the axis position on the fly if it is running at high speed. The servomotor works in a speed range between 0°/s and 720°/s, (gearbox output with a 1:6 ratio). As long as the servomotor is operating at speeds below about 400 °/s, the function is able to correct the position correctly even when forcing values far apart, but at high speeds, from 400 °/s upwards, the correction no longer takes place. For example, trying to correct the position of 280° into 300° with absolute mode, the axis that is moving at speed actually shifts the position by a few degrees, not the expected 20. I don't understand why with the servo drive running slowly the position shift occurs correctly, while increasing in speed it no longer works.
Last updated: 2025-01-09

Sort by relevance or date