| FORUM | LATEST POST | # TOPICS |
|---|---|---|
|
Engineering 🇬🇧 Discussions about the CODESYS Development System, IEC programming, CODESYS Professional Developer Edition |
Blocking UDP ports 1740–1743 and 22350 to disable CODESYS network scan (... by thierry-b 4 days ago |
5970 |
|
Runtime 🇬🇧 Related questions to SoftPLCs e.g. Raspberry Pi, Beaglebone, IoT2000 and other platforms |
Unknown Type by mait-tim 15 hours ago |
2300 |
|
Visualization 🇬🇧 Realizing operator screens with CODESYS HMI, Targetvisu, Webvisu |
WebVisu Activity Tracking (no user logged in) by rckalex 2026-03-26 |
1056 |
|
Motion 🇬🇧 Realizing single or multi axis motion control, CAM, CNC and Robotic applications |
Absolute movement controlled by an external encoder. by poliautomacao 1 day ago |
566 |
|
Codesys V2.3 🇬🇧 Forum about V2.3 |
AI + Programming by heman 2026-03-26 |
2242 |
|
Deutsch 🇩🇪 German forum |
Wann kann Git Rebase by mae-rex 2026-03-23 |
4578 |
|
Automation Server 🇬🇧 The Industry 4.0 administration platform for users and operators of CODESYS compatible controllers |
Gateway in China - "Gateway not connected" by pernockham 2026-03-18 |
79 |
|
Forge 🇬🇧 Discussions about CODESYS Forge projects and features of the CODESYS Forge website |
DSE M840-001-02: DSEServiceTool transfers CodesysApp.pkg successfully, b... by sahin6033 2026-03-17 |
231 |
Hello, Im working with EPEC PLC's and working on the HMI and i'm running into the following errors: Unknown Type ISOImages.TargetContainer.TDS (and similars) I cannot locate the error and the source position is the visutalisation manager where i cannot find anything related to this type. Im working with: Codesys V3.5 SP18 patch 3 and i cannot update since the hardware does not allow for newer SP versions
Hey Husarz, thanks for your Message, now i understand your Problem, also able to reproduce that. Pls. give me a Short Time to Check some stuff on this, i'll come back to this Topic with news ASAP. Greetings
Hey Husarz, thanks for your Message, now i understand ypur Problem and are able to reproduce that. Pls. give me a Short Time to Check some stuff on this, i'll come back to this Topic with news ASAP. Greetings
Georg, the encoder's actual position was -208 because I moved it manually for testing, but I managed to get it working. Your information is correct; there was a parameter error, Kp was at 0. After I adjusted it, it responded as expected. Thank you very much for your help.
My codesys is 3.5.21.30. I am using function ModbusServer from library ModbusTCP_Slave. The reason is that I need share 9000 Holding registers. By standard configuration it is only 4096. fbMbTcpDevice: ModbusTCP_Slave.ModbusServer; fbMbTcpDevice( wPort := 502, pInputData := ADR(awInputReg), pOutputData := ADR(awHoldingReg), uiInputDataSize := 10, uiOutputDataSize := 9000, xEnable := TRUE, tTimeout := 10000, InterfaceName := "eth0", xBusy => xBusy, xError => xError, byClientConnections => byConnections...
Please explain how you configured that. Normaly, the Server should answer to all UID as long as gateway isn't activated. With activated gateway all UID will be forwarded to Serial-Interface, in taht case 255 has to be used for Gateway-Diagnostics. So that means, there is somethink wrong on your configuration. Which CDS-Version, Which Runtime-Version and so on are used.
I need the same issue. In my application TCP server on raspberry (codesys) should have UnitID 1. But it only works when I am requesting with UnitID 255. And my application can't work with this parameters...
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...
Hello Alex, the message is generated by the CODESYS code generator based on the DevDesc settings of the memory areas available for the target. The problem arises when after too many online changes the area is full. Therefore no more boot project can be generated. Short-term remedy as described in the dialog: Clean and fresh download. This way the initial memory size will be "used" again After how many online changes did this error occur? There is no set limit on the number of online changes, but...
Do you have any additional information about when the error occurs? I am trying to recreate this issue to find a workaround... Maybe you could also make the project available. You could add the following logfilter to the CODESYS configuration file: [CmpLog] Logger.0.Filter=0xFFFFFFFF Logger.0.Enable=1 Logger.0.MaxEntries=10000 Logger.0.MaxFileSize=1000000 SysSem.Filter=0xFFFFFFFF SysTask.Filter=0xFFFFFFFF I hope that the log filter will show us which task is responsible for this, so we can narrow...