CODESYS Forge - CODESYS Forge / Talk / Search

<< < 1 .. 57 58 59 60 61 62 > >> (Page 59 of 62)

Post by axberry on CODESYS Control for Raspberry Pi 5 - "Hardware version or firmware version not supported" on Rev 1.1, persists across multiple runtime versions and OS images ^{CODESYS Forge} ^talk ^(Post)
Hi, I'm trying to run CODESYS Control for Raspberry Pi SL on a Raspberry Pi 5, and the runtime consistently fails to start with the following error when launched manually: ooops... this runtime was built for RASPBERRYPI. Hardware version or firmware version not supported! (-18, 0x00000BB8, 0xFFFFFFFB) Hardware: Raspberry Pi 5 Model B Rev 1.1 Revision code: d04171 CPU: aarch64, BCM2712 Serial number is correctly exposed via /proc/cpuinfo and /proc/device-tree/serial-number /proc/device-tree/model correctly reports "Raspberry Pi 5 Model B" What I've tried (all resulting in the same error): CODESYS Control for Raspberry Pi SL 4.11.0.0 (SDK 3.5.19.61) — the version that introduced Pi 5 support CODESYS Control for Raspberry Pi SL 4.21.0.0 (SDK 3.5.22.20) — latest available Raspberry Pi OS Bookworm (64-bit) with kernel 6.12.93+rpt-rpi-2712 (June 2026 build) Fresh install on Raspberry Pi OS Bookworm (64-bit) with an older image from November 24, 2025 — same error, ruling out a kernel-version regression Bootloader/EEPROM confirmed up to date (rpi-eeprom-update reports "up to date") Clean purge and reinstall of the codesyscontrol package each time (verified via dpkg -l, no leftover files) Verified /etc/codesyscontrol/3S.dat correctly symlinks to /etc/codesyscontrol/3S_aarch64.dat The service starts (systemctl status briefly shows active (running) with a real PID under /opt/codesys/bin/codesyscontrol.bin), but crashes shortly after and the process disappears — port 11740 never opens. Since this happens identically across two different runtime versions and two different OS images (5+ months apart), it doesn't seem to be a kernel/firmware timing issue. Could this be specific to the Rev 1.1 board revision, or is there a known issue with the hardware detection logic in the SL runtime that I should be aware of? Happy to provide full debug logs (-d flag output) or journalctl output if useful. Thanks in advance!
Last updated: 2026-08-10

Post by mariapaola on Port instantiation of serial interface in WAGO PLC using Modb_L05.lib in CoDeSys v2.3 ^{CODESYS Forge} ^talk ^(Post)
Hi, Would really appreciate your insights in this issue I have. I am currently using a WAGO 750-881 with multiple IO devices. For one of them I already occupied the MODBUS Master configuration tool so I cannot overwrite it for my other devices. I have a total of two serial interfaces WAGO 750-652. The first one is instantiated in COM2 and doesn't need any protocol since the information comes in an specific formatting that need little code to differentiate between needed info. This one is working just fine. The second one is where I have an issue. I have tried to instantiate the port using MODBUS library modb_L05.lib to properly receive the data from an ARDUINO and I am absolutely unable to open the port: Signal DEVICE2.fbModbus.MODBUS_EXT_MASTER.Interface.Com_Port_Ist_Offen is never TRUE, among with all other signals from that interface, while signal DEVICE1.COM2.Com_Port_Ist_Offen is TRUE, and the other signals also read as TRUE or FALSE. I have tried instantiating the second one as the first one, changing COM3 to COM4, I've tried a lot of things but it wont ever open the channel. I don't know if you have any recommendations for me. For both physical modules, both witness LEDs A and E are on. First one is instantiated like this: PROGRAM DEVICE1 VAR wBaudRate : WORD := BAUD_9600; bDataBits : BYTE := 8; bParity : BYTE := 0; bFlowControl : BYTE := 3; (RS422 FullDuplex with continous send) i : INT; COM2 : SERIAL_INTERFACE; xOpenPort2 : BOOL := TRUE; ( Flag to open the Port ) xInitPort2 : BOOL; ( Flag to initiallize the Port ) ReceiveBuffer2 : typRing_Buffer; END_VAR COM2( bCOM_PORT_NR := 2, cbBAUDRATE := wBaudRate, cbsBYTESIZE := bDataBits, cpPARITY := bParity, csSTOPBITS := STOPBITS_1, cfFLOW_CONTROL := bFlowControl, utRECEIVE_BUFFER := ReceiveBuffer2, ptSEND_BUFFER := ADR(SendString2), xINIT := xInitPort2, xOPEN_COM_PORT := xOpenPort2, iBYTES_TO_SEND := LEN(SendString2)+1, xSTART_SEND := xSendActive2 ); Second one like this: PROGRAM DEVICE2 VAR COM4 : SERIAL_INTERFACE; xInitPort4 : BOOL := TRUE; xOpenPort4 : BOOL := TRUE; ReceiveBuffer4 : typRing_Buffer; fbModbus : MODBUS_EXTENDED_MASTER_RTU; fbError : enumMB_ERROR; stQuery : typModbusExtendedQuery; stResponse : typModbusResponse; au16Data : ARRAY[0..14] OF WORD; i : INT; tPoll : TON; END_VAR COM4( bCOM_PORT_NR := 4, cbBAUDRATE := BAUD_9600, cbsBYTESIZE := 8, cpPARITY := 0, csSTOPBITS := STOPBITS_1, cfFLOW_CONTROL := 2, ( RS-485 half-duplex ) utRECEIVE_BUFFER := ReceiveBuffer4, xINIT := xInitPort4, xOPEN_COM_PORT := xOpenPort4, xSTART_SEND := xSendActive4, ); stQuery.SlaveAddress := 1; stQuery.FunctionCode := 3; stQuery.Read_StartAddress := 0; stQuery.Read_Quantity := 15; (Poll code) fbModbus( ENABLE := TRUE, bCOM_PORT := 4, ( COM4=> 750-652 port ) cbCOM_BAUDRATE := BAUD_9600, cpCOM_PARITY := 0, csCOM_STOPBITS := 1, cbsCOM_BYTESIZE := 8, cfCOM_FLOW_CONTROL := 2, TimeOut := T#500ms, StartFunction := xStart, ExtQuery := stQuery, Response := stResponse, MB_Error => fbError ); FOR i := 0 TO 14 DO au16Data[i] := stResponse.Data[i]; END_FOR;
Last updated: 2025-11-28

