Post by spiessli on Softmotion axis to CANopen Maxon IDX drive ^{CODESYS Forge talk (Post)}
Just verified the behaviour. Still is the same. It should be attached here. But I also tried the DCF-file with the axis in the lab with the real drive: The MC_Power block never goes out of busy. Had not time to investigate further, though.
Last updated: 2024-01-08

Post by rkohser on Python Script for Finding "Last saved with" Value ^{CODESYS Forge talk (Post)}
Hi jkilburn, I have the exact same issue and thought I would search a solution on this forum. I see you did not get any answer, did you find a solution on how to extract the last saved version of codesys from the project file ? Roland
Last updated: 2024-01-29

Post by durstloescher on Library Documentation DocScripting ^{CODESYS Forge talk (Post)}
Hi, I am currently creating a documentation for our library with DocScripting. In the process, I noticed that Visu images are created before the merge and transform, i.e. "screenshots" of the different Visus. Unfortunately, these are not used in the later process (Merge/Transform). Is there a way to set it up so that they are found in the html file?
Last updated: 2024-02-19

Post by reinier-geers on SysFileOpen does not work after update to V3.5 SP19 Patch 5 ^{CODESYS Forge talk (Post)}
At 19.1 the hFile_test should be RTS_IEC_HANDLE and always open-write - close in one cycle udi_handle: RTS_IEC_HANDLE; //handle-number. Is created by SysFileOpen udi_handle:=SysFileOpen(sFileName,Sysfile.AM_WRITE_PLUS, ADR(udi_ErrorCode)); udi_RetValWrite:=SysFileWrite(udi_handle, pRemBuffer, szRemBufSize, ADR(udi_ErrorCode)); //closing file IF udi_RetValWrite < szRemBufSize THEN ui_Error:=cWriteError; END_IF//error writing data udi_ErrorCode_Close:=SysFileClose(udi_handle);
Last updated: 2024-02-19

Post by timvh on when going online, stuck on "Syncing file "visuelemsdatetime.tl_datetime.txt" ^{CODESYS Forge talk (Post)}
I don't know the root cause... But what could help to continue when it seems to hang, is stop the CODESYS (communication) Gateway. Go to the Windows SysTray, find the icon for the Gateway and then stop it and start it again. This will interrupt the connection between CODESYS and your controller.
Last updated: 2024-03-05

Post by nano on Error building Extension SDK Linux code ^{CODESYS Forge talk (Post)}
Hey schnepper, when i look into your c-file, i would say that only the main-function is declared with cext-addendum in your codesys-library-project. all yöur funtions in library has to be the cext-addendum when the external implementation is activ. if i remeber right, methods and other subelements dont need that, but every base-elements
Last updated: 2024-04-02

Post by danwoodlock on Rpi zero w lost license after 4.11 update ^{CODESYS Forge talk (Post)}
Just adding some info: Today I found this post: https://forge.codesys.com/forge/talk/Runtime/thread/264bd530d4/ followed the steps suggested started with a fresh install of raspbian lite, installed 4.11, and then attempted to import my license update file. I get this when I do: Any help is appreciated.
Last updated: 2024-04-15

Post by hismoon on Prüfen ob Datei existiert wenn nicht neu erstellen ^{CODESYS Forge talk (Post)}
Nur für die Nachwelt. Ja, Ressourcen wie Files sollte man optimalerweise nur aus 1 Task schreiben. Typischerweise nimmt man da eine nieder-priore, die sich um solche langsamen File- oder Logging-Geschichten kümmert. Dann gibt es auch keine Synchronisations-Probleme. Aus mehreren Tasks das zu tun braucht eben diese Synchronisation. Sonst passieren schlimme Dinge.
Last updated: 2024-06-04

Post by kporter on SoftMotion, accessing PDO input data via object ref/pointer ^{CODESYS Forge talk (Post)}
Now that SP21 is out, what's the answer? I want to get a pointer to the TxPDO and RxPDO structs. I can generate a STRUCT declaration from the ESI file with a bit of Python. I just need to get the pointer from the ETC_Slave.
Last updated: 2025-10-29

Post by kalmeyer on Stepper motor control with (SM_Drive_RaspStepper_direct) ^{CODESYS Forge talk (Post)}
I AM VERY GRATEFUL FOR YOUR HELP. I HAVE INSTALLED: CODESYS SOFTMOTION VER. 4.19.0.0 AS SEEN IN THE ATTACHED FILE. BUT IT DOESN'T CHANGE THE FACT THAT I GET 6 ERRORS WHEN I HAVE INSTALLED SM_Drive_RaspiStepper_Direct DO YOU HAVE ANY SUGGESTIONS ON WHAT I CAN DO NOW? /KLAUS
Last updated: 2025-11-10

