Post by mubeta on Some 'pathetic' errors in SoftMotion program ^{CODESYS Forge talk (Post)}
Yes, this is the error the sometimes show up. What make me crazy is the fact that it happens randomly and not each times. I know very well where the problem is, in wich one program row it's located. For each actions of the state machine I have all events recorded with log on text file. it is not problematic for me to find the application point of the fault, but I need to understand why occasionally and for no apparent reason, switching the state machine and thus changing the motion FB, sends the axis into failure (but only occasionally). For example, one case that is often problematic is the execution of the Axis Halt instruction. When, after a MoveAbosulte instruction this returns the event as 'done' and indeed the axis is in standstill, the state machine first sets the move instruction to FALSE, and the next cycle sets the Halt request to TRUE. Some of the time everything works out fine. Occasionally, however, in this exchange, the axis goes into fault, also losing the OPERATIONAL state. Meanwhile, I would like to understand why the motion FB instances must still be called even after the Execute is set to FALSE, especially in view of the fact that the next instruction is programmed to abort the previous one, with BufferMode set to 'Aborting'. All these unnecessary FB calls are an unnecessary overhead on the CPU anyway. Is there any precise rule about when to cease calling the various instances? (It should precisely be the 'done' status that says this one has finished its work).
Last updated: 2024-07-18

Post by tk096 on Some 'pathetic' errors in SoftMotion program ^{CODESYS Forge talk (Post)}
Meanwhile, I would like to understand why the motion FB instances must still be called even after the Execute is set to FALSE, especially in view of the fact that the next instruction is programmed to abort the previous one, with BufferMode set to 'Aborting'. All these unnecessary FB calls are an unnecessary overhead on the CPU anyway. Is there any precise rule about when to cease calling the various instances? (It should precisely be the 'done' status that says this one has finished its work). In general: - Motion function blocks have to be called until they report 'Done', 'Error', 'CommandAborted' or a subsequent motion FB with BufferMode=Aborting is started in the current cycle. - Setting the Execute input to FALSE will not abort any ongoing motion of the motion function block. For example, one case that is often problematic is the execution of the Axis Halt instruction. When, after a MoveAbosulte instruction this returns the event as 'done' and indeed the axis is in standstill, the state machine first sets the move instruction to FALSE, and the next cycle sets the Halt request to TRUE. Some of the time everything works out fine. Occasionally, however, in this exchange, the axis goes into fault, also losing the OPERATIONAL state. I think the error SMC_FB_WASNT_CALLED_DURING_MOTION is only a follow-up (and misleading) error that results from the axis not being in operational state anymore (bus problems). Is there an error 'regulator or start not set' in the device log before the error 'motion generating FB wasn't called for at least one cycle'? Which error does the respective function block (Halt.ErrorId) report?
Last updated: 2024-07-22

Post by fmon on Modbus : dis- / re-connect cable: modbus does not re-start ^{CODESYS Forge talk (Post)}
Hello, I am using codesys Modbus TCP client (4.4.0.0) to communicate with a python modbus server (package pyModbusTCP). I first start my python server on the distant machine. After a fresh codesys compilation, a plc connection/transfer and a PLC run, the modbus connection is OK. Every time in this context the connection is created correctly. When I shut down the server, the modbus connection falls, that is normal. When I restart the python server, impossible to recreate the modbus connexion. With the client autoreconnection, I see on my server that the client tries to connect but unsuccesfully. I have the following message : DEBUG:pyModbusTCP.server:accept new connection from ClientInfo(address='192.168.1.20', port=33476) DEBUG:pyModbusTCP.server:Exception during request handling: NetworkError('recv return null') I tried to stop the codesys client and to restart it with these commands : Modbus_TCP_Client.xStop := True; // Or False Modbus_TCP_Client.Enable := True; // Or False Modbus_TCP_Server.Enable := True; // Or False I tried to confirm the error manually to force reconnection with: Modbus_TCP_Server_Motors.xConfirmError := TRUE; I tried also this command to STOP/RESET/START client and server (codesys side) but nothing happens : status_client := Modbus_TCP_Client.SetCommunicationState(eRequestedState := DED.DEVICE_TRANSITION_STATE.STOP); // .RESET & .START The answer of this function when executed is "status_client = NOT_SUPPORTED" It seems that is a socket problem, but I do not understand if it is on the client or server side. I tried a modbus simulator called "ananas.exe" and the result is the same. Impossible to get a modbus reconnection. What is different at the first connection and at a reconnection attempt ? Thanks for your help
Last updated: 2025-03-14