Post by baltzer on ICertificateVerifier.VerifyCertificate doesn't appear to override an ERR_CERT_HAS_EXPIRED rejection in TCP_Client.Upgrade() ^{CODESYS Forge} ^talk ^(Post)
Follow-up: working workaround found (routing TLS outside CODESYS) For anyone finding this thread later with the same problem (a third-party device presenting a self-signed and/or expired certificate that ICertificateVerifier/udiVerificationMode won't let you connect through) - we never got a working fix within NBS itself, but found a practical workaround worth sharing. Approach: run a local TLS-terminating proxy on the same host as the CODESYS runtime, and have CODESYS talk plain, unencrypted TCP to it instead of connecting to the remote device directly over TLS: CODESYS --plain TCP--> 127.0.0.1:<port> --stunnel/TLS--> <remote device>:<port> We used stunnel (client mode), with certificate verification explicitly disabled at that layer (verifyChain = no, verifyPeer = no) - a simple, well-documented one-line option, unlike anything we could get working inside NBS. Running it as a systemd service with Restart=always means it survives reboots and recovers automatically if the proxy or the remote device drops. On the CODESYS side, this required no changes beyond pointing TCP_Client at 127.0.0.1 instead of the device's real IP, and removing the TLSContext/ICertificateVerifier code entirely - the rest of our application-layer logic (framing, checksums, etc.) was completely unaffected, since none of that ever depended on where the TLS termination happened. Confirmed working end-to-end against a real device with an expired self-signed certificate, running on CODESYS Control for Raspberry Pi SL (Linux). We haven't yet set this up on Windows - stunnel does have Windows builds available, so the same general approach should be possible there too, but that combination isn't tested or confirmed by us at this point. Caveat: this only makes sense when the proxy and the CODESYS runtime are on the same trusted host (in our case, both on the same Raspberry Pi) - don't expose the proxy's plaintext side on a reachable network interface, since that would create an unauthenticated plaintext path to the device. The original question - whether there's a supported way to override an ERR_CERT_HAS_EXPIRED/self-signed rejection from within NBS's own TLSContext/ICertificateVerifier - remains open as far as we know. Still happy to hear from anyone who's solved that particular piece, since the workaround above is a practical detour rather than an actual answer to the original question.
Last updated: 2026-08-06

Post by paulpotat on cm4 runtime problem ^{CODESYS Forge} ^talk ^(Post)
Hello, We are having the same kind of problem again with the last CM4 we received : ooops... this runtime was built for RASPBERRYPI. Hardware version or firmware version not supported! (-18, 0x00000BB8, 0xFFFFFFFB) Hardware Version $ cat /proc/cpuinfo processor : 0 model name : ARMv7 Processor rev 3 (v7l) BogoMIPS : 126.00 Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32 CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x0 CPU part : 0xd08 CPU revision : 3 processor : 1 model name : ARMv7 Processor rev 3 (v7l) BogoMIPS : 126.00 Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32 CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x0 CPU part : 0xd08 CPU revision : 3 processor : 2 model name : ARMv7 Processor rev 3 (v7l) BogoMIPS : 126.00 Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32 CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x0 CPU part : 0xd08 CPU revision : 3 processor : 3 model name : ARMv7 Processor rev 3 (v7l) BogoMIPS : 126.00 Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32 CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x0 CPU part : 0xd08 CPU revision : 3 Hardware : BCM2711 Revision : a03141 Serial : 1000000097594db7 Model : Raspberry Pi Compute Module 4 Rev 1.1 Kernel Version $ uname -a Linux cmr-pv2-1t00-0001 6.12.25-rt9-v7l #1 SMP PREEMPT_RT Thu Sep 25 11:53:00 CEST 2025 armv7l GNU/Linux OS Version $ cat /etc/os-release PRETTY_NAME="Raspbian GNU/Linux 12 (bookworm)" NAME="Raspbian GNU/Linux" VERSION_ID="12" VERSION="12 (bookworm)" VERSION_CODENAME=bookworm ID=raspbian ID_LIKE=debian HOME_URL="http://www.raspbian.org/" SUPPORT_URL="http://www.raspbian.org/RaspbianForums" BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs" CodeSys runtime 4.13.0.0 So far we tested runtime versions up to 4.18.0.0, here are the results : * 4.13.0.0 --> Not working ❌ * 4.14.0.0 --> Not working ❌ * 4.15.0.0 --> Not working ❌ * 4.16.0.0 --> Not working ❌ * 4.17.0.0 --> Working ✅ * 4.18.0.0 --> Working ✅ There is nothing in the 4.17.0.0 release note that mentions that, so I'm not sure what to think about this. Is this a known problem within the CodeSys development team ? If yes, how do you follow CM4 hardware evolutions ? Is there a way of making this work without having to update the runtime version ? We have several products working with the 4.13.0.0 runtime and we would like to avoid having to update them all. BR
Last updated: 2026-02-02

Post by danp1406 on Question about Demo License limitations for Modbus TCP communication and Fieldbus Instances ^{CODESYS Forge} ^talk ^(Post)
Hello everyone, I am currently working with CODESYS Virtual Control for Linux running in Docker on a Debian virtual machine. I am deploying my application using Deploy Control SL, and in my project I am using the ModbusFB library to implement Modbus TCP communication. My setup is the following: I am trying to establish a Modbus TCP connection between a virtual PLC (CODESYS acting as Modbus TCP Client/Master) and a Siemens S7-1200 PLC acting as a Modbus TCP Server. From the Debian VM, I can successfully ping the S7-1200 and verify that port 502 is open using tools like nc. Network-wise, everything appears to be correct. However, when running the application in CODESYS, I receive messages such as “Demo mode for Modbus/TCP Master started. Will expire and stop!” and socket errors like “ClientSocket.UpdateStatus socket error 111 disconnecting.” The ClientTCP block from the ModbusFB library attempts to connect, but the connection does not remain stable. My main question is whether the CODESYS demo license explicitly limits or interrupts Modbus TCP Master communication. Is it expected that in demo mode the runtime will automatically close sockets after some time or prevent stable Modbus TCP connections? I would like to confirm whether this behavior is normal when using ModbusFB in demo mode, or if I should continue troubleshooting the configuration. Additionally, I would like clarification regarding the “fieldbus instances” mentioned in CODESYS licensing options (for example, 2, 4, or 16 instances). What exactly is considered one fieldbus instance? Does one Modbus TCP Client block count as one instance? Does each active connection to a different device count separately? Do Modbus TCP Master and Server count independently toward the total number of instances? Finally, I would appreciate clarification on any other practical limitations of demo mode when using industrial communication libraries such as ModbusFB. Are there limits on the number of connections, number of requests, or communication duration? I am trying to determine whether demo mode is sufficient for testing a virtual PLC communicating with a Siemens S7-1200 over Modbus TCP, or whether a full license is required even for this kind of validation scenario. Thank you in advance for any guidance.
Last updated: 2026-02-25

Post by rossanoparis on CAN TX regression in Control for Raspberry Pi 4.21.0.0 with CAN API library (RX works, TX silently fails) ^{CODESYS Forge} ^talk ^(Post)
Environment: Target: Revolution Pi (Kunbus RevPi), armv7l 32-bit OS: Raspbian GNU/Linux 9 (Stretch), kernel 4.19.95-rt38-v7 (SMP PREEMPT RT, built 2022-03-22) CAN: via SocketCAN (can0) Runtime: CODESYS Control for Raspberry Pi SL IDE: CODESYS V3.5 SP22 + patch 3 (previously V3.5 SP22 + patch 2, where everything worked with runtime 4.18.0.0) Library: CANBusAPI from the "CAN API" package, version 1.0.0.3 Summary: The setup worked correctly with V3.5 SP22 + patch 2 and runtime 4.18.0.0. After updating the IDE to SP22 + patch 3 and the runtime to 4.21.0.0, CAN transmission via the CANBusAPI library stopped working. Reception is unaffected. There are no error indications anywhere: the application runs normally and the CAN diagnosis reports a healthy bus. Systematic testing (below) shows the problem follows the runtime version, not the IDE update. Regression isolation: The same application (compiled under SP22 + patch 3, unchanged between tests) was downloaded to the same target with different runtime versions, changing only the runtime each time: 4.18.0.0: TX and RX both work 4.19.0.0: TX and RX both work 4.20.0.0: TX and RX both work 4.21.0.0: RX works, TX does not The behavior is fully reproducible in both directions (downgrading to 4.20 restores TX, upgrading to 4.21 breaks it again). Hardware, wiring, OS, project, and application code are identical across all tests. Diagnostic data (CANBusDiagnosis FB, while the application is transmitting on 4.21): ctSendCounter: incrementing normally ctTxErrorCounter: 0 ctRxErrorCounter: 0 eState: ERROR_FREE xBusAlarm: FALSE So the library accepts and counts the outgoing messages, no TX errors are reported, and the CAN controller state stays error-free, but the messages never reach the other nodes on the bus. Expected behavior: Messages sent via CANBusAPI (CANDriver / SendMessage) are transmitted on the bus, as with runtime versions up to and including 4.20.0.0. Notes: I am aware that the CAN API package (1.0.0.3, from 2016) is old; however, the regression is tied to the runtime version, since the identical binary works on 4.18-4.20. Questions: Is there a known change in CmpSocketCanDrv / CmpCAACanL2 between 4.20.0.0 and 4.21.0.0 that could affect TX via the CAN API library? Is runtime 4.21.0.0 still supported on Debian 9 Stretch (kernel 4.19, RT-patched), or is a newer OS required? If a minimum OS/kernel requirement was introduced with 4.21, is it documented?
Last updated: 2026-08-17

Post by clesio on CAA.File.Write – Unexpected characters when writing a CSV file ^{CODESYS Forge} ^talk ^(Post)
Hello everyone, I am trying to create a routine in CODESYS to export a report to a CSV file using the CAA.File library. The file is created successfully, but I am getting some unexpected/unknown characters in the generated CSV. The problem seems to be related to the SIZEOF() function. I am using it for the szSize parameter of File.Write, as recommended in the CODESYS documentation. However, when I use SIZEOF(), the CSV contains extra characters and parts of previous strings. I also tried using LEN(), but in my application the file is created empty, even though the string and the calculated length appear to be correct. Here is the relevant part of my code: PROGRAM Relatorio VAR // Bool b_Executa_fb_Cria_Arquivo : BOOL; b_Executa_fb_Fecha_Arquivo : BOOL; b_Escreve_dados : BOOL; b_Erro_fb_Escreve : BOOL; //STR s_Nome_Arquivo : STRING; s_Palavra : STRING; s_Palavra_Anterior : STRING; s_Data_Atualizada_Formatada : STRING; s_Dia : STRING; s_Mes : STRING; s_Ano : STRING; s_Hora_Atualizada_Formatada : STRING; s_Hora : STRING; s_Minu : STRING; s_Segu : STRING; //INT i_modo_fb_Cria_Arquivo : INT; i_ErroID_fb_Escreve : INT; //UINT i_Tamanho_Palavra : UINT; // Blocos de Funcao fb_Cria_Arquivo : FILE.Open; fb_Fecha_Arquivo : FILE.Close; fb_Escreve : FILE.Write; // DATA E HORA sc_DataTime : SysTimeRtc.RTS_SYSTIMEDATE; // STRUCT = sc uidResultRtcGet : UDINT; //stGetDate : SysTimeRtc.RTS_SYSTIMEDATE; uidResultConvertToDate : UDINT; uidResult : RTS_IEC_RESULT; END_VAR VAR_INPUT //BOOL b_SET_Executa_fb_Cria_Arquivo : BOOL; b_RES_Executa_fb_Cria_Arquivo : BOOL; b_Executa_fb_Escrita : BOOL; // INT i_Linhas_Cabecalho : INT; i_Linhas_Cabecalho_Anterior : INT; END_VAR // Para Testes s_Nome_Arquivo := 'relatorio/Teste1M.CSV'; i_modo_fb_Cria_Arquivo := 0; // TRATAMENTO DE DATOS DATA e HORA uidResultRtcGet := SysTimeRtcGet(uidResult); uidResultConvertToDate := SysTimeRtcConvertUtcToDate(dwTimestampUtc := uidResultRtcGet, pDate := sc_DataTime); // FORMATA DATA EM UMA STRING s_Dia := UINT_TO_STRING(sc_DataTime.wDay); s_Mes := UINT_TO_STRING(sc_DataTime.wMonth); s_Ano := UINT_TO_STRING(sc_DataTime.wYear); s_Data_Atualizada_Formatada := CONCAT(s_Dia, CONCAT('/', CONCAT(s_Mes, CONCAT('/', s_Ano)))); // FORMATA HORA EM UMA STRING s_Hora := UINT_TO_STRING(sc_DataTime.wHour); s_Minu := UINT_TO_STRING(sc_DataTime.wMinute); s_Segu := UINT_TO_STRING(sc_DataTime.wSecond); s_Hora_Atualizada_Formatada := CONCAT(s_Hora, CONCAT(':', CONCAT(s_Minu, CONCAT(':', s_Segu)))); // ABRE e CRIA ARQUIVO IF (b_SET_Executa_fb_Cria_Arquivo OR b_Executa_fb_Cria_Arquivo) AND NOT(b_RES_Executa_fb_Cria_Arquivo) THEN b_Executa_fb_Cria_Arquivo := TRUE; ELSE b_Executa_fb_Cria_Arquivo := FALSE; END_IF fb_Cria_Arquivo( xExecute := b_Executa_fb_Cria_Arquivo, sFileName := s_Nome_Arquivo, eFileMode := i_modo_fb_Cria_Arquivo, xExclusive := FALSE, ); //i_Tamanho_Palavra := SizeOf(s_Palavra); // ESCREVE NO ARQUIVO fb_Escreve( xExecute := b_Executa_fb_Escrita, hFile := fb_Cria_arquivo.hFile, szSize := SIZEOF(s_Palavra), pBuffer := ADR(s_palavra) ); // FECHA ARQUIVO fb_Fecha_Arquivo( xExecute := b_Executa_fb_Fecha_Arquivo, hFile := fb_Cria_arquivo.hFile ); IF Criacao_Edicao_Arquivos.b_Escreve_Cabecalho THEN CASE i_Linhas_Cabecalho OF 1 : s_palavra := 'ESTERILIZADOR'; 2: s_palavra := 'MAQ4; $R$L'; 3: s_palavra := CONCAT(CONCAT('CLIENTE: ',GVL.sReceitaAtual), '$R$L'); 4: s_palavra := CONCAT(CONCAT('NUMERO LOTE: ',DINT_TO_STRING(GVL.Lote)), '$R$L'); 5: s_palavra := CONCAT(CONCAT('OPERADOR: ', DINT_TO_STRING(GVL.Operador)), '$R$L'); 6: s_palavra := CONCAT(CONCAT('DATA: ', s_Data_Atualizada_Formatada), '$R$L'); 7: s_palavra := CONCAT(CONCAT('HORA: ', s_Hora_Atualizada_Formatada), '$R$L'); 8: s_palavra := '$R$L'; 9: s_palavra := 'PARAMETROS AJUSTADOS $R$L'; 10: s_palavra := CONCAT('TEMPO PRE COND.: ', CONCAT(INT_TO_STRING(GVL.rc_T_PreCondicionamento), ' min $R$L')); 11: s_palavra := CONCAT('PULSOS INERTIZACAO 1: ', CONCAT(INT_TO_STRING(GVL.rc_PulsosInertizacao_1), ' PULSOS $R$L')); 12: s_palavra := CONCAT('PULSOS INERTIZACAO 2: ', CONCAT(INT_TO_STRING(GVL.rc_PulsosInertizacao_2), ' PULSOS $R$L')); 13: s_palavra := CONCAT('PULSOS AERACAO: ', CONCAT(INT_TO_STRING(GVL.rc_PulsosAeracao_2), ' PULSOS $R$L')); 14: s_palavra := CONCAT('PRESSAO DE VACUO 1: ', CONCAT(REAL_TO_STRING(GVL.rc_PV1_max), ' bar $R$L')); 15: s_palavra := CONCAT('PRESSAO DE VACUO 2: ', CONCAT(REAL_TO_STRING(GVL.rc_PV2), ' bar $R$L')); 16: s_palavra := CONCAT('PRESSAO INERTIZACAO 1: ', CONCAT(REAL_TO_STRING(GVL.rc_PN1), ' bar $R$L')); 17: s_palavra := CONCAT('PRESSAO INERTIZACAO 2: ', CONCAT(REAL_TO_STRING(GVL.rc_PN2), ' bar $R$L')); 18: s_palavra := CONCAT('PRESSAO AERACAO: ', CONCAT(REAL_TO_STRING(GVL.rc_PAR), ' bar $R$L')); 19: s_palavra := CONCAT('PRESSAO ETO: ', CONCAT(REAL_TO_STRING(GVL.rc_PressaoETO), ' bar $R$L')); 20: s_palavra := CONCAT('PRESSAO Compl.: ', CONCAT(REAL_TO_STRING(GVL.rc_PressaoETO_2), ' bar $R$L')); 21: s_palavra := CONCAT('MASSA ETO: ', CONCAT(REAL_TO_STRING(GVL.rc_QuantidadeETO), ' Kg $R$L')); 22: s_palavra := CONCAT('TEMPO PRE COND. Vacuo/Vapor: ', CONCAT(INT_TO_STRING(GVL.rc_T_Vapor_1), ' min $R$L')); 23: s_palavra := CONCAT('SET-POINT: ', CONCAT(REAL_TO_STRING(GVL.ihm_SPTemperatura), ' °C $R$L')); 24: s_palavra := CONCAT('TEMPO ESTERILIZACAO: ', CONCAT(INT_TO_STRING(GVL.rc_TempoEsterilizacao), ' min $R$L')); 25: s_palavra := CONCAT('TEMPO PARADA: ', CONCAT(INT_TO_STRING(GVL.rc_T_PressaoParada), ' min $R$L')); 26: s_palavra := CONCAT('UMIDADE: ', CONCAT(REAL_TO_STRING(GVL.rc_UmidadeRelativa), ' % $R$L')); 27: s_palavra := '$R$L'; END_CASE END_IF Note: The code I am attaching does not include the execution/sequence management of the function blocks. I have omitted this part to keep the example focused on the CSV writing routine. The function blocks are triggered and managed by a separate state machine. I am not sure what the correct approach is in this case, especially since the official documentation recommends using SIZEOF() for szSize. I will attach my code and a screenshot of the generated CSV showing the issue. Has anyone experienced something similar or could suggest the correct way to write a changing STRING to a CSV file using CAA.File.Write?
Last updated: 2026-09-08

Post by cfam on Codesys Control for PLCnext (PLC - AXL F 2152) ^{CODESYS Forge} ^talk ^(Post)
Good day All I would like to share some information on this site for the Codesys team as well for the future members using Codesys Control for PLCnext if it is allowed. I hope that i Post it in the correct spot. Subject: Codesys, Codesys Control for PLCnext Objective: Using the following Phoenix components to built a PLC Rack and run it on Codesys: Hardware and Software used 1. 2404267, AXC F 2152 - Controller 2. 1088136, AXL F BP SE6 - Module carrier 3. 1088129, AXL SE DO16/1 - Digital module 4. 1337224, AXL SE PD16 GND - Potential distributors 5. 1088127, AXL SE DI16/1 - Digital module 6. 1337223, AXL SE PD16 24V - Potential distributors 7. 1088123, AXL SE AO4 I 4-20 - Analog module 8. 1088134, AXL SE SC-A - Cover 9. Codesys v3.5 SP19 Patch 4 10. Codesys Control for PLCnext V4.10.0.0 Process: Firstly I built the Rack according to the Phoenix Project+ Software tool. Where I rebuilt it onto my test bench . I used the PLCnext Engineer IDE from Phoenix and all Communications where up and running and my PLC program executed successfully. THEN I tried the same PLC Layout with Codesys and Codesys Control for PLCnext. It was not successful and gave me the "Error: Local Bus not Running". I searched the web for answers but was unsuccessful in finding a solution. So I tried to change my configuration and found that the following Modules COULD NOT be recognized by Codesys Control. The result was that the Local Bus Failed to run. 1337224, AXL SE PD16 GND - Potential distributors 1337223, AXL SE PD16 24V - Potential distributors Example 1, Resulted in "Error: Local Bus Not Running": Module carrier slot 1: 1088129, AXL SE DO16/1 - Digital module Module carrier slot 2: 1337224, AXL SE PD16 GND - Potential distributors Module carrier slot 3: 1088127, AXL SE DI16/1 - Digital module Module carrier slot 4: 1337223, AXL SE PD16 24V - Potential distributors Module carrier slot 5: 1088123, AXL SE AO4 I 4-20 - Analog module Module carrier slot 6: 1088134, AXL SE SC-A - Cover Example 2, Result "Successful": Module carrier slot 1: 1088129, AXL SE DO16/1 - Digital module Module carrier slot 2: 1088127, AXL SE DI16/1 - Digital module Module carrier slot 3: 1088123, AXL SE AO4 I 4-20 - Analog module Module carrier slot 4: 1088134, AXL SE SC-A - Cover Module carrier slot 5: 1088134, AXL SE SC-A - Cover Module carrier slot 6: 1088134, AXL SE SC-A - Cover Result: Codesys or Codesys Control for PLCnext, has a PROBLEM to identify the following Modules. 1. AXL SE PD16 24V - Potential distributors 2. AXL SE PD16 GND - Potential distributors Hope that this information could be useful in future. Best regards Jaco Pretorius
Last updated: 2023-12-06

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

Post by kevinrn on Github Actions CI/CD tasks - development topic ^{CODESYS Forge} ^talk ^(Post)
Hello community, I just want to inform you about our plans and the current status of automating the build process for CODESYS libraries. So it might be helpful for some people who are in the same situation. Background story: I am a software engineer at powerIO GmbH, normally I use high level languages for the products we develop and offer. Sometimes I work with my team on CODESYS libraries, which can also be found in the CODESYS store. Most of the time I spend with them on architecture tasks and tasks that are not directly related to our products. Every time I see the manual processes for releasing a library etc., I am very surprised about this time intensive process. Current situation: I know there has been a scripting interface for years. CODESYS Git was released a few years ago, but the scripting interface was only released a few months (weeks?) ago. We developed a pseudo-automated solution a few months ago, but it was all very hacky. So now there is a better Git implementation and also more modularization and installation options. For example, the CODESYS installer has a full CLI, which makes it very convenient to install CODESYS installations headless. Plans: I think it's the right time to develop a better automation solution. Most of our software projects are hosted on Github and we use Github actions very intensively for other software projects. Therefore, we have decided to use Github for our CODESYS library projects as well. Following tasks should be implemented in automation for CI/CD tasks: - Automated setup of CODESYS installation (Already released: https://github.com/marketplace/actions/setup-codesys-installation) - Checkout CODESYS libraries - Execute tests scripts - Sign CODESYS libraries - Extract Library documentation - Create CODESYS package - Sign CODESYS package Side Note: - This is mainly a side project, and we do not provide support for the CI/CD part. - This topic is here to help and also to get help from other software engineers. - This project and idea is not prioritized as I am currently the only one working on it and I hope it will help us and also others and increase productivity. - We are putting this out there as an organization, but priorities can change quickly and the CI/CD tasks I am developing are mostly done in my spare time. So please don't expect this to happen in a short time or even be fully completed. I would be very happy if some ppl will join the development process and might be open to discuss some technical details for this. I hope this topic is not to off-topic, but I think the CI/CD part is very important today and it can increase a lot of quality and push productivity. Thanks :)
Last updated: 2024-03-28