Post by bdschnapp on OPC-UA ApplicationUri / ProductUri ^{CODESYS Forge talk (Post)}
From Codesys support: The format of the URN is always the same. It's always urn:<vendor>:<product>:OPCUA:Server. What I think you can influence the vendor and product (DeviceName) through settings in the runtime cfg file:</product></vendor> [SysTarget] VendorNameUnicode="T\00E\00S\00T\00" DeviceNameUnicode="t\00e\00s\00t\00" Note that these are 16-bit strings, thus the ASCII padded with nulls
Last updated: 2026-03-17

Post by struccc on Application failing to boot after system reboot ^{CODESYS Forge talk (Post)}
I started to experience the same issue, after upgrading to 3.5.19 , and still persists with 3.5.20.3 , using CodesysControlWinV3 x64 on Windows. Unfortunately, this is a live application, normally it is running for months without interruption - so it was a surprise at the last cold start... It was not possible to go online with the original version, so I couldn't see the application, or system status, just the log message. First time I manually clean the Application from the PlcLogic directory (there was no coredump file in there), then I could start the runtime service, and do a fresh download, and set the bootproject. I could not try a cold system reboot - it's in a 24/7 production environment, and I was under heavy pressure to start... What I did, I have created a backup from the * complete * runtime directory, from the failed, and fixed version - before and after download. This directory in my case C:\ProgramData\CODESYS\CODESYSControlWinV3x64\55096128 - At the next shutdown, it was sufficient to copy back this backup completely, and could start the runtime service afterwards. Ugly, but local staff with some skills can do it without programming tool... I don't store any live data, configuration, log files, persistent data in this directory - the only reason I need this is to edit the CodesysControl... .cfg file.... And to see the logfiles in emergencies like this. The application concerned doesn't use any retain area. - exactly for these reasons - Maybe that is causing the problem with the newer runtime versions As far as I see, this problem occurs only if the power of the Windows PLC is interrupted without a proper shutdown. Unfortunately, this can happen sometimes. The newer versions, seems tp modify CodesysControl.cfg on the fly, and register the applications, and bootproject information after download. (I don't really see CodesysControl.cfg a proper location for this... but that's just my feeling) So now I had a look at CodesysCotrol.cfg on my laptop and I found: [CmpRetain] ;Retain.SRAM.Size=0x200200 ;Retain.SRAM.Address=0xFA3C5776 ;SimulateSRAM=1 [CmpApp] ;Bootproject.CreateOnDownload=0 ;Bootproject.StoreOnlyOnDownload=0 ;Bootproject.InvalidateByRename=1 ;Bootproject.InvalidateBySetting=1 ;Bootproject.InvalidateNever=0 ;PersistentForce=0 ;RetainType.Applications=InSRAM ;RetainType.Applications=OnPowerfail ;RetainType.Applications=None ;Exception.Hardware.GlobalStop=1 Application.1=MyTestAppNoRetain The last line appeared after download and boot project creation. Maybe... Should set RetainType.Applications=None? I wonder about all these settings, but... Will write separately about it. I hope this helps a little...
Last updated: 2024-11-21

Post by peterkcontrols on TargetVisu started in windowed or not full screen ^{CODESYS Forge talk (Post)}
Thanks for the response. I have found this file in two places, I have updated the text in both but it didnt work. Am I missing something on the Codesys side. How do you restart the soft plc, I have been stopping it and starting it. The Visu screen come up but still in full screen mode. Here are the two locations of this file: C:\Program Files\Codesys Control\GatewayPLC\AppDataFiles\CODESYSControlWinV3x64 and C:\Program Files\CODESYS 3.5.20.50\GatewayPLC\AppDataFiles\CODESYSControlWinV3x64 Here is the contents of targetvisuextern.cfg [ComponentManager] [CmpTargetVisu] ; The Window... settings can be used for displaying the targetvisualization in a window instead of fullscreen WindowType=0 WindowPositionX=0 WindowPositionY=0 WindowSizeWidth=1024 WindowSizeHeight=768 HideCursorCompletely=1 [SysWindow] ;Windows.CloseOnAltF4=0 ;Windows.CloseOnWM_CLOSE=0 [CmpLog] ;Logger.0.Name=TvExtLogger ;Logger.0.Enable=1 ;Logger.0.MaxEntries=1000 ;Logger.0.MaxFileSize=5000 ;Logger.0.MaxFiles=3 ;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
Last updated: 2025-02-26