Post by fmon on Modbus TCP client reconnection problem ^{CODESYS Forge talk (Post)}
Hello, I am using codesys Modbus TCP client (4.4.0.0) to communicate with a python modbus server (package pyModbusTCP). I first start my python server on the distant machine. After a fresh codesys compilation, a plc connection/transfer and a PLC run, the modbus connection is OK. Every time in this context the connection is created correctly. When I shut down the server, the modbus connection falls, that is normal. When I restart the python server, impossible to recreate the modbus connexion. With the client autoreconnection, I see on my server that the client tries to connect but unsuccesfully. I have the following message : DEBUG:pyModbusTCP.server:accept new connection from ClientInfo(address='192.168.1.20', port=33476) DEBUG:pyModbusTCP.server:Exception during request handling: NetworkError('recv return null') I tried to stop the codesys client and to restart it with these commands : Modbus_TCP_Client.xStop := True; // Or False Modbus_TCP_Client.Enable := True; // Or False Modbus_TCP_Server.Enable := True; // Or False I tried to confirm the error manually to force reconnection with: Modbus_TCP_Server_Motors.xConfirmError := TRUE; I tried also this command to STOP/RESET/START client and server (codesys side) but nothing happens : status_client := Modbus_TCP_Client.SetCommunicationState(eRequestedState := DED.DEVICE_TRANSITION_STATE.STOP); // .RESET & .START The answer of this function when executed is "status_client = NOT_SUPPORTED". Is it normal ? It seems that is a socket problem, but I do not understand if it is on the client or server side. I tried a modbus simulator called "ananas.exe" and the result is the same. Impossible to get a modbus client reconnection. What is different at the first client connection and at a reconnection attempt ? Thanks for your help
Last updated: 2025-03-17

