Search talk: base control library

 
<< < 1 .. 61 62 63 64 > >> (Page 63 of 64)

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 julianramirez on ModbusFB write update CODESYS Forge talk (Post)
Hello everyone, I am testing the ModbusFB library tcp server and so far I am able to create holding registers successfully, however, I am trying to identify after each write which registers got updated (i.e. function code, write value). I can even see the var udiNumWriteRequests, which increases with every write. I noticed that there is logging with the LogStatusInfo method. After I call it I am able to read in the console stuff that I want. Nevertheless, this is only available at the logs and is not easy to decode because it consists on several messages, I would like to know if there is a way for me to retrieve this information from the function itself with pointers or if there is any way to copy the logs messages (assuming that I can filter them with the LoggingOptions to only show what I need) inside the runtime code and not in the console. Thanks for your help :)
Last updated: 2024-09-16

Post by salvadegianluca on List files in a directory with SysDiropen And SysDirRead CODESYS Forge talk (Post)
Good morning; I'm facing an issue that seems being caused by the library itself. I'm trying to create the list of all the files that are stored inside a psecific directory. Unluckily the first file is allways hidden. VAR CONSTANT arysEmptyArray:ARRAY[iArrayMinDimension..iArrayMAXDimension] OF STRING := [(iArrayMAXDimension - iArrayMinDimension)('')]; iArrayMinDimension:INT := 1; iArrayMAXDimension:INT := 99; END_VAR VAR_INPUT sDirectoryToInspect:STRING; sSearchFilter:STRING; END_VAR VAR_IN_OUT xCheckFileInsideDirectory:BOOL; END_VAR VAR arysListOfFoundFiles:ARRAY[iArrayMinDimension..iArrayMAXDimension] OF STRING; sNullString:STRING; iNullIndex:INT := 0; libInfoAboutThePath:DirInfo; libResultOfThePathMonitoring:CmpErrors.RTS_IEC_RESULT; libInstanceToMonitorThePath:CmpErrors.RTS_IEC_HANDLE; sEntityToSearch:STRING; dMaxEntityDimension:DINT := SIZEOF(sEntityToSearch); libFileInfo:DirInfo; sFilteredFileName:STRING; iIndexToScrollArrays:INT; END_VAR IF xCheckFileInsideDirectory THEN arysListOfFoundFiles:=arysEmptyArray; iIndexToScrollArrays:=iArrayMinDimension; libInstanceToMonitorThePath:= SysDirOpen(szDir:= sDirectoryToInspect,szDirEntry:=sNullString,diMaxDirEntry:= iNullIndex,pDirInfo:= ADR(libInfoAboutThePath),pResult:= ADR(libResultOfThePathMonitoring)); WHILE libResultOfThePathMonitoring = Errors.ERR_OK AND iIndexToScrollArrays <= iArrayMAXDimension DO sEntityToSearch:= ''; libResultOfThePathMonitoring:=SysDirRead(hDir:=libInstanceToMonitorThePath,szDirEntry:=sEntityToSearch,diMaxDirEntry:=dMaxEntityDimension,pDirInfo:=ADR(libFileInfo)); sFilteredFileName:= FUN_06_00_FindItemInString_0(sFilter:=sSearchFilter,sSource:=sEntityToSearch); IF sFilteredFileName <> '' THEN arysListOfFoundFiles[iIndexToScrollArrays]:=sFilteredFileName; iIndexToScrollArrays:=iIndexToScrollArrays + 1; END_IF IF libResultOfThePathMonitoring <> Errors.ERR_OK THEN libResultOfThePathMonitoring:= Errors.ERR_OK; END_IF END_WHILE libResultOfThePathMonitoring:=SysDirClose(hDir:= libInstanceToMonitorThePath); xCheckFileInsideDirectory:=FALSE; END_IF How is possible to solve this issue? Any known work around?
Last updated: 2024-09-17