Post by lzml on HTML5 visualization controls disabled on CODESYS Control for Linux SL - overlay not supported? ^{CODESYS Forge} ^talk ^(Post)
Hello, I'm developing a custom HTML5 visualization control (via the HTML5 Control Editor / Tools > Visualization Element Repository) and I'm running into what looks like a target-device limitation when trying to deploy it to CODESYS Control for Linux SL. I'd like to understand whether this is a known/expected limitation or something in my setup. Environment - CODESYS Development System: V3.5.22.0 - Target runtime: CODESYS Control for Linux SL, package version 4.15.0.0 (installed together with CODESYS Edge Gateway for Linux 4.15.0.0) - Visu system libraries (VisuElems, VisuElemsAlarm, VisuInputs, VisuNativeControl, etc.): version 4.7.0.0 - Host OS: Debian RT (minimal/base installation) - We only use WebVisu, not TargetVisu. What I did 1. Built a custom HTML5 control following the official HTML5-API-Examples pattern (.html5control.xml manifest + ElementWrapper.js + CSS), installed it successfully via the HTML5 Control Editor ("Save and Install") into the Visualization Element Repository. 2. In the Visualization Manager, enabled "Support client animations and overlay of native elements" (documented as required for HTML5 controls to work at all). 3. With the project's Device set to CODESYS Control for Linux SL, compiling/downloading fails with: "Overlay is not supported for your target visualization device." (Visualization Manager) Build stops with 1 error, download not possible. Isolating the cause - The Visualization Element Repository confirms the control is correctly installed. - With the project Device set to a Windows-based device, the HTML5 control appears and is enabled in the Toolbox as expected. - With the project Device set to CODESYS Control for Linux SL, the HTML5 control is disabled/missing from the Toolbox entirely, even though it's installed in the repository. This points to the Linux SL device description simply not declaring overlay/HTML5 support, rather than a missing package or Debian-side dependency (WebVisu itself already works fine for standard/native visualization elements on this same target). Questions 1. Does CODESYS Control for Linux SL currently support WebVisu overlay (and therefore custom HTML5 controls)? I found documentation stating overlay support for target visualizations (Windows and Linux) was added starting with CODESYS Development System V3.5.17.0, but that seems to refer to TargetVisu, and our case is WebVisu-only on a Linux runtime. 2. If not currently supported, is this on a roadmap, or is there a different Linux runtime package/edition that does support WebVisu overlay for HTML5 controls? 3. Is there any Linux-side configuration or package needed to enable this (given the check appears to happen against a static device capability declaration rather than a live server check), or is this purely a matter of the device description bundled with the current Control for Linux SL package? Thanks in advance for any pointers.
Last updated: 2026-08-05

