Post by to-ke on Errors with VisuUserManagement library ^{CODESYS Forge talk (Post)}
Hallo zusammen, hi all, ich habe den gleichen Fehler. Auf einem Raspberry Pi geht der Fehler weg, wenn ich alles bereinige und dann vollständig übersetze. Wenn das Projekt im Codesys Development System wieder neu geladen wird ist der Fehler aber wieder da. Mit eine Win V3 x64 PLC kann ich den Fehler nur unterbinden wenn ich auf der HMI das VUM_Login einbinde. Dieses brauche ich aber nicht, da ich die HMI für das User Management selbst gestaltet habe. Das funktioniert auch. I have the same error. On a Raspberry Pi the error goes away if I clean everything and then compile completely. When the project is reloaded in the Codesys Development System, the error returns. With a Win V3 x64 PLC I can only prevent the error if I integrate the VUM_Login on the HMI. But I don't need this because I designed the HMI for user management myself. That works too. Anyone have an idea to fix this problem. Many thanks
Last updated: 2024-07-09

Post by fless on Von SNMP auf IIoT wechseln ^{CODESYS Forge talk (Post)}
Hallo, 1. Willkommen :-) 2. Da hast schon etwas worauf du aufbauen kannst. 3. Da gibt es von WAGO Hilfen wie man Projekte zu Codesys 3.5 migriert. 4. Mit SNMP habe ich keine Erfahrung, kann dir leider nicht weiterhelfen. 5. WAGO hat eine eigene SNMP Implementierung. Ich vermute WAGO entwickelt diese Libary nicht mehr parallel weiter, deshalb die Aussage des Supports. Die Codesys SNMP lib ist in das Paket IoT gepackt worden. Die Library kannst du ganz normal einbinden wenn du die IoT Lizenz für das Gerät gekauft hast . Hilfe findest du hier Wenn du keine Lizenz hast sollte die Lib einen gewissen Zeitraum, iirc 30 Minuten, ohne Einschränkungen im Demomodus laufen. Zu den Detailfragen, das ist eine WAGO Libary da wirst du hier nur mit viel Glück Hilfe finden. Ich würde für ein Retrofit auf die Version von Codesys wechseln, dann bist du auch nicht mehr abhängig vom Hersteller. Grüße
Last updated: 2024-08-21

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 kevinrn on CODESYS Development System V3 installation auf unter Parallells Windows 11auf MAC PRO M1 ARM Prozessor ^{CODESYS Forge talk (Post)}
Hallo, das Thema ist ja etwas offtopic. Aber ich kann gerne mal von meiner Erfahrung berichten: Nachdem ich von 2020 bis 2023 immer einen MacBook Pro mit Intel CPU hatte (i9/32GB) und nun seit Januar 2024 mit dem M3 Max unterwegs bin kann ich Nachfolgendes berichten. Infos zu den Aufgaben, die ich damit erledige: Die Runtime nutze ich nicht auf dem Mac (Wenn ich von Mac rede, dann meine ich damit die Win11 ARM64 Parallels Umgebung) Ich nutze die IDE für Library development und für automatisierungs Tests von CI/CD jobs. Weiterhin öffne ich oft große Projektarchive mit teilweise 160 MB. Erfahrungen zur Installation von CODESYS Versionen: Ich habe einige Versionen installiert, unter anderem, 3.5.14.4, 3.5.17.2, 3.5.16.3, 3.5.18.4 und 3.5.19.6. Ich hatte mit keiner einizgen Installation ein Problem. Die Installation lief immer ohne Probleme durch. Runtimes (Control Win) installiere ich nicht. Ich nutze linux basierte Zielsysteme und bei bedarf eine Windows VM auf einen entfernen Host mit X64. Lokales Gateway läuft ebenso Sonstige Erfahrungen: Ich nutze viele Komponenten Querbeet: Alarming, AC Persistence, Symbol Konfiguration, CFC und ST Editor, externes Packages wie STWeep, Git für Library Entwicklung, Visu, etc. Mit keiner dieser "Komponenten" hatte ich schwierigkeiten oder einen Unterschied zu x64 systemen festgestellt. Man muss aber auch sagen, dass das alles nur ein kleiner Bruchteil ist, was die CODESYS Welt beinhaltet, deshalb sind diese Aussagen auch nur subjektiv aus meinem Erfahrungsbereich. Für das Entwickeln von Libraries sehe ich keine Performance Einschränkungen. Ganz im Gegenteil, für das, dass hier eine emulation stattfindet, ist es erstaunlich schnell. Meiner Meinung nach sind sogar einfache und kleine Projekte schneller als beim Intel Mac. Die Akku Leistung mit dem Mac und Parallels ist fantastisch. Lüfter hört man nicht mal bei der Nutzung von CODESYS. Beim Intel konnte ich sonst ein Spiegelei auf der Abdeckung zubereiten... Was evtl. etwas langsamer ist bzw. mir manchmal so vor kommt ist, der CFC Editor im Online Mode. Aber hierzu fehlt mir ein richtiger Vergleich. Fazit: Ich bin selbst erstaunt wie gut die CODESYS IDE auf einem ARM64 emuliert wird. Ich muss aber auch sagen, dass ich jederzeit eine x64 Workspace zur Verfügung habe, falls was nicht funktionieren sollte. Das habe ich mir extra zum Umstieg zu gelegt. Bisher habe ich es jedoch noch nie benötigt, da meine Anforderungen alle erfüllt werden. Es sollte einem aber bewusst sein, dass dies keine supportete Umgebung ist und man auch bei spezifischen Problemen keinen Support erwarten sollte. Ich nutze CODESYS ca. 4-12 Stunden die Woche und ich warte immer noch auf etwas, um meine X64 Cloud Workspace mal zu verwenden... Vielleicht hilft dir dies ja etwas bei der Entscheidung.
Last updated: 2024-03-21

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

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

Sort by relevance or date