Post by pernockham on Engineering IDE from linux? ^{CODESYS Forge talk (Post)}
I have done the switch (linux mint, virtual windows through QEMU/KVM) now and is generally pleased. Have had problems in two areas initially. To bridge IP to the Virtual unit (solved), I overthought things initially. Solution. Configure manually a bridge in the mint-"network connections". Use that bridge in the Qemu settings as "Bridge device", "Device name": "name of the configured bridge" Figure out where to store the projects. I started out have the data in linux world (sort of) and linking it the windows with "virtio-fs". That had some serious impact though on git-handling. It seems that virtio-fs interpreted any file-path as lowercase only even if there were uppercase, resulting in git not able to sync files between its repository and the source code (it created a new file-path for me with only lowercase). Then I switch to samba-share instead and this works much better, though (git-actions) is a part that still has low performance with lots of waiting for file-actions. What should be the best way of handling the source/git? Edit to answer myself: Save the project "locally" in windows, then a lot of slow performance is avoided. Then a git-remote sync for backup.
Last updated: 2025-05-08

Post by dantheman on Connecting to SoftPLC Only Works By Turning Off Modbus Ethernet Port ^{CODESYS Forge talk (Post)}
I have an IPC with 2 ethernet ports and 1 Wi-Fi. I'm using ModbusTCP with the ethernet port named "enp2s0" connected to my remote I/O. This works fine when testing with Python and also works with CODESYS, but CODESYS is only able to scan for the Linux SoftPLC when I turn off the "enp2s0" interface. In other words, I can't get online with the IDE if I want my ModbusTCP comms to run with CODESYS. I'm using a Linux SoftPLC that has the following entry in CODESYSControl.cfg, hoping that this will allow me to connect with "enp1s0" or "wlp3s0", and leave "enp2s0" for field comms, but this seems to only make the source IP of the ModbusTCP comms to be bound to "enp2s0". That last point is the case only if I don't restart the service, but if I do restart the service after changing the config file, the source IP for the ModbusTCP comms then becomes the one for "enp1s0", which is very confusing to me: [SysSocket] Adapter.0.Name="enp2s0" Adapter.0.EnableSetIpAndMask=1 On the device list, I only have "enp2s0" given as the ethernet device that has the ModbusTCP master & slave beneath it, shown in Screenshot 1. On the IPC, I can ping the ModbusTCP client (remote I/O) from "enp2s0", and I've attached a Wireshark capture of running ModbusTCP from the CODESYS runtime as Screenshot 2, 3 & 4 (again, I can't get online when this is running, I have to turn off "enp2s0" to connect even when it's idle and I don't have an active TCP session with my Python tests). Like I explained above, the source IP is "enp1s0", even though the ethernet device on the project is "enp2s0". I was lucky to catch the red message that showed the source IP that makes sense to me (the one for "enp2s0"), but for some reason that connection was reset and I never saw that packet again. I've also tried this with Auto-reconnect both enabled & disabled, for the ModbusTCP Master device. I also have to turn off "enp1s0" and then turn it on, just so that I can have the ModbusTCP comms running from "enp2s0" (which is not intuitive in any way to me, I'd love some help understanding that phenomenon as well) in the weird manner that I've described above. I would be very appreciative if someone can help me figure out this pickle. I'd love to just connect to CODESYS through my Wi-Fi interface and leave my ethernet ports for field comms.
Last updated: 2024-08-01