Post by hammer on Cartesian XY Chart — 2-D array binding: "Element to use" enumerates the wrong dimension ^{CODESYS Forge} ^talk ^(Post)
Title: Cartesian XY Chart — 2-D array binding: "Element to use" enumerates the wrong dimension; documented example (Dialog: XY Chart Configuration, "Two-dimensional array of base type REAL") appears transposed Product / version: CODESYS Development System V3.5 SP21 Patch 40 (3.5.21.40). Cartesian XY Chart visualization element (System_VisuElemXYChart / VisuElemXYChart). Summary: When a curve's Data X/Data Y is bound to a two-dimensional array, the element treats the last array dimension as the per-point record (the one selected by "Element to use") and iterates the first dimension as the sequence of curve points. The online documentation's worked example has the dimensions in the opposite order, so following it produces a non-functional curve and a nonsensical "Element to use" list. Steps to reproduce (fails — matches the documented layout): 1. Declare aData : ARRAY[0..1, 0..4095] OF LREAL; (2 data sets × 4096 points, i.e. first dimension = set, second = point). 2. In XY Chart Configuration, bind a curve's Data X (and Y) Variable to this array. 3. Observe the "Element to use" combobox. Actual result: The "Element to use" combobox lists 4096 entries (the indices of the second dimension) instead of 2 (the data sets in the first dimension). Selecting a row does not produce the expected curve; at most a single/degenerate point is plotted. Steps to reproduce (works — transposed): 1. Declare aData : ARRAY[0..4095, 0..1] OF LREAL; (points first, set second). 2. Bind Data X/Y to this array; "Element to use" now correctly lists [0] and [1]. 3. Populate aData[point, set] and the curve plots as expected. Expected result: Either the documented example should select the data set from the first dimension (as its [1]/[2] "Element to use" implies), or the documentation should state that the last dimension is the record dimension (stride) and the first dimension is the point sequence — consistent with how the element actually behaves. Analysis: The behavior is self-consistent if the element always walks a single array by a fixed byte stride, reading one element per point — the same mechanism as the documented "one-dimensional array of a DUT" case, where it strides by SIZEOF(DUT) and "Element to use" picks the member offset. For a 2-D array the record is the last dimension: to plot column/set c it starts at [0, c] and strides by the last-dimension length to reach [1, c], [2, c], … (row-major layout makes this a contiguous column walk). Under that rule, ARRAY[0..N, 0..1] is correct (record length 2 → "Element to use" [0]/[1]), and the documented ARRAY[1..2, 1..50] with "Element to use" [1]/[2] is transposed. Documentation reference: Dialog: XY Chart Configuration → Data X / Data Y → "Example: Two-dimensional array of the base type REAL" (ARRAY[1..2, 1..50], Element to use [1]/[2], "100 array values are displayed"). This example does not plot as described in 3.5.21.40; transposing to ARRAY[1..50, 1..2] does. Request: Please confirm whether this is (a) a documentation error (example dimensions reversed) or (b) an element defect (combobox enumerates the wrong dimension). Either way, a corrected example plus an explicit statement of which dimension is the point sequence vs. the record/stride dimension would prevent others from hitting this. Two separate 1-D arrays for Data X and Data Y work correctly and are unaffected.
Last updated: 2026-08-14