Post by serwis on Dynamic target position tracking ^{CODESYS Forge talk (Post)}
Hello, I am trying to control a servo drive and dynamically set its position. I control the drive via EtherCAT with a cycle time of 500us. I use the MC_MoveAbsolute block for this. The problem is that when using a PID controller, I generate the positions I want the drive to move to on an ongoing basis, and I would like the position to be set immediately. The MC_MoveAbsolute block must receive a rising edge to execute, and I would like the movement to be performed without waiting for this edge. I have created a function that generates a rising edge every 1 ms, but I am unable to change this time to 500 µs because the TON function does not support times shorter than 1 ms. Below is the code to call the rising edge: IF Exe = TRUE THEN delay1(IN:=TRUE, PT:=T#1MS); IF delay1.Q = TRUE THEN Exe := FALSE; delay1(IN:=FALSE); END_IF END_IF IF Exe = FALSE THEN delay(IN:=TRUE, PT:=T#1MS); IF delay.Q = TRUE THEN Exe := TRUE; delay(IN:=FALSE); END_IF END_IF END_IF Here is the code for calling the MC_MoveAbsolute function: MoveDegree( Axis:= Tilt, Execute:= Exe, Position:= position_target - (base_angle_real * feedforward_turn), Velocity:= vel, Acceleration:= acc, Deceleration:= dec, Jerk:= jerk, Direction:= MC_DIRECTION.shortest, BufferMode:= MC_BUFFER_MODE.Aborting, Done=> , Busy=> , Active=> , CommandAborted=> , Error=> , ErrorID=> ); I realize that there are probably better methods for performing this type of task. How can I implement motion with a dynamically changing setpoint? THANKS
Last updated: 2025-09-05

Post by westcountryewe on ac_persistence not working when creating a Boot Application but works with a Direct Download to the PLC ^{CODESYS Forge talk (Post)}
I am using V3.5 SP18 Patch 5. I have noticed that when I Create a Boot Application from CODESYS, and upload this to my PLC via a USB stick the AC_Persistence does not work and none of my values that are in my PersistenceChannel are retained. However, if I connect direct to my PLC and I perform a direct download of my CODESYS program, my values that are in my PersistenceChannel are retained and work as they should. This makes me wonder if there are files that are missing when a Boot Application is created. I have tried taking a backup of my configuration files after performing a direct download, which gives me the plclog.zip folder, and appears to have the ac_persistence folder present within the file structure, however when I replace the plclogic.zip with the same folder that was created when I created a Boot Application, it still does not work but I wonder whether this is because the ac_persistence folder isn't stored in the correct location for reading. The .app and .crc files are embedded within the plclogic.zip folder, which obviously when uploading need to be standalone files in the root directory of the USB, so the intention there is clearly to extract the .app and .crc files and put them into the correct location within the USB. I wonder if it could be the same for the ac_persistence folder? I have tried moving it to different locations but none have worked. Has anybody else discovered a fix for this? I know the short-term solution is to do a direct download to the PLC but there are some logistical reasons why this isn't neccesarily the best solution for us.
Last updated: 2024-02-27

Post by testlogic on Sending Sequential Modbus TCP Packets ^{CODESYS Forge talk (Post)}
I have a Modbus TCP slave device where I need to do sequential writes to the same register. The register I'm writing to is kind of like a command line, each packet is a command word encoded in Hexadecimal. I am having difficulty implementing this system in CoDeSys 3.5 SP19. I feel like the structure of the program should be something along the lines of (Pseudocode): ModbusTCPSend(Command Register, Command1) ModbusTCPSend(Command Register, Command2) ModbusTCPSend(Command Register, Command3) I have tried to implement this with a rising edge trigger wMot1OPCode := 16#E1; //Stop Motor & Kill Program xMot1SendOP := TRUE; //Send OP on rising edge xMot1SendOP := FALSE; //Reset wMot1OPCode := 16#9E; //Disable Motor xMot1SendOP :=TRUE; //Send OP on rising edge xMot1SendOP := FALSE; //Reset Where "wMot1OPCode" is the IO map for writing to the command register, and "xMot1SendOP" is the rising edge trigger for that modbus channel. However, this doesn't work. The device never responds to the modbus commands. It seems like the trigger variable is switched too quickly for modbus to send the packet. I know the modbus register is working, because I can set the channel to cyclic and the device will respond. However, I can't use this reliably because I need each command to be sent once, in order. Cyclic keeps re-sending the commands and seems like it could miss a command as well if one was sent in-between cycle time. I have also trying using the Application trigger as described by https://faq.codesys.com/pages/viewpage.action?pageId=24510480, but this is also not working for me. See attached picture for my FBD code. This seems like a simple function, I can't tell what I'm doing wrong here. Thanks for the help.
Last updated: 2024-03-06

Post by thierry-b on Blocking UDP ports 1740–1743 and 22350 to disable CODESYS network scan (startup + device discovery) ^{CODESYS Forge talk (Post)}
Hello, I am currently investigating the network behavior of CODESYS 3.5 (IDE + Gateway) in environments where the engineering workstation is connected to a very large /16 network. In such networks, the automatic device scan performed at IDE startup (and the manual “Scan Network” device discovery) can cause significant delays or freezes, due to the broadcast‑based discovery mechanism. After analyzing the traffic with Wireshark, I identified that the IDE uses the following UDP ports: 1740 – broadcast discovery 1741 – handshake / responses 1742 – fallback discovery 1743 – fallback handshake 22350 – additional runtime / gateway communication (WAGO, debug, extended discovery) To prevent the IDE from scanning the large /16 network, I tested blocking these ports in both directions (IN/OUT) on the network interface connected to the /16 segment (while keeping them open on the OT /24 network interface). Result: When UDP 1740, 1741, 1742 and 1743 are blocked on the IT interface, the IDE no longer sends any discovery traffic on that interface. The IDE still works normally on the OT interface (device discovery, online mode, download, etc.). Blocking port 22350 does not seem required to stop the scan, but I included it for completeness. My question: => Can you confirm that blocking UDP ports 1740, 1741, 1742, 1743 (and optionally 22350) on a specific network interface is a valid and supported way to completely disable the CODESYS IDE network scan on that interface (both at startup and during manual device discovery)? I am not trying to block communication with controllers on the OT network — only to prevent the IDE from scanning the large /16 IT network. Any confirmation or additional technical details about the discovery mechanism would be greatly appreciated. Thank you.
Last updated: 2026-03-31

Post by wold on CodeMeter Network Server: Keep runtime dongle local-only and export only a second CmStick ^{CODESYS Forge talk (Post)}
Hello, I am running a CODESYS Control Runtime on a Raspberry Pi. Two CmSticks are connected to the same system: CmStick A - Runtime license - MultiCore license - KNX license CmStick B - Engineering / Developer licenses My goal is: The runtime on the Raspberry Pi shall use CmStick A locally. Licenses from CmStick A shall NOT be provided by the CodeMeter Network Server. Only licenses from CmStick B shall be available to remote network clients. During troubleshooting I observed that the CodeMeter Network Server collects licenses from both CmSticks. The KNX license appears to be local-only, but the runtime and multicore licenses of the same dongle are still visible through the server. I would like to know if a supported configuration exists for the following scenario: One CmStick remains strictly local to the runtime. A second CmStick on the same machine is exported through the CodeMeter Network Server. Questions: Is it possible to exclude a specific CmStick from being exported by the CodeMeter Network Server? Can this be configured via License Access Permissions (ACL), WebAdmin, or another mechanism? Can export rules be applied per CmStick, per Firm Code, or per Product Code? If supported, could you provide a configuration example or a reference to the relevant documentation? The reason for asking is that after removing a separately installed CodeMeter server component and returning to a local-only setup, the runtime licensing behaviour became stable again. Therefore I am looking for the officially supported way to keep the runtime dongle local while still providing engineering licenses from a second dongle over the network. Thank you.
Last updated: 2026-08-02

Post by olehmann03 on PFC200 - WAGO 750-8202 - MODBUS RTU ^{CODESYS Forge talk (Post)}
Hello, I’m working on implementing Modbus RTU communication with a Carel controller (CPCO). I want to use the front RS485 interface through the DB9 connector. The issue is that I can’t get the communication working correctly. Below are the steps I’ve done so far: Connected pins 3 and 8 from the DB9 connector to the +/- RX/TX terminals on the Carel side. In the PLC shell, I set serialmode to RS485. In WBM under Administration > Serial Interface > Assign owner of serial interface, I set the port to unassigned. In the device tree, I created Modbus_COM with the following settings: COM port: 1 Baud rate: 19200 Parity: None Stop bits: 1 Created a Modbus client on this COM interface in RTU mode. Under the status tab, I can see it is in running state. On the client, I created a Modbus server and set the Modbus address of my unit to 1. Defined a few channels as FC03 to read holding registers according to the Carel register map. I checked the communication with the Carel controller using a USB-to-RS485 converter connected to my PC, and communication works correctly there. In the status tab, I can see that the Modbus server is polling, but there is no response from the controller. I also tried multiple times swapping A/B lines on the Carel side, but it did not help. Do you have any suggestions on what else I should check?
Last updated: 2026-05-22

Post by olehmann03 on PFC200 - WAGO 750-8202 - MODBUS RTU ^{CODESYS Forge talk (Post)}
Hello, I’m working on implementing Modbus RTU communication with a Carel controller (CPCO). I want to use the front RS485 interface through the DB9 connector. The issue is that I can’t get the communication working correctly. Below are the steps I’ve done so far: Connected pins 3 and 8 from the DB9 connector to the +/- RX/TX terminals on the Carel side. In the PLC shell, I set serialmode to RS485. In WBM under Administration > Serial Interface > Assign owner of serial interface, I set the port to unassigned. In the device tree, I created Modbus_COM with the following settings: COM port: 1 Baud rate: 19200 Parity: None Stop bits: 1 Created a Modbus client on this COM interface in RTU mode. Under the status tab, I can see it is in running state. On the client, I created a Modbus server and set the Modbus address of my unit to 1. Defined a few channels as FC03 to read holding registers according to the Carel register map. I checked the communication with the Carel controller using a USB-to-RS485 converter connected to my PC, and communication works correctly there. In the status tab, I can see that the Modbus server is polling, but there is no response from the controller. I also tried multiple times swapping A/B lines on the Carel side, but it did not help. Do you have any suggestions on what else I should check?
Last updated: 2026-05-22

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)}
Setup: Net Base Services (NBS), TCP_Client + TLSContext, ePurpose := CLIENT_SIDE, connecting to a third-party embedded device (Velux KLF200 home automation gateway) whose factory-installed TLS certificate expired on 2026-07-12 and has no user-facing renewal path. Tested on both CODESYS Control for Raspberry Pi SL (3.5.19.0) and CODESYS Control Win V3 x64, with identical results on both. Goal: Accept the peer's expired certificate via a custom ICertificateVerifier implementation, since the certificate itself can never be replaced. Implementation: FUNCTION_BLOCK FB_MyCertVerifier IMPLEMENTS NBS.ICertificateVerifier VAR udiCallCount : UDINT; aeCurStateLog : ARRAY[0..9] OF NBS.RTS_IEC_RESULT; END_VAR METHOD VerifyCertificate : UDINT VAR_INPUT hCert : NBS.RTS_IEC_HANDLE; eCurState : NBS.RTS_IEC_RESULT; END_VAR IF udiCallCount < 10 THEN aeCurStateLog[udiCallCount] := eCurState; END_IF udiCallCount := udiCallCount + 1; VerifyCertificate := 0; // also tried: VerifyCertificate := eCurState; Wired in via tlsContext.itfCertVerifer := certVerifier at declaration time, alongside itfTLSContext := tlsContext set at TCP_Client's own declaration (per an earlier forum thread here on ensuring inline start-values on FB-typed variables are actually honored when nested one level deep - that fix was needed and worked correctly for getting the handshake to start at all). Observed: - VerifyCertificate is confirmed called exactly once per connection attempt (via the call counter above). - eCurState passed in = 0x709 = ERR_CERT_HAS_EXPIRED - correctly reflecting the actual state of the peer's certificate. - Packet capture confirms the full TLS 1.2 handshake completes correctly at the wire level: ClientHello -> ServerHello -> Certificate -> ServerKeyExchange -> ServerHelloDone -> our ClientKeyExchange/ChangeCipherSpec/Finished -> server's ChangeCipherSpec/Finished. Both sides successfully complete the cryptographic handshake. - Despite this, TCP_Client.Upgrade() subsequently returns NBS.ERROR.CONNECTION_ERROR, and the connection is torn down with a plain TCP FIN (not a TLS alert) roughly 7-8ms after our side ACKs the server's Finished message. - TCP_Client.eErrorID (inherited from LCon) remains NO_ERROR throughout - the failure is only visible via Upgrade()'s return value. - Returning 0 (ERR_OK/ERR_CERT_OK - confirmed via the CmpErrors2 Interfaces documentation that these are literally the same value) makes no difference. - Echoing eCurState back unchanged (on the theory that this callback might work like mbedTLS's native verify callback, where the incoming state is a flags value to be cleared/modified and returned, rather than paired with a separate fixed "accept" sentinel) also makes no difference. - Identical result across udiVerificationMode := 0, 1, and 2. - Importing the peer's certificate into the runtime's trusted certificate store via cert-import trusted makes no difference either. - With itfCertVerifer left at its default (no custom verifier) and udiVerificationMode := 2, the underlying engine sends its own fatal TLS alert (handshake_failure) immediately after receiving the peer's Certificate message - suggesting built-in validation may reject at the record layer independent of whether a custom verifier is even present. Questions: 1. Is there an additional step required for a custom ICertificateVerifier to actually override an ERR_CERT_HAS_EXPIRED (or more generally, any ERR_CERT_*) rejection, or is certificate validation enforced unconditionally for a CLIENT_SIDE TLSContext regardless of what the verifier returns? 2. Is 0/ERR_OK genuinely the correct "accept" return value for VerifyCertificate, or does it expect something else (a specific bit pattern, a different constant, a value that must be computed from hCert itself)? 3. Is there a supported way to connect to a peer presenting a certificate that is both self-signed and expired, short of the peer issuing a new certificate? Happy to share the full packet captures or additional test combinations if useful. Also worth noting for anyone finding this thread later: a maintained Node-RED library for this same device (node-red-contrib-velux-klf200, forked to handle this exact expired-certificate situation) solves it by disabling built-in TLS validation entirely (rejectUnauthorized: false) and doing fingerprint-based pinning by hand after the handshake completes, rather than relying on a validation callback - which may be the more realistic approach here too if ICertificateVerifier genuinely can't override this class of rejection. Thanks in advance /Jørgen Disclosure: most of the CODESYS code and this investigation was developed with the help of Claude (Anthropic's AI assistant) - the state machine design, SLIP/checksum implementation, and debugging methodology (including the packet capture analysis) were worked through in an extended back-and-forth with it. Posting here because we've run out of self-serviceable options and this now looks like it needs input from someone with visibility into NBS's actual implementation.
Last updated: 2026-07-26

