Which CODESYS 2.3 runtime runs on 64-bit Windows panels

Can the CODESYS 2.3 RTE run on a 64-bit Windows panel PC?

The CODESYS V2.3 RTE runs only on 32-bit Windows, so a 64-bit panel PC cannot host it: the vendor's support channel confirms the 2.3.9.47 RTE on Windows 7 32-bit, and the application documentation states the runtime supports only Windows 7 as a 32-bit system.

Two components hide behind one download page. The V2.3 programming system, the engineering tool, installs on x64 Windows for project work, and the V2.3 RTE, the service that executes the program on the panel PC, installs only where the operating system is 32-bit. Read every compatibility statement with that split in mind: x64 compatibility of the engineering download says nothing about the runtime service that has to run in production.

The consequence for a fleet is direct. The XP panel PCs the old stations ran on are gone from suppliers, so the hardware moves, and on x64 hardware the V2.3 RTE is off the table unless you deliberately order a 32-bit Windows license for the new panel.

Which runtime options exist for a V2.3 project on a 64-bit panel PC?

Two paths keep your V2.3 libraries and generated function blocks untouched: the V2.3 RTE on 32-bit Windows 7, or the V2.3 PLCWinNT target on 64-bit Windows; the two V3 runtimes, Control RTE and Control Win, also cover x64 but open a conversion effort.

Two of the four keep the V2.3 library base untouched, which decides the case when a tool generates the project and the function blocks must stay identical across an installed fleet. The two V3 runtimes open V2.3 projects directly, and most functionality converts without edits; what goes back on the review list is the custom file-access code and every third-party library.

Is a 32-bit Windows panel PC still a path worth buying?

Treat 32-bit as a closing door: the vendor's lifecycle page ends 32-bit support for Control RTE SL on 31 December 2026, with SP22 the last supported version, so a 32-bit panel PC ordered today buys time on a branch the ecosystem is leaving.

How long the V2.3 RTE itself stays supported carries no published date at all, which is its own answer. Leave existing 32-bit panels in service where they already run the V2.3 RTE with a supported adapter, and order x64 for every new panel, settling timing with the runtime choice instead.

When is the PLCWinNT target good enough, and when does it fail?

PLCWinNT is good enough whenever your station only moves data: a Modbus TCP poll, an OPC DA link to the HMI and server file access have no hard real-time loop to protect, while motion or any axis control needs the RTE, because SoftMotion requires it.

Because PLCWinNT executes as a Windows process, Windows schedules it and cycle timing gets softer. The vendor's own comparison puts the RTE far ahead on jitter, and motion is the hard line. Read that against your station list. Polling a Modbus remote I/O unit, serving OPC DA to a Java HMI, reading a string from a vision camera every cycle and writing files to a server are data moves with no machine behind them; a few milliseconds of scheduling delay on any of them shows nothing an operator can see.

One safety line belongs here: if the station drives an interlock, an axis or anything that stops or moves material, soft timing is the wrong tool, and that loop belongs on an RTE-class runtime or a dedicated controller.

On a Windows-scheduled runtime, put the heavy work at the end of the cycle; moving cycle-end data transfers out of the PLC program shows the pattern.

Which network adapters does each runtime accept?

An RTE never uses the Windows network stack: it takes over the adapter with its own driver component, so each adapter model needs a matching component, while PLCWinNT and Control Win work with any adapter the operating system supports.

A current panel PC whose controllers are missing from the V2.3 RTE adapter list cannot serve the RTE even on 32-bit Windows, and the symptom on the floor is a target that never connects, or Modbus TCP traffic to the remote I/O that never leaves the box. The V3 Control RTE ships driver components for current controllers; for one very common on-board gigabit controller family, the component is CmpEt1000MPD, installed from the INF the V3 package carries at c:\Program Files\3S CoDeSys\CODESYS Control RTE3\CmpEt1000MPD\net541ex.inf. Bind the adapter to that INF in Windows Device Manager, then add the component to the RTE configuration. Pointing a V2.3 runtime at that folder solves nothing, because the folder belongs to the V3 product.