Post by kuegerls on PROFINET Controller SL: WRREC remains BUSY forever, no DCE/RPC packets transmitted (RevPi Connect 5 + NORD SK205E) ^{CODESYS Forge} ^talk ^(Post)
Hello , I am currently evaluating the CODESYS PROFINET Controller SL on a Revolution Pi Connect 5 and have encountered a problem with acyclic PROFINET Record Access (WRREC/RDREC). System Hardware: Revolution Pi Connect 5 Runtime: CODESYS Control 4.16.0.0 (SDK 3.5.21.10) Development System: CODESYS V3.5 SP21 (64-bit) CommFB: 3.5.17.10 ProfinetCommon: 4.6.0.0 PROFINET Controller Device: PN-Controller 4.6.0.0 PROFINET Device: NORD DRIVESYSTEMS SK205E with SK TU4-PNT GSDML: GSDML-V2.46-NORDDRIVESYSTEMS-PNT-20251016.xml Network The PROFINET network is completely separated from the office network. RevPi: eth0 → Office network eth1 → PROFINET wlan0 → Visualization The PN Controller is configured to use eth1. IP configuration: RevPi (eth1): 192.168.100.1/24 NORD Drive: 192.168.100.3 Connection is established successfully. Current Status The PN Controller reports: Controller Status = Run Online = TRUE IP Active = TRUE Connections = 1 Cyclic PROFINET IO communication works correctly. Problem I am trying to access PKW parameters via WRREC (Record Index 100). The request buffer contains: 01 14 00 04 92 00 00 00 00 00 00 which corresponds to Reference = 0x01 Request = Read Axis = 0 Parameter = 170 + 1000 Subindex = 0 Value = 0 The WRREC call is fbWRREC( REQ := xWrReq, ID := ConnectionID, INDEX := 100, LEN := 11, RECORD := ADR(TxBuffer) ); REQ is pulsed for one PLC cycle only. Observed Behaviour WRREC enters BUSY state and never finishes. Observed values: BUSY = TRUE DONE = FALSE ERROR = FALSE STATUS = 16#FFFFFFFF indefinitely. Packet Capture A Wireshark capture was taken on the PROFINET network. Observed traffic: PROFINET RT LLDP DCP Observed: successful cyclic IO Not observed: DCE/RPC Record Write Record Read RPC Bind No RPC packets are transmitted at all. Diagnostic Messages The controller repeatedly reports AR alarm.ind(err) AR CMI timeout although cyclic IO communication continues to work. Already Verified The following points have already been checked: correct Ethernet interface (eth1) correct CREATE_ID result correct Device ID correct Slot/Subslot correct GSDML correct REQ pulse RECORD buffer is larger than LEN cyclic IO communication works different Record Indices (100...104) tested Question Is there any known issue or limitation where WRREC/RDREC requests remain permanently BUSY and no RPC Record Access packets are generated? Could this behaviour be related to Runtime 4.16.0.0, PN Controller 4.6.0.0, the missing runtime license (currently running in demo mode), or any known issue with the PROFINET Controller SL? I am currently evaluating the PROFINET Controller SL and therefore the runtime is operating in demo mode. Could you please confirm whether WRREC/RDREC (acyclic Record Data services) are fully supported in demo mode, or whether a valid license is required for these services? If required, I can provide: complete project archive Wireshark capture (.pcap) GSDML online screenshots diagnostic log Thank you very much for your help. Best regards, Stefan
Last updated: 2026-07-17