Post by rossanoparis on After un upgrade of "CODESYS Control for Raspberry Pi MC SL" from v4.7 to v4.9 SysFileOpen function stopped working ^{CODESYS Forge talk (Post)}
For those who will step on this thread. Everything is fine, I had only to increase by 1 my place holders number. For sure the system is occupying the number 1 without being declared ... Below the modification I made to get my code working. [SysFile] PlaceholderFilePath.2=/home/pi/hpca/bin, $hpcabin$ PlaceholderFilePath.3=/home/pi/hpca/cfg, $hpcacfg$ PlaceholderFilePath.4=/home/pi/hpca/logs, $hpcalogs$ PlaceholderFilePath.5=/home/pi/hpca/resources, $hpcares$
Last updated: 2023-08-22

Post by vformanek on No source code available for profinet library ^{CODESYS Forge talk (Post)}
Hello, I have been using CODESYS for a while and after updating to version 3.5.18.50 the code randomly stops with this fault. Why is that ? I have tried to locate the fault in the Call Stack but I dont know what to do now... I have updated the projects properly for the version I am using. This fault started happening after like 14 days of using the new version of CODESYS.
Last updated: 2023-08-23

Post by kreisfilho on Stop raspberry from executing a plc program ^{CODESYS Forge talk (Post)}
Hi guys, Can someone inform where in a raspberry pi are stored the codesys programs? I´ve been training the use of a RPI as PLC, which works pretty well, however while both the RPI and PC (running codesys) remain connected to the same network. The question is: how to run the codesys program downloaded to the RPI as a stand alone device (disconnected from the PC)? Thanks! Kreis
Last updated: 2023-08-23