Post by salvadegianluca on List files in a directory with SysDiropen And SysDirRead CODESYS Forge talk (Post)
Good morning; I'm facing an issue that seems being caused by the library itself. I'm trying to create the list of all the files that are stored inside a psecific directory. Unluckily the first file is allways hidden. VAR CONSTANT arysEmptyArray:ARRAY[iArrayMinDimension..iArrayMAXDimension] OF STRING := [(iArrayMAXDimension - iArrayMinDimension)('')]; iArrayMinDimension:INT := 1; iArrayMAXDimension:INT := 99; END_VAR VAR_INPUT sDirectoryToInspect:STRING; sSearchFilter:STRING; END_VAR VAR_IN_OUT xCheckFileInsideDirectory:BOOL; END_VAR VAR arysListOfFoundFiles:ARRAY[iArrayMinDimension..iArrayMAXDimension] OF STRING; sNullString:STRING; iNullIndex:INT := 0; libInfoAboutThePath:DirInfo; libResultOfThePathMonitoring:CmpErrors.RTS_IEC_RESULT; libInstanceToMonitorThePath:CmpErrors.RTS_IEC_HANDLE; sEntityToSearch:STRING; dMaxEntityDimension:DINT := SIZEOF(sEntityToSearch); libFileInfo:DirInfo; sFilteredFileName:STRING; iIndexToScrollArrays:INT; END_VAR IF xCheckFileInsideDirectory THEN arysListOfFoundFiles:=arysEmptyArray; iIndexToScrollArrays:=iArrayMinDimension; libInstanceToMonitorThePath:= SysDirOpen(szDir:= sDirectoryToInspect,szDirEntry:=sNullString,diMaxDirEntry:= iNullIndex,pDirInfo:= ADR(libInfoAboutThePath),pResult:= ADR(libResultOfThePathMonitoring)); WHILE libResultOfThePathMonitoring = Errors.ERR_OK AND iIndexToScrollArrays <= iArrayMAXDimension DO sEntityToSearch:= ''; libResultOfThePathMonitoring:=SysDirRead(hDir:=libInstanceToMonitorThePath,szDirEntry:=sEntityToSearch,diMaxDirEntry:=dMaxEntityDimension,pDirInfo:=ADR(libFileInfo)); sFilteredFileName:= FUN_06_00_FindItemInString_0(sFilter:=sSearchFilter,sSource:=sEntityToSearch); IF sFilteredFileName <> '' THEN arysListOfFoundFiles[iIndexToScrollArrays]:=sFilteredFileName; iIndexToScrollArrays:=iIndexToScrollArrays + 1; END_IF IF libResultOfThePathMonitoring <> Errors.ERR_OK THEN libResultOfThePathMonitoring:= Errors.ERR_OK; END_IF END_WHILE libResultOfThePathMonitoring:=SysDirClose(hDir:= libInstanceToMonitorThePath); xCheckFileInsideDirectory:=FALSE; END_IF How is possible to solve this issue? Any known work around?
Last updated: 2024-09-17

Post by salvadegianluca on List files in a directory with SysDiropen And SysDirRead CODESYS Forge talk (Post)
Good morning; I'm facing an issue that seems being caused by the library itself. I'm trying to create the list of all the files that are stored inside a psecific directory. Unluckily the first file is allways hidden. VAR CONSTANT arysEmptyArray:ARRAY[iArrayMinDimension..iArrayMAXDimension] OF STRING := [(iArrayMAXDimension - iArrayMinDimension)('')]; iArrayMinDimension:INT := 1; iArrayMAXDimension:INT := 99; END_VAR VAR_INPUT sDirectoryToInspect:STRING; sSearchFilter:STRING; END_VAR VAR_IN_OUT xCheckFileInsideDirectory:BOOL; END_VAR VAR arysListOfFoundFiles:ARRAY[iArrayMinDimension..iArrayMAXDimension] OF STRING; sNullString:STRING; iNullIndex:INT := 0; libInfoAboutThePath:DirInfo; libResultOfThePathMonitoring:CmpErrors.RTS_IEC_RESULT; libInstanceToMonitorThePath:CmpErrors.RTS_IEC_HANDLE; sEntityToSearch:STRING; dMaxEntityDimension:DINT := SIZEOF(sEntityToSearch); libFileInfo:DirInfo; sFilteredFileName:STRING; iIndexToScrollArrays:INT; END_VAR IF xCheckFileInsideDirectory THEN arysListOfFoundFiles:=arysEmptyArray; iIndexToScrollArrays:=iArrayMinDimension; libInstanceToMonitorThePath:= SysDirOpen(szDir:= sDirectoryToInspect,szDirEntry:=sNullString,diMaxDirEntry:= iNullIndex,pDirInfo:= ADR(libInfoAboutThePath),pResult:= ADR(libResultOfThePathMonitoring)); WHILE libResultOfThePathMonitoring = Errors.ERR_OK AND iIndexToScrollArrays <= iArrayMAXDimension DO sEntityToSearch:= ''; libResultOfThePathMonitoring:=SysDirRead(hDir:=libInstanceToMonitorThePath,szDirEntry:=sEntityToSearch,diMaxDirEntry:=dMaxEntityDimension,pDirInfo:=ADR(libFileInfo)); sFilteredFileName:= FUN_06_00_FindItemInString_0(sFilter:=sSearchFilter,sSource:=sEntityToSearch); IF sFilteredFileName <> '' THEN arysListOfFoundFiles[iIndexToScrollArrays]:=sFilteredFileName; iIndexToScrollArrays:=iIndexToScrollArrays + 1; END_IF IF libResultOfThePathMonitoring <> Errors.ERR_OK THEN libResultOfThePathMonitoring:= Errors.ERR_OK; END_IF END_WHILE libResultOfThePathMonitoring:=SysDirClose(hDir:= libInstanceToMonitorThePath); xCheckFileInsideDirectory:=FALSE; END_IF How is possible to solve this issue? Any known work around?
Last updated: 2024-09-17