Post by ppix on Establishing TLS Connection with MQTT Broker using MQTT Client SL Package ^{CODESYS Forge talk (Post)}
I’m currently working on establishing a TLS connection with an MQTT broker using the MQTT Client SL package in CODESYS. While I’ve successfully established communication with the broker without TLS, I'm encountering issues when trying to enable TLS. In the 'MQTT Explorer' application, I can easily upload the server certificate (.crt), client certificate (.crt), and client key (.key). However, in CODESYS, I can’t find a way to upload my client key (.key file). Here's a summary of my current setup: Certificates: I have uploaded both the client and server certificates to the certificate store under the 'Trusted Certificates' folder in the security screen. TLS Context Initialization: Despite setting the _sCommonName as the name of my client certificate, a new self-signed certificate is created and placed within the device’s certificates. I then need to manually move this certificate to the trusted certificates folder. This results in three certificates in my trusted certs folder: client cert, server cert, and the newly created cert. _ciDefaultCertInfo : MQTT.NBS.CERT_INFO := (psInfo := ADR(_sCommonName), udiSize := TO_UDINT(LEN(_sCommonName))); // CN of the certificate (common name) _sCipherList : MQTT.NBS.CIPHER_LIST := STRUCT(psList := ADR('HIGH'), udiSize := 4); // Cipher string see https://www.openssl.org/docs/man1.1.1/man1/ciphers.html _tlsContext : MQTT.NBS.TLSContext := ( sUseCaseName := _sCommonName, // A certificate is stored in the certificate store with the use case name. You can choose any name. Here we use the common name. ePurpose := MQTT.NBS.PURPOSE.CLIENT_SIDE, // For client certificates set this to NBS.PURPOSE.CLIENT_SIDE sTLSVersion := '1.3', // The TLS version sCipherList := _sCipherList, // Set the cipher list sHostname := sHostname, // The hostname of the broker udiVerificationMode := 2, // 2 => Active Peer verification ciCertInfo := _ciDefaultCertInfo, // Set the cert info itfCertVerifer := 0); // 0 => No Verifier mqttClient : MQTT.MQTTClient := (xUseTLS:=TRUE, itfTLSContext := _tlsContext, itfAsyncProperty := _asyncProperty); Additional Details: In the client FB, I’ve set uiPort:= 8883, xUseTLS:= TRUE, and configured itfTLSContext as mentioned above. The certificates are encrypted with SHA256RSA. sHostname is the IP address of my broker. I’ve attached a copy of the client FB, which shows straight lines where variables are assigned and boxes where they are not. I am currently trying this on the only 2 compatible versions of COSDESYS with my controller (V3.5.15.20 and V3.5.18.40) My Question: How do I correctly set up this mTLS connection? What might I be missing? Any guidance or suggestions would be greatly appreciated, especially considering I’ve already successfully established a non-TLS connection with the same broker. Thank you in advance for your help!
Last updated: 2024-06-19

Post by sahin6033 on DSE M840-001-02: DSEServiceTool transfers CodesysApp.pkg successfully, but device shows “No application loaded ^{CODESYS Forge talk (Post)}
Hi, I am trying to load a test application into a DSE M840-001-02 display, but after reboot the device still shows: “No application loaded” I would like to understand whether the problem is in my project, the package creation process, or firmware/runtime compatibility. Hardware Device: DSE M840-001-02 Firmware used: M840 MKII Firmware File v4.1.2 Software CODESYS V3.5 SP12 (32-bit) DSE CODESYS Package v1.5.44 DSEServiceTool What I did Created a new empty Standard Project Selected target/template: M840-02 V4.1 Used a minimal ST program only: PROGRAM PLC_PRG VAR xAlive : BOOL := TRUE; END_VAR Confirmed: project builds PLC_PRG is assigned to MainTask created Boot Application Generated CodesysApp.pkg Put the M840 into bootloader mode Sent the package using DSEServiceTool DSEServiceTool result Transfer completes successfully and I get: connection accepted 100% download package ACK <status>OK</status> ** Example log:** Searching for controllers.... sendPackageToController: waiting for incoming data connection... sendPackageToController: connection accepted... <status>Downloading</status> <percent>20</percent> <percent>40</percent> <percent>90</percent> <percent>100</percent> sendPackageToController: sent 112cb8 bytes OK Package ...\CodesysApp.pkg transferred to controller c0a80101 OK sendPackageToController: package ACK <status>OK</status> Actual result After reboot, the display still shows: “No application loaded” Additional issue I also saw earlier At one stage I also had these fatal errors in CODESYS: [FATAL ERROR] Unresolved reference: 'IOMGRLOCKENTER' [FATAL ERROR] Unresolved reference: 'IOMGRLOCKLEAVE' I checked library versions and adjusted them to: IoDrvBase = 3.5.5.0 IoStandard = 3.5.10.0 Also, I am using CODESYS SP12, which I understand is the correct version for DSE M840. My questions If DSEServiceTool shows Status OK and package ACK, but the device still says “No application loaded”, does that mean: the .pkg was transferred but not accepted as a valid application? the package was built incorrectly? the boot application / runtime / firmware versions are still mismatched? What is the correct procedure to generate CodesysApp.pkg for M840-02 V4.1? Is there any known compatibility issue between: DSE CODESYS Package 1.5.44 M840 MKII Firmware 4.1.2 CODESYS 3.5 SP12 Has anyone successfully loaded even a minimal empty test project into M840-001-02, and if so, what exact versions/process did you use? Any help would be appreciated.
Last updated: 2026-03-17