Post by mozed on Connection to device closed ^{CODESYS Forge talk (Post)}
Hello, Exulting the command /opt/CoDeSysControl/Files/run restart debug I get this response from the linux terminal:(ScreenShot1 to ScreenShot7) When I try to reconnect via codesys this line appears at the linux terminal level:(ScreenShot8) A few seconds later, the error window appears on Codesys.(ScreenShot9) I see that following the command /opt/CoDeSysControl/Files/run restart debug there are errors, are they the problem? Sincerely,
Last updated: 2023-08-24

Post by ellcap on Symbol Configuration, I'm doing it wrong ^{CODESYS Forge talk (Post)}
if you're here because you are making the same mistake as me, I just resolved it. I mistakenly thought I didn't need to write the word attribute in the column labeled attribute. changed this 'symbol' := 'read' to this attribute 'symbol' := 'read' The last two in this clip are still wrong: I recongize this is probably a big "duh". That's ok. I like to fail out loud in hopes it helps someone else from looking silly.
Last updated: 2023-08-31

Post by macros8 on Alarm Management - latched variable represented as Text list ^{CODESYS Forge talk (Post)}
Hi all, in Alarm management you can latch some variable to show value within the alarm msg. It´s very useful sometime. But I´m wondering whether there is any possibility to represent that value as Text list. It´s quite common in other HMI tools and this is very useful in case of using some ErrorID for detail specification of error. Unfortunately I could not find any way how to do it but I believe that exists :) Thanks a lot. M.
Last updated: 2023-09-06