Post by salvadegianluca on List files in a directory with SysDiropen And SysDirRead CODESYS Forge talk (Post)
Good morning; I'm facing an issue that seems being caused by the library itself. I'm trying to create the list of all the files that are stored inside a psecific directory. Unluckily the first file is allways hidden. VAR CONSTANT arysEmptyArray:ARRAY[iArrayMinDimension..iArrayMAXDimension] OF STRING := [(iArrayMAXDimension - iArrayMinDimension)('')]; iArrayMinDimension:INT := 1; iArrayMAXDimension:INT := 99; END_VAR VAR_INPUT sDirectoryToInspect:STRING; sSearchFilter:STRING; END_VAR VAR_IN_OUT xCheckFileInsideDirectory:BOOL; END_VAR VAR arysListOfFoundFiles:ARRAY[iArrayMinDimension..iArrayMAXDimension] OF STRING; sNullString:STRING; iNullIndex:INT := 0; libInfoAboutThePath:DirInfo; libResultOfThePathMonitoring:CmpErrors.RTS_IEC_RESULT; libInstanceToMonitorThePath:CmpErrors.RTS_IEC_HANDLE; sEntityToSearch:STRING; dMaxEntityDimension:DINT := SIZEOF(sEntityToSearch); libFileInfo:DirInfo; sFilteredFileName:STRING; iIndexToScrollArrays:INT; END_VAR IF xCheckFileInsideDirectory THEN arysListOfFoundFiles:=arysEmptyArray; iIndexToScrollArrays:=iArrayMinDimension; libInstanceToMonitorThePath:= SysDirOpen(szDir:= sDirectoryToInspect,szDirEntry:=sNullString,diMaxDirEntry:= iNullIndex,pDirInfo:= ADR(libInfoAboutThePath),pResult:= ADR(libResultOfThePathMonitoring)); WHILE libResultOfThePathMonitoring = Errors.ERR_OK AND iIndexToScrollArrays <= iArrayMAXDimension DO sEntityToSearch:= ''; libResultOfThePathMonitoring:=SysDirRead(hDir:=libInstanceToMonitorThePath,szDirEntry:=sEntityToSearch,diMaxDirEntry:=dMaxEntityDimension,pDirInfo:=ADR(libFileInfo)); sFilteredFileName:= FUN_06_00_FindItemInString_0(sFilter:=sSearchFilter,sSource:=sEntityToSearch); IF sFilteredFileName <> '' THEN arysListOfFoundFiles[iIndexToScrollArrays]:=sFilteredFileName; iIndexToScrollArrays:=iIndexToScrollArrays + 1; END_IF IF libResultOfThePathMonitoring <> Errors.ERR_OK THEN libResultOfThePathMonitoring:= Errors.ERR_OK; END_IF END_WHILE libResultOfThePathMonitoring:=SysDirClose(hDir:= libInstanceToMonitorThePath); xCheckFileInsideDirectory:=FALSE; END_IF How is possible to solve this issue? Any known work around?
Last updated: 2024-09-17