Post by taqamert on IFM-Sensor ADC READ ^{CODESYS Forge talk (Post)}
I have a pressure sensor that measures 0-600 bar and outputs a 0-5V signal, but my PLC reads analog inputs in the 0-10V range and displays a value of 1024 when 10V is applied. In this case, when the sensor outputs 5V at 600 bar, the PLC shows a value of 512. My working range is 0-350 bar, which means the PLC only uses 298 bits in this range, significantly reducing the resolution. What can I do to achieve better resolution within the 0-350 bar range?
Last updated: 2024-08-23

Post by taqamert on IFM-Sensor ADC READ ^{CODESYS Forge talk (Post)}
I have a pressure sensor that measures 0-600 bar and outputs a 0-5V signal, but my PLC reads analog inputs in the 0-10V range and displays a value of 1024 when 10V is applied. In this case, when the sensor outputs 5V at 600 bar, the PLC shows a value of 512. My working range is 0-350 bar, which means the PLC only uses 298 bits in this range, significantly reducing the resolution. What can I do to achieve better resolution within the 0-350 bar range?
Last updated: 2024-08-23

Post by taqamert on IFM-Sensor ADC READ ^{CODESYS Forge talk (Post)}
I have a pressure sensor that measures 0-600 bar and outputs a 0-5V signal, but my PLC reads analog inputs in the 0-10V range and displays a value of 1024 when 10V is applied. In this case, when the sensor outputs 5V at 600 bar, the PLC shows a value of 512. My working range is 0-350 bar, which means the PLC only uses 298 bits in this range, significantly reducing the resolution. What can I do to achieve better resolution within the 0-350 bar range?
Last updated: 2024-08-23

Post by timvh on Unable to Connect to Modbus RTU Device ^{CODESYS Forge talk (Post)}
If your Control Win is the Modbus "Master" then your configuration should be something like: Modbus_COM (Serial port) - Modbus Master (this is the Control Win SoftPLC actively setting up the communication) - Modbus Slave (this is then your WAGO 750-315) You need to add channels to the Modbus Slave configuration to inform the master which variables to read/write from the Wago module. The way you configured it now, the Control Win is also a slave. PS, don't forget to put the PLC (Control Win) in Run.
Last updated: 2024-09-03

Post by amy123 on JSON Utilities ENUM to STRING ^{CODESYS Forge talk (Post)}
Hello, Is it possible to get the string returned from the ENUM JSONType? I read that with regular enumerations you can add '{attribute 'to_string'}' and access it. However, this is from the compiled library, so I can not add that attribute. When I try to use TO_STRING(JSONType) it returns the integer as a string. Ex. jsonType :=TO_STRING(pJSONData^._aJSONData[i].eType); gives '8' instead of NONE Thanks!
Last updated: 2024-12-09

Post by gatto on Read codesys version in the codesys application ^{CODESYS Forge talk (Post)}
hi, i used another way declaration: pApp : POINTER TO APPLICATION; pAppInfo : POINTER TO APPLICATION_INFO; ProjectName : STRING (24) ; CodesysVersion : STRING (15) ; code: //library : // CmpApp // IoDrvEthernet // // Get Pointer to current application pApp := CmpApp.AppGetCurrent( pResult:= 0 ); // Get Pointer to Application information pAppInfo := CmpApp.AppGetApplicationInfo(pApp:= pApp, pResult:= 0 ); ProjectName := pAppInfo^.pstProjectName^ ; //convert codesys version to string CodesysVersion := IoDrvEthernet.UDINT_TO_IPSTRING ( udiIPAddress := pApp^.udiPSVersion ) ; so i think you need to convert your dwVersion in a UDINT and after convert UDINT_TO_IPSTRING
Last updated: 2025-01-17

Post by rmaas on TCP Server ^{CODESYS Forge talk (Post)}
Hi George, I do not know what the problem is with the syssocket implementation, but when i read the forums it seems the Net Base Services library is the recommended way to go. There is another more extensive example here: https://forge.codesys.com/prj/codesys-example/plc-chat-nbs/home/Home/ I have just tested this example and it works very well, also with closing and opening the connection from hercules... good luck!
Last updated: 2025-02-20

Post by atone on Set DeviceID of an IO-Link Sensor at Runtime ^{CODESYS Forge talk (Post)}
I need to be able to change (set) the DeviceID of an IO-Link sensor (see DeviceID.png) at runtime. I tried with both ProfinetCommon.PN_PortConfiguration and ProfinetCommon.IOL_PortConfiguration, but I get an error for both when I try to read the port configuration (see PN_PortConfiguration.png). Does one of those FBs is the right one for my purpose? Do I possibly make a mistake when assigning the parameter IOLD_ID/IOLM_ID?
Last updated: 2025-03-19

Sort by relevance or date