Post by janderson on Ethercat scan for devices not picking up EL7041 as a softmotion axis ^{CODESYS Forge talk (Post)}
it appears that the different revisions have different PDOs. I am currently trying to use the rev25. I have tried to use the rev24 (the device repository entry not from 'scan for devices') and i keep getting 'invalid output mapping' or 'invalid input mapping' in the ethercat log. I cant even get the bus to run from the device description that comes from 'scan for devices'...
Last updated: 2023-09-18

Post by janderson on Ethercat scan for devices not picking up EL7041 as a softmotion axis ^{CODESYS Forge talk (Post)}
it appears that the different revisions have different PDOs. I am currently trying to use the rev25. I have tried to use the rev24 (the device repository entry not from 'scan for devices') and i keep getting 'invalid output mapping' or 'invalid input mapping' in the ethercat log. I cant even get the bus to run from the device description that comes from 'scan for devices'...
Last updated: 2023-09-18

Post by docker on Canopen connection. Unknown node id. ^{CODESYS Forge talk (Post)}
hi, i am currently trying to adapt an i/o device for a project. the node id is unknown and there is no eds file available. no data is being emitted from the device as a giveaway, the baudrate is known but useless without the node id. is there an sdo request available to determine the id? i cannot get the device to leave pre op status even with a global nmt request. please help. no hair left.
Last updated: 2023-09-25