Post by lbartik on J1939 TX/RX PDU1 CODESYS Forge talk (Post)
Is it possible to transmit a PDU1 PGN using the J1939 manager and local device? What if I need to transmit a PGN RQST via 0xEA00 (PGN 59904)? How would I do this P2P (Destination < 0xFF) or broadcast (Destination 0xFF)? I don't think this is possible for any destination type. I don't think it's possible to receive broadcast PDU1 messages either. For example, an address claim PGN 60928 (0x18EEFF80) is addressed to all nodes (0xFF) and not any specific local device so it will be filtered out. These are major oversights in the IoDrvJ1939 library to not support every PDU1 RX/TX scenario. IoDrvJ1939 supported scenario: 1. Receive (RX) PDU1 (P2P) destination-specific (PDU-specific < 255) to local device with matching address IoDrvJ1939 unsupported scenarios: 1. Receive (RX) PDU1 (P2P) global (PDU-specific = 255) 2. Transmit (TX) PDU1 (P2P) global (PDU-specific = 255) 3. Transmit (TX) PDU1 (P2P) destination-specific (PDU-specific < 255)
Last updated: 2024-09-23

Post by breiter on Frustration-Fueled Feedback on Project File Management and Git Integration CODESYS Forge talk (Post)
Hi, supporting a text based storage format is on our roadmap, see https://www.codesys.com/the-system/releases-updates-lifecycle/release-plan-roadmap.html It will be an Add-On feature called "File Based Storage" for the professional developer edition. Structured text POUs will be stored as plain text. Other graphical languages will remain in an xml format. You will be able to switch the storage type for projects. Certain workflows will become easier this way. Nevertheless restrictions will remain because of CODESYS specific storage logic (for example how methods below function blocks are stored as file). So merging using our Git Integration Add-On remains the recommended workflow. A workflow involving Visual Studio Code as the main IDE is not supported. Simply because many topics like library management, task configuration or fieldbus configurators are not available for VS Code. A PLC project is a lot more than just some ST POUs. Best Regards
Last updated: 2024-10-16

Post by struccc on Bibliothek: floatingpointutils CODESYS Forge talk (Post)
The issue s the byte order typically in this case. Can be especially problematic with floating point numbers - even more tricky if transferred with a word based protocol. It is a peasant way to try out the alternatives, dword order can be a-b-c-d, b-a-d-c, c-d-a-b, d-c-b-a where a is the most significant, d is the least significant byte. So all you need is to swap the bytes in your dword, until you get the expected result. If you don't want to mess writing code for this, I'd recommend CAA_Memory library for that: MEM.ReverseBYTEsInDWORD and MEM.ReverseWORDsInDWORD functions would definitively do the trick. Otherwise, can do like this: VAR dwIn : DWORD := 16#11223344; dwOut : DWORD; rOut : REAL; pIN : POINTER TO BYTE; pOUT : POINTER TO BYTE; END_VAR pIN := ADR(dwIn); //pOUt := ADR(dwOut); pOUt := ADR(rOut); pOut[0] := pIN[3]; pOut[1] := pIN[2]; pOut[2] := pIN[1]; pOut[3] := pIN[0]; Ugly, but does the job...
Last updated: 2024-11-19

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 leandroct on Error reading files after runtime update from 4.0.0.0 to 4.8.0.0 CODESYS Forge talk (Post)
Since version 19 they changed how file access is handle. There are two solutions: 1. You change where the file is stored (need to go to: /PlcLogic/) 2. You can, if you don´t want to store at PlcLogic, add the following line in the CODESYSControl.cfg under [SysFile]: ForceIecFilePath=0 The CodesysControl.cfg is at C:\ProgramData\CODESYS\CODESYSControlWinV3x64\xxPROJECT_NUMBERxx\ Here the email they sent me: "with the 3.5.19 Version we changed how files are handled. See following issue: CDS-81506 - CODESYS Control SysFile system file access vulnerability. There are two solutions: 1. You change where the file is stored (need to go to: /PlcLogic/) 2. You can, if you don´t want to store at PlcLogic, add the following line in the CODESYSControl.cfg under [SysFile]: ForceIecFilePath=0 Here is the official release-note: [[COMPATIBILITY_INFORMATION]] With the activation of ForceIecFilePath the file access from IEC is now restricted to the configured paths only (file sandbox)! [SysFile] ForceIecFilePath=1 (new default) The standard path is the current directory, the PlcLogic subfolder or a configured path. Every file access outside of this path is configured via PlaceholderFilePath, for example access to temporary files or removable media: [SysFile] PlaceholderFilePath.1=/tmp, $TMP$ PlaceholderFilePath.2=/media/usb, $USB$ PlaceholderFilePath.2.Volatile=1 For more information see our tutorial FilePath & Placeholders. To restore the old behavior ForceIecFilePath may be configured as follows: [SysFile] ForceIecFilePath=0 BUT WE HIGHLY RECOMMEND TO LEAVE THIS SETTING AT ITS NEW DEFAULT VALUE! "
Last updated: 2024-05-07

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

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