Post by thejesh on WebVisu: switch-frame destroys and rebuilds referenced visualization - is retention configurable? ^{CODESYS Forge} ^talk ^(Post)
Hi, HTML5 Conrtrol elements on CODESYS V3.5 SP22 Patch 2, WebVisu only (no TargetVisu). The client is Chromium 147 in kiosk mode on a Raspberry Pi CM5 panel; the runtime is CODESYS Control Win V3 x64/CODESYS Control RTE V3 x64 on a separate IPC. I have measured that changing a Frame element's switch-frame variable destroys the currently referenced visualization and fully rebuilds it on return, including all embedded HTML5 controls. We would like to know whether this lifecycle is configurable. Measurement 1: Curently, our production page contains a good number of custom HTML5 controls and will only increase , each of which the WebVisu client instantiates as a separate about:srcdoc iframe. I counted live targets via the Chromium remote debugging endpoint (curl http://localhost:9222/json/list) before and after switching. Production displayed (index 0) 108 iframes Switched to a light page (index 1) 46 iframes Switched back to Production 108 iframes 62 controls are destroyed on leaving the page and re-instantiated on return. Observed latency was approximately 2.5 -5s away from the heavy page and approximately 4.0 -5 s back to it. This was measured with the panel otherwise idle: 2.8% system CPU, 97.1% idle, 2 h 56 min uptime, no remote-desktop session running, hardware acceleration confirmed active in chrome://gpu. I had previously measured the same behaviour under a much higher CPU load and have since resolved that load separately (VISU_TASK cycle period), so I am confident the rebuild is the frame lifecycle itself and not CPU starvation. Measurement 2 — frame offset instead of switch index I then displayed the same overlay page by a different mechanism. Instead of using a switch-frame index, I placed the page in a fixed Frame parked off-screen below the visible canvas, and drive its Y offset from an INT in Structured Text to move it into view. With this approach the overlay appears immediately, the production page underneath is never torn down and keeps updating, and no visualization is destroyed or rebuilt in either direction. The iframe count does not change at any point. This is the same visualization, containing the same HTML5 controls, as in Measurement 1 — the only difference is how it is brought on screen. So the rebuild appears to be a property of the switch-frame mechanism specifically, not of the page or its control count. Questions: Is the destroy-and-rebuild behavior on switch-frame the intended and documented lifecycle for WebVisu? Is there any setting, property or client option that causes a referenced visualization to remain instantiated when it is not the active index — the equivalent of keeping it mounted but not displayed? Does the runtime or client offer any form of caching or pre-instantiation for referenced visualizations, so that a return switch does not pay the full construction cost? Is the cost specific to HTML5 controls, or would the same rebuild occur with an equivalent number of native visualization elements? We ask because it would inform whether reducing our HTML5 control count is a viable solution. Is there a recommended pattern for showing a full-screen page over a live production screen without tearing the production screen down? My current workaround is to keep every page permanently instantiated and move it on and off screen by driving a frame offset variable, which avoids the rebuild entirely but means every page stays live and consumes client resources for the life of the session. This works, but I would prefer to use the supported mechanism if one exists. Any help on this is greatly appreciated. Thank you!
Last updated: 2026-08-07

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