How do you test a V3 conversion before buying a runtime license?

You can test the whole conversion for free, because the demo runtimes run for 2 hours per start: download V3 with Control Win, import a representative project, rebuild it and count the compile errors before you buy any runtime license.

Control Win ships with the development system, so the first bench needs no extra download, and Control RTE comes from the vendor's store on the same terms. The sequence that produces a real cost estimate:

1. Open the V2.3 project in V3; the IDE imports it directly.
2. Rebuild with the representative library set and count the compile errors by cause: file-access blocks, third-party libraries, memory layout settings.
3. Run the built project under Control Win for a 2-hour session against the real remote I/O and the HMI.
4. Send the project, or screenshots of the library manager, to the runtime vendor's official support channel for an effort estimate.

File access is the usual rewrite: V3 handles files through a Use Case library built on the Common Behaviour Model, device independent and non-blocking where the V2.3 file blocks block. Teams new to V3 shorten the curve with the vendor's 20-hour training. Two demo starts in one afternoon give 2 × 120 = 240 minutes of run time, enough to see whether the HMI link, the Modbus poll and the file share survive.

Scenario: which runtime fits a data-only station moving from XP to an x64 panel?

A data-management station on a new x64 panel PC, built from generated V2.3 code that must match an installed fleet, lands on the V2.3 PLCWinNT target: it keeps every library unchanged, avoids the adapter driver question and accepts the higher jitter a data station can absorb.

Take the station behind this decision: a softPLC on a panel PC, a Java HMI over OPC DA, a Modbus TCP remote I/O unit, file access to a Windows server, and a string read from a vision camera. The project is tool-generated, must match an installed V2.3 fleet, and the station performs no machine control. Assume a 100 ms Modbus TCP poll and a 20-character camera string read 10 times per second; measure your own values before you rely on the result.

• Poll load. 20 characters × 10 reads per second = 200 characters per second. A 100 Mbit/s Ethernet link carries 100 ÷ 8 = 12.5 MB/s, so the camera traffic uses 200 ÷ 12,500,000 = 0.0016% of the link. Bandwidth is nowhere near the constraint.
• Timing. The fastest transaction is the 100 ms poll. There is no axis, no interlock and no output that moves material, so Windows scheduling delay on a data poll costs nothing visible.
• Bench budget. The demo runtime allows 120 minutes per start. One import-and-build session of 30 minutes plus two demo runs gives 30 + (2 × 120) = 270 minutes, or 4.5 hours of test in an afternoon.

Result: the station runs the V2.3 PLCWinNT target on the new x64 panel PC with every library unchanged, and the V3 conversion runs on the bench under the demo license until the fleet plan allows the move. If the wall next to the station should show the same numbers, a read-only process display keeps the PLC program as it is, and where a small screen fits on an andon board covers the placement question.

Which runtime should you pick?

Pick PLCWinNT for a V2.3 fleet on x64 panels, the V2.3 RTE on 32-bit Windows only where a line already runs it and hard real time is fixed, and V3 Control RTE where x64 plus hard real time or motion is a hard requirement.

Sort the fleet into three cases and the choice follows on its own.

• Data-only V2.3 station on a new x64 panel: PLCWinNT. Fleet consistency stays intact, migration risk on the generated code stays at zero, and the Windows network stack removes the adapter question.
• Existing 32-bit panel already running the V2.3 RTE with a supported adapter: leave it in service; that combination still delivers hard real time under V2.3.
• New station that needs hard real time, motion or SoftMotion on x64: V3 Control RTE, with the library migration costed first through the demo build and the support estimate.

Recommendation: run today's data-only V2.3 stations on the PLCWinNT target when the panel PC is 64-bit, keep the V2.3 RTE only on existing 32-bit panels that already run it with a supported adapter, and move a station to V3 Control RTE when x64 hard real time or motion is a requirement, costing that conversion with the 2-hour demo runtime before any purchase. After a target switch, check whether the runtime is running or stopped before you suspect the project, and keep V3 on the bench as the planned path for the whole fleet.

Questions