Post by fefefede on Get the numer of day CODESYS Forge talk (Post)
Hello i tro to create a program to turn on or off the air condition in relationship temperature and numer of day. I can't get the number of day. I try this after installing SysTime library but this not work and have this error on debug ------ Build started: Application: Device.Sim.Device.Application ------- Typify code... Generate code... [ERROR] giorno_accensione_aria: PLC_PRG Device: PLC Logic: Application: C0032: Cannot convert type 'Unknown type: 'SysTimeCore(TRUE)'' to type 'TIME' [ERROR] giorno_accensione_aria: PLC_PRG Device: PLC Logic: Application: C0035: Program name, function or function block instance expected instead of 'SysTimeCore' [ERROR] giorno_accensione_aria: PLC_PRG Device: PLC Logic: Application: C0032: Cannot convert type 'Unknown type: 'DayOfWeek(CurrentTime)'' to type 'INT' [ERROR] giorno_accensione_aria: PLC_PRG Device: PLC Logic: Application: C0035: Program name, function or function block instance expected instead of 'DayOfWeek' [INFORMATION] giorno_accensione_aria: PLC_PRG Device: PLC Logic: Application: C0181: Related position Build complete -- 4 errors, 0 warnings : No download possible PROGRAM PLC_PRG VAR Temperatura: UDINT; AriaCondizionata: BOOL := FALSE; CurrentDayOfWeek: INT; //Variabile Giorno CurrentTime: TIME; GiornoDellaSettimana: INT; DayOfWeek: INT; END_VAR CurrentTime := SysTimeCore(TRUE); // Ottieni l'ora corrente CurrentDayOfWeek := DayOfWeek(CurrentTime); CASE GiornoDellaSettimana OF 1: // Azioni per Lunedì 2: // Martedì se più 10° accend altrimenti spegni IF Temperatura >= 10 THEN AriaCondizionata := TRUE; ELSE AriaCondizionata := FALSE; END_IF 3: // Mercoledì se più di 50° accendi altrimenti spegni IF Temperatura >=50 THEN AriaCondizionata := TRUE; ELSE AriaCondizionata := FALSE; END_IF 4: // Giovedì se più di 40° accendi altrimenti spegni IF Temperatura >=40 THEN AriaCondizionata := TRUE; ELSE AriaCondizionata := FALSE; END_IF 5: // Venerdì se più di 50° accendi altrimenti spegni IF Temperatura >=50 THEN AriaCondizionata := TRUE; ELSE AriaCondizionata := FALSE; END_IF 6: // Sabato se più di 25° accendi altrimenti spegni IF Temperatura >=25 THEN AriaCondizionata := TRUE; ELSE AriaCondizionata := FALSE; END_IF 7: // Domenica sempre spenta AriaCondizionata := FALSE; END_CASE
Last updated: 2023-09-14