Post by timvh on Specify Input Configuration "OnDialogClosed" Action to only react to certain Dialogs ^{CODESYS Forge talk (Post)}
What maybe helps is the Visu Dialog ST demo project: https://store.codesys.com/en/visu-dialog-st.html This has an application IECOpenDialog where dialogs are opened using the VU.FbOpenDialogExtended function blocks. The fbOpenConfigurationDialog call has a reference (interface) to the "close listener" FB of which it's method is automatically called when the dialog is closed. This way you can create specific function blocks for each dialog when it is closed and do what you want with the data that might have been changed.
Last updated: 2023-09-28

Post by jantje on Setting up the "Visual Studio Code" debugging environment (using .NET debugging) for use with the ScriptEngine API in Python. ^{CODESYS Forge talk (Post)}
Hi Till, Sadly I did not get any feedback on this and was not able to get it to work using Visual Studio Code. I believe I have used a Codesys environment to get something up, but I cant remember any specifics, its too long ago. Good luck with it! Kind regards, Jan
Last updated: 2023-10-02

Post by martinlithlith on Raspberry Pi: List of available drivers / libraries ^{CODESYS Forge talk (Post)}
As most of the posts are moved here around 2015, what would be the right version of codesys to run? Would it be better to install a older version of codesys or should i keep on downgrading libraries? Is there any work done to update theses libraries? It´s been a few years since the last update in this post, are there new libraries/devices for raspberry being added/posted somewhere else? Thanks, Martin
Last updated: 2023-10-17

Sort by relevance or date