Post by mogam on Internal error:System.NullReferenceException: The object reference was not set to an object instance. ^{CODESYS Forge} ^talk ^(Post)
Hi everyone, I have a my App that reads values from a shared memory than 2 variables x,y were calculated. here as you can see in my code: PROGRAM PLC_PRG VAR szName : STRING := '/SM'; ( Name of the shared memory.) uxiSize : __UXINT := 646 * 2 * SIZEOF(REAL); ( Size of the shared memory. ) hShm : RTS_IEC_HANDLE; ( Handle to the shared memory ) pStart : POINTER TO REAL; ( Pointer to the first element in the memory ) pData : POINTER TO REAL; ( Pointer, which is incremented until the last sign in the memory is reached. ) shared_data :ARRAY[0..645, 0..1] OF REAL; velocity : ARRAY[0..2] OF REAL; ( Velocity array ) position : ARRAY[0..2] OF REAL; ( Position array ) angleDepth : ARRAY[0..645, 0..1] OF REAL; ( Angle and depth array ) xEndOfMemory : BOOL; x : ARRAY[0..645] OF REAL := 1.0; y : ARRAY[0..645] OF REAL := 1.0; (* Result of actions at the memory. *) OpenResult : RTS_IEC_RESULT; ReadResult : RTS_IEC_RESULT; PointerResult : RTS_IEC_RESULT; DeleteResult : RTS_IEC_RESULT; CloseResult : RTS_IEC_RESULT; i : INT; END_VAR ( Open the shared memory ) hShm := SysSharedMemoryOpen2(szName, 0, ADR(uxiSize), ADR(OpenResult)); IF hShm <> RTS_INVALID_HANDLE THEN (* Read the entire shared memory table *) SysSharedMemoryRead(hShm:= hShm, ulOffset:= 0, pbyData:= ADR(shared_data), ulSize:= uxiSize, pResult:= ADR(ReadResult)); (* Fetch the pointer from the shared memory. The pointer is pointing to the first element address *) //pStart := SysSharedMemoryGetPointer(hShm, ADR(PointerResult)); (* Close the shared memory *) //CloseResult := SysSharedMemoryClose(hShm := hShm); (* Read velocity and position data from the shared memory *) FOR i := 0 TO 2 DO velocity[i] := shared_data[i, 0]; position[i] := shared_data[i, 1]; END_FOR; (* Read angle and depth data from the shared memory *) FOR i := 0 TO 645 DO angleDepth[i, 0] := shared_data[(i + 6), 0]; angleDepth[i, 1] := shared_data[(i + 6), 1]; END_FOR; FOR i := 0 TO 645 DO x[i] := angleDepth[i, 1]*COS(angleDepth[i, 0]); y[i] := angleDepth[i, 1]*SIN(angleDepth[i, 0]); END_FOR; END_IF For these values an XY-CHART needs to be done and when i create a visualisation and set the x data and y data when i try to compile, i recieve this error: ------ Übersetzungslauf gestartet: Applikation: Device.Read_App ------- Code typisieren ... [FEHLER] Internal error:System.NullReferenceException: Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt. bei _3S.CoDeSys.LanguageModelManager.LDateType.Accept(ITypeVisitor typvis) bei ..(_IVariable , IScope5 , _ICompileContext , _ISignature ) bei ..(_ISignature , IScope5 , _ICompileContext ) bei ..(_ISignature , _IPreCompileContext ) bei ..( ) bei ..(String ) bei ..(String , IVariable[]& , ISignature[]& ) bei ..(String , IVariable[]& , ISignature[]& , IScope& ) bei ..visit(_IVariableExpression , AccessFlag ) bei ..(_IUserdefType ) bei ..(_IVariable , IScope5 , _ICompileContext , _ISignature ) bei ..(_ISignature , IScope5 , _ICompileContext ) bei ..(_ISignature , _IPreCompileContext ) bei ..( ) bei ..(String ) bei ..(String , IVariable[]& , ISignature[]& ) bei ..(String , IVariable[]& , ISignature[]& , IScope& ) bei ..visit(_IVariableExpression , AccessFlag ) bei ..(_IUserdefType ) bei ..(_IVariable , IScope5 , _ICompileContext , _ISignature ) bei ..(_ISignature , IScope5 , _ICompileContext ) bei ..(_ISignature , _IPreCompileContext ) bei ..( ) bei ..(String ) bei ..(String , IVariable[]& , ISignature[]& ) bei ..(String , IVariable[]& , ISignature[]& , IScope& ) bei ..visit(_IVariableExpression , AccessFlag ) bei ..(_IUserdefType ) bei ..(_IVariable , IScope5 , _ICompileContext , _ISignature ) bei ..(_ISignature , IScope5 , _ICompileContext ) bei ..(_ISignature , _IPreCompileContext ) bei ..( ) bei ..(String ) bei ..(String , IVariable[]& , ISignature[]& ) bei ..(String , IVariable[]& , ISignature[]& , IScope& ) bei ..visit(_IVariableExpression , AccessFlag ) bei ..(_IUserdefType ) bei ..(_IArrayType ) bei ..(_IPointerType ) bei ..(_IVariable , IScope5 , _ICompileContext , _ISignature ) bei ..(_ISignature , IScope5 , _ICompileContext ) bei ..(_ISignature , _IPreCompileContext ) bei ..( ) bei ..(String ) bei ..(String , IVariable[]& , ISignature[]& ) bei ..(String , IVariable[]& , ISignature[]& , IScope& ) bei ..visit(_IVariableExpression , AccessFlag ) bei ..(_IUserdefType ) bei ..(_IPointerType ) bei ..(_IVariable , IScope5 , _ICompileContext , _ISignature ) bei ..(_ISignature , IScope5 , _ICompileContext ) bei ..(_ISignature , _IPreCompileContext ) bei ..( ) bei ..(String ) bei ..(String ) bei ..(_ISignature , IScope5 , _ICompileContext ) bei ..(_ISignature , IScope5 , _ICompileContext ) bei ..(_ISignature , _IPreCompileContext ) bei ..( ) bei ..(String ) bei ..(String ) bei ..(_ISignature , IScope5 , _ICompileContext ) bei ..(_ISignature , IScope5 , _ICompileContext ) bei ..(_ISignature , _IPreCompileContext ) bei ..( ) bei ..(String ) bei ..(String ) bei ..(_ISignature , IScope5 , _ICompileContext ) bei ..(_ISignature , _IPreCompileContext ) bei ..( ) bei ..(String ) bei ..(String , IVariable[]& , ISignature[]& ) bei ..(String , IVariable[]& , ISignature[]& , IScope& ) bei ..visit(_IVariableExpression , AccessFlag ) bei ..(_IUserdefType ) bei ..(_IVariable , IScope5 , _ICompileContext , _ISignature ) bei ..(_ISignature , IScope5 , _ICompileContext ) bei ..(_ISignature , _IPreCompileContext ) bei ..( ) bei ..(String ) bei ..(String , IVariable[]& , ISignature[]& ) bei ..(String , IVariable[]& , ISignature[]& , IScope& ) bei ..visit(_IVariableExpression , AccessFlag ) bei ..(_IUserdefType ) bei ..(_IVariable , IScope5 , _ICompileContext , _ISignature ) bei ..(_ISignature , IScope5 , _ICompileContext ) bei ..(_ISignature , _IPreCompileContext ) bei ..( ) bei ..(String ) bei ..(String , IVariable[]& , ISignature[]& ) bei ..(String , IVariable[]& , ISignature[]& , IScope& ) bei ..visit(_IVariableExpression , AccessFlag ) bei ..(_IUserdefType ) bei ..(_IPointerType ) bei ..(_IVariable , IScope5 , _ICompileContext , _ISignature ) bei ..(_ISignature , IScope5 , _ICompileContext ) bei ..(_ISignature , _IPreCompileContext ) bei ..( ) bei ..(String ) bei ..(String ) bei ..(_ISignature , IScope5 , _ICompileContext ) bei ..(_ISignature , IScope5 , _ICompileContext ) bei ..(_ISignature , _IPreCompileContext ) bei ..( ) bei ..(String ) bei ..(String ) bei ..(_ISignature , IScope5 , _ICompileContext ) bei ..(_ISignature , _IPreCompileContext ) bei ..( ) bei ..(String ) bei ..(String , IVariable[]& , ISignature[]& ) bei ..(String , IVariable[]& , ISignature[]& , IScope& ) bei ..visit(_IVariableExpression , AccessFlag ) bei ..(_IUserdefType ) bei ..(_IVariable , IScope5 , _ICompileContext , _ISignature ) bei ..(_ISignature , IScope5 , _ICompileContext ) bei ..(_ISignature , _IPreCompileContext ) bei ..( ) bei ..(String ) bei ..(String , IVariable[]& , ISignature[]& ) bei ..(String , IVariable[]& , ISignature[]& , IScope& ) bei ..visit(_IVariableExpression , AccessFlag ) bei ..(_IUserdefType ) bei ..(_IVariable , IScope5 , _ICompileContext , _ISignature ) bei ..(_ISignature , IScope5 , _ICompileContext ) bei _3S.CoDeSys.Compiler35140.Compiler.(_ICompileContext , _IPreCompileContext , _ICompileContext , IProgressCallback ) bei _3S.CoDeSys.Compiler35140.Compiler.(_ICompileContext , Boolean , Boolean , _IPreCompileContext , _IPreCompileContext , _ICompileContext , Boolean , Boolean& , IProgressCallback ) bei _3S.CoDeSys.Compiler35140.Compiler.(Guid , Boolean , Boolean , Boolean , Boolean& , _ICompileContext& , _ICompileContext& , IProgressCallback , Boolean , Boolean ) Kompilierung abgeschlossen -- 1 Fehler, 0 Warnungen Übersetzung abgeschlossen -- 1 Fehler, 0 Warnungen : Kein Download möglich!
Last updated: 2024-05-24

<< < 1 .. 57 58 59 60 61 62 > >> (Page 59 of 62)

Sort by relevance or date

Forums

Help

Search talk: ST IF

Forums

Help

Search talk: ST IF

Searching