Post by mondinmr on Why SysPipeWindows is not implemented in RTE? CODESYS Forge talk (Post)
This library would be very useful for IPC communications. Using a UDP socket on localhost is unpredictable, as with slightly loaded machines it does not even guarantee packet delivery locally. Using TCP creates a lot of overhead. Message named pipes would be an excellent solution for Windows RTE. On Linux, since the release of the extension package, there is no issue, as it is sufficient to develop a component. However, although now 90% of our clients understand that Linux runtimes are better in every way compared to Windows RTE, especially from the security aspect (Not in kernel space) and the issues with Windows updates, 10% stubbornly insist (sometimes for trivial commercial reasons) on using Windows. Managing IPC with circular buffers in shared memory is quite ugly, or rather really ugly and unaesthetic. In the manuals, I saw the SysPipeWindows libraries, so I decided to test them, but unfortunately, I noticed that they are not implemented for RTE devices. Technically, I could try to open them as regular files, but SysFileOpen returns 16#27 or 16#39 depending on how I set the name (direction of the slashes). Here is the code to create shared memory and named pipes. Shared memory work great, named pipes no! #ifdef Q_OS_WIN32 SECURITY_ATTRIBUTES sa; SECURITY_DESCRIPTOR sd; InitializeSecurityDescriptor(&sd, SECURITY_DESCRIPTOR_REVISION); SetSecurityDescriptorDacl(&sd, TRUE, NULL, FALSE); sa.nLength = sizeof(SECURITY_ATTRIBUTES); sa.lpSecurityDescriptor = &sd; sa.bInheritHandle = FALSE; const wchar_t* name = L"Global\\ShmTest"; HANDLE hMapFile = CreateFileMapping( INVALID_HANDLE_VALUE, NULL, PAGE_READWRITE, 0, sizeof(SharedData), name); if (hMapFile == NULL) { qCritical("Error creating shared memory"); return 1; } data = static_cast<SharedData*>(MapViewOfFile(hMapFile, FILE_MAP_ALL_ACCESS, 0, 0, sizeof(SharedData))); if (data == NULL) { qCritical("Error mapping shared memory"); return 1; } HANDLE hPipe = CreateNamedPipe( TEXT("\\\\.\\pipe\\MyPipe"), PIPE_ACCESS_DUPLEX, PIPE_TYPE_MESSAGE | PIPE_READMODE_MESSAGE | PIPE_WAIT, PIPE_UNLIMITED_INSTANCES, 1024 * 1024, 1024 * 1024, NMPWAIT_USE_DEFAULT_WAIT, &sa); if (hPipe == INVALID_HANDLE_VALUE) { qCritical("Error creating named pipe"); return -1; } if (!ConnectNamedPipe(hPipe, NULL)) { qCritical("Error connecting to named pipe"); return -1; } checkPipe(hPipe); #endif
Last updated: 2024-02-02

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

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

Post by 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 gorditron on I2C Communication with CODESYS Forge talk (Post)
Hello, I have problems with the I2C communication to an ADS7828 AD converter. I don't get any value back from the chip. I use a Kontron chip (ARM 32SC) with Linux as the operating system. I also use the CmpCharDevice library. ADS7828 parameters Address: A1 = 0 / A0 = 0 = SD = 1 = Single End C2 = 0 / C1= 0 / C0= 0 / Channel 0 PD1 = Internal Reference and PD0 = AD Converter ON Here is my code: VAR b_i2cAdr : BYTE := 16#48; (* Standard I2C-Adresse des ADS7828 *) x_Init: BOOL;(* Flag für die Initialisierung *) b_config_byte: BYTE;(* Konfigurationsbyte für den ADS7828 *) ab_cmd_buffer : ARRAY [0..0] OF BYTE; (* Buffer für den Befehl *) ab_data_buffer : ARRAY [0..1] OF BYTE; (* Buffer für die empfangenen Daten *) ui_adc_value_1 : UINT; (* Ausgelesener ADC-Wert *) I2C_Handle: RTS_IEC_HANDLE; (* Handle für das I2C-Device *) di_result_open: DINT;(* Ergebnis der Funktionsaufrufe *) di_result_adr: DINT;(* Ergebnis der Funktionsaufrufe *) di_result_wr_cmd: DINT;(* Ergebnis der Funktionsaufrufe *) di_result_rd_cmd: DINT;(* Ergebnis der Funktionsaufrufe *) di_result_close: DINT;(* Ergebnis der Funktionsaufrufe *) END_VAR //*** Init from the I2C communication port *** IF NOT x_Init THEN I2C_Handle := CDOpen(szFile:= '/dev/i2c-0', dFlags:= O_RDWR, pResult:= ADR(di_result_open)); //* I2C opening * //*** set of the I2C address *** CDIoctl(hFile:=I2C_Handle , dRequest:=1795 , dParameter:=b_i2cAdr , pResult:=ADR(di_result_adr) ); x_Init := TRUE; END_IF (* Hauptlogik *) IF I2C_Handle <> 0 THEN (* Konfigurationsbyte setzen: Single-Ended Kanal 0, interne Referenz *) b_config_byte := 16#8C; (* 10001100b: AIN0, interne Referenz, Single-Ended *) ab_cmd_buffer[0] := b_config_byte; (* Schreiboperation zum Konfigurieren des Chips *) CDWrite(hFile:= I2C_Handle, pbyBuffer:= ADR(ab_cmd_buffer), udCount:= SIZEOF(ab_cmd_buffer), pResult:= ADR(di_result_wr_cmd)); IF di_result_wr_cmd = 0 THEN (* Leseoperation, um den ADC-Wert zu erhalten *) CDRead(hFile:= I2C_Handle, pbyBuffer:= ADR(ab_data_buffer), udCount:= SIZEOF(ab_data_buffer), pResult:= ADR(di_result_rd_cmd)); IF di_result_rd_cmd = 0 THEN (* ADC-Wert aus den Daten extrahieren *) ui_adc_value_1 := SHL(TO_UINT(ab_data_buffer[0]), 8) OR TO_UINT(ab_data_buffer[1]); ELSE (* Fehler beim Lesen der Daten *) ui_adc_value_1 := 0; (* ADC-Wert auf 0 setzen *) END_IF ELSE (* Fehler beim Schreiben der Konfiguration *) ui_adc_value_1 := 0; END_IF END_IF
Last updated: 2024-12-13

Post by bbm1995 on Camera RTSP Feed CODESYS Forge talk (Post)
Hi dgrard, I had the same issue for a long time, but on a WAGO webvisu. Now I'm glad that I can share my solution. I don't know if you are trying to use the webvisu or the target visu, but this works on webvisu: Get "go2rtc" and set it up according to the documentation. I'm running the Windows binary. Here's my example of the go2rtc.yaml config file (contains working example streams): api: listen: ":1984" # default ":1984", HTTP API port ("" - disabled) origin: "*" # default "", allow CORS requests (only * supported) static_dir: "www" # default "", folder for static files (custom web interface) tls_listen: ":443" # default "", enable HTTPS server tls_cert: "./SSL/fullchain.pem" tls_key: "./SSL/privatekey.pem" streams: # Streams with multiple links will fall back on the next link. ABUS TVIP48511: - rtsp://<username>:<password>@<hostname>:<port>/ch1/main - rtsp://<username>:<password>@<hostname>:<port>/ch1/sub # Diagnostic connections Kirchhoff Institute for Physics - Germany: http://pendelcam.kip.uni-heidelberg.de/mjpg/video.mjpg Blanton Bottling, Kentucky - USA: http://camera.buffalotrace.com/mjpg/video.mjpg Tokyo - Japan: http://61.211.241.239/nphMotionJpeg?Resolution=320x240&Quality=Standard Tampere Hacklab - Finland: http://tamperehacklab.tunk.org:38001/nphMotionJpeg?Resolution=640x480&Quality=Clarity Soltorget Pajala - Sweden: http://195.196.36.242/mjpg/video.mjpg Kaiskuru Skistadion - Norway: http://77.222.181.11:8080/mjpg/video.mjpg webrtc: listen: ":8555" #ice_servers: # - urls: [ "stun:localhost:3478" ] # username: "" # credential: "" Access the webinterface of go2rtc and get the link of your stream. Use the link as for your browser frame in the visualization. Depending on your device, you need to be able to access the file /etc/lighttpd/lighttpd.conf or /etc/lighttpd/webvisu.conf and change the contents similar to this one, otherwise you'll get CORS and CSP errors in the browser and you won't be able to view the stream on the webvisu: # Webvisu specific settings $SERVER["socket"] =~ port_webvisu_used_any { url.redirect += ( "^/webvisu/?$" => "/webvisu/webvisu.htm" ) $HTTP["url"] =~ "^/webvisu/?" { var.response_header_policy_webvisu = ( # CSP for WebVisu, allowing inline sources. "Content-Security-Policy" => "default-src 'self' 'unsafe-inline'; media-src *; frame-src *", # CORS for WebVisu, allowing any origin to access. "Access-Control-Allow-Origin" => "*", # Tell older browsers that this page can only be displayed if all ancestor # frames are same origin to the page itself. "X-Frame-Options" => "SAMEORIGIN" ) # Response header policy for WebVisu setenv.set-response-header = var.response_header_policy_webvisu setenv.set-response-header += var.response_header_policy_common }
Last updated: 2023-11-14

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

Post by spiessli on Raspberry Pi 4 with Legacy Drivers and Codesys 3.5.19 Patch 4 CODESYS Forge talk (Post)
Hi, I wanted to use the Adafruit Hat for the Raspberry and get acquainted with Softmotion using servos for RC models. This did work great with Codesys 3.5.19 Patch 1, but with Patch 4 and 5 i get errors. I suspect changes in the SoftMotion library have broken dependencies in the legacy drivers, might that be true? Thanks for any hint, spiessli Here the error log: ------ Übersetzungslauf gestartet: Applikation: Device.Application ------- Code typisieren... Code erzeugen... [FEHLER] sm3_drive_servo, 4.6.0.0 (3s - smart software solutions gmbh): GetStandardConfigParams AXIS_REF_SERVO: C0032: Typ 'Unbekannter Typ: 'ConfigGetParameterValueLREAL(pParam, 0)'' kann nicht in Typ 'LREAL' konvertiert werden [FEHLER] sm3_drive_servo, 4.6.0.0 (3s - smart software solutions gmbh): GetStandardConfigParams AXIS_REF_SERVO: C0046: Bezeichner 'ConfigGetParameterValueLREAL' nicht definiert [FEHLER] sm3_drive_servo, 4.6.0.0 (3s - smart software solutions gmbh): GetStandardConfigParams AXIS_REF_SERVO: C0035: Programmname, Funktion oder Funktionsbausteinstanz an Stelle von 'ConfigGetParameterValueLREAL' erwartet [FEHLER] sm3_drive_servo, 4.6.0.0 (3s - smart software solutions gmbh): GetStandardConfigParams AXIS_REF_SERVO: C0032: Typ 'Unbekannter Typ: 'ConfigGetParameterValueLREAL(pParam, 0)'' kann nicht in Typ 'LREAL' konvertiert werden [FEHLER] sm3_drive_servo, 4.6.0.0 (3s - smart software solutions gmbh): GetStandardConfigParams AXIS_REF_SERVO: C0046: Bezeichner 'ConfigGetParameterValueLREAL' nicht definiert [FEHLER] sm3_drive_servo, 4.6.0.0 (3s - smart software solutions gmbh): GetStandardConfigParams AXIS_REF_SERVO: C0035: Programmname, Funktion oder Funktionsbausteinstanz an Stelle von 'ConfigGetParameterValueLREAL' erwartet [FEHLER] sm3_drive_servo, 4.6.0.0 (3s - smart software solutions gmbh): GetStandardConfigParams AXIS_REF_SERVO: C0032: Typ 'Unbekannter Typ: 'ConfigGetParameterValueLREAL(pParam, 0)'' kann nicht in Typ 'LREAL' konvertiert werden [FEHLER] sm3_drive_servo, 4.6.0.0 (3s - smart software solutions gmbh): GetStandardConfigParams AXIS_REF_SERVO: C0046: Bezeichner 'ConfigGetParameterValueLREAL' nicht definiert [FEHLER] sm3_drive_servo, 4.6.0.0 (3s - smart software solutions gmbh): GetStandardConfigParams AXIS_REF_SERVO: C0035: Programmname, Funktion oder Funktionsbausteinstanz an Stelle von 'ConfigGetParameterValueLREAL' erwartet [FEHLER] sm3_drive_servo, 4.6.0.0 (3s - smart software solutions gmbh): GetStandardConfigParams AXIS_REF_SERVO: C0032: Typ 'Unbekannter Typ: 'ConfigGetParameterValueLREAL(pParam, 0)'' kann nicht in Typ 'LREAL' konvertiert werden [FEHLER] sm3_drive_servo, 4.6.0.0 (3s - smart software solutions gmbh): GetStandardConfigParams AXIS_REF_SERVO: C0046: Bezeichner 'ConfigGetParameterValueLREAL' nicht definiert [FEHLER] sm3_drive_servo, 4.6.0.0 (3s - smart software solutions gmbh): GetStandardConfigParams AXIS_REF_SERVO: C0035: Programmname, Funktion oder Funktionsbausteinstanz an Stelle von 'ConfigGetParameterValueLREAL' erwartet [FEHLER] sm3_drive_servo, 4.6.0.0 (3s - smart software solutions gmbh): GetStandardConfigParams AXIS_REF_SERVO: C0032: Typ 'Unbekannter Typ: 'ConfigGetParameterValueLREAL(pParam, 0)'' kann nicht in Typ 'LREAL' konvertiert werden [FEHLER] sm3_drive_servo, 4.6.0.0 (3s - smart software solutions gmbh): GetStandardConfigParams AXIS_REF_SERVO: C0046: Bezeichner 'ConfigGetParameterValueLREAL' nicht definiert [FEHLER] sm3_drive_servo, 4.6.0.0 (3s - smart software solutions gmbh): 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-19

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

Post by 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 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

<< < 1 .. 61 62 63 64 > >> (Page 63 of 64)

Showing results of 1578

Sort by relevance or date