Patched Wine packages for Ubuntu and CODESYS 3.5

2026-10-31T00:14:10.989000Z

I have now published Ubuntu amd64 packages of my patched Wine build for CODESYS, targeting Ubuntu 22.04, 24.04, 26.04 and 26.10.

The packages are based on Wine 11.20 and include all five compatibility patches covering NCrypt, thread suspension, security tokens, service tokens and local WMI marshalling. Both 32-bit and 64-bit Windows applications are supported through WoW64.

In my working environment, CODESYS 3.5 SP21 successfully compiled and went online with a very complex project containing hundreds of thousands of lines of code and extensive use of polymorphism.

PPA and installation

All four binary builds have completed successfully and are now published and available through APT.

Wine ADV for CODESYS PPA

sudo add-apt-repository ppa:mondinmr/wine-adv
sudo apt update
sudo apt install wine-adv

The runtime installs under /opt/wine-adv and provides dedicated commands, allowing it to coexist with your existing Wine installation.

For example, to launch CODESYS from an existing dedicated prefix:

WINEPREFIX="$HOME/.wine.codesys" wine-adv \
  'C:\Program Files\CODESYS 3.5.21.30\CODESYS\Common\CODESYS.exe'

Adjust the executable path to match your installed version. Use the same WINEPREFIX when running the CODESYS installer or installing its prerequisites.

The package contains the patched Wine runtime. CODESYS and its required Microsoft .NET components must be installed separately inside the prefix.

Source code, patches and packaging are available on the project page.

This is an experimental community build. Feedback and test results from other users are welcome!

CODESYS Installer and CodeMeter licensing are also working in my setup.

For CodeMeter, I use the native Linux CodeMeter runtime, while the Windows applications run under the patched Wine build.

From target start Win OnScreenKeyboard

2026-10-29T09:28:27.927000Z

Thanks, but today morning it works on random base. (from Target Visu directly). After a few attemps I found the problem:
The button for the keyboard is on the Master-Frame. And it works on every single Visu-Screen, but NOT on the Start-Visu! (But there is a short flash on the bottom of the screen...)
And of course I tested the whole time with the Start-Visu. Now I copy the Bitmap-Button on the Start Screen OVER the Frame Bitmap, too and it works. So I think its a bug...
For me works this: in the visu for the element
Input-Config >> OnMouseUp >> ExecuteClientProgram >> 1. Parameter = 'osk.exe'

From target start Win OnScreenKeyboard

2026-10-28T14:40:05.287000Z

Check the CODESYS log. Do you see something like this?:

2026-10-28T14:27:50.602Z: Cmp=SysFile, Class=2, Error=39, Info=4, pszInfo=!!!! Access denied to 'C:/Windows/System32/osk.exe' due to ForceIecFilePath
2026-10-28T14:27:50.602Z: Cmp=SysFile, Class=1, Error=0, Info=0, pszInfo= To grant access, this path may be configured as a PlaceholderFilePath

PS, if you give an irritating, or annoying or blaming answer, I will never try to help you again.

SMC_Interpolator / CNC Abort – ControlAxisByPos Sometimes Remains Busy and Axis Continues Moving

2026-10-27T16:35:07.197000Z

Hi kishan,

I would recommend to first execute a stop (input bSlowStop or bQuickStop of the interpolator). Only when the interpolator has stopped you should abort the interpolator and preprocessing FBs. BTW., a new rising edge of the execute input should suffice.

In case preprocessing is done in a different task: take care to write the abort signal to a local variable in the path and interpolation task and use this local copy. (Otherwise, some preprocessing FBs might see an abort and others not, in the same cycle of the task.)

Best regards,

Georg

From target start Win OnScreenKeyboard

2026-10-27T16:06:50.335000Z

Hi !
I am get crazy....
I try to start osk.exe from Visu or PLC.
From Visu I can't load it, always error (It change from programm execute always to load receipe ..!?!?)
From PLC always freeze of PLC,
- I allowed the win service of the PLC the data exchange between desktop and service
- I allowed in ..user.cfg [SysProcess] Command=AllowAll
Shutdown with SysProcessExecuteCommand works, but 'osk.exe' or the complete path always crashed the system.
And like always: No documentation. Just guessing. Or know somebody more and have a link for me?
THANKS !

From target start Win OnScreenKeyboard

2026-10-27T16:06:41.901000Z

Checking the device tree, not just the code: what else is worth a static check?

2026-10-27T08:10:53.689000Z

I spend most of my time reviewing other people's CODESYS projects before commissioning,
and two kinds of defects keep showing up. Both compile clean. Both read fine.

One is in the code. A pause timer whose own input gets cleared inside the branch
the timer is supposed to gate:

rampDelay(IN := run_2);
IF NOT run_2 OR rampDelay.Q THEN
    run_1 := TRUE;
    run_2 := FALSE;      // the timer's own input, cleared right here
ELSE
    run_1 := FALSE;
    run_2 := FALSE;
END_IF

Next scan IN is FALSE, the timer resets, the condition is true again, and the second
pump starts immediately. A 30-second ramp delay that actually lasts one task cycle.
The setpoint is on the HMI, the operator turns it, and nothing changes.

The other is not in the code at all. On one site the outdoor temperature read 0.0 °C
in mild weather. The ST was correct, the variable was bound to the channel — but the
channel's sensor type was left at "disabled", so nothing was ever digitised. Same class:
a module with Disable_module = TRUE, or an analog output bound to a variable while its
mode is off. Nothing in the project reports any of this, and the code review never looks
there, because the configuration lives in the device tree and not in the POUs.

That second class is what pushed me to parse the .export format rather than PLCopenXML
alone — the export carries the device tree and the visualization, so "nothing ever writes
this alarm variable" stops being a guess and becomes a fact you can check against the
screen bindings.

Three things about the format that cost me time, in case they save you some:

the same device parameter can appear three times (template, internal copy, actual
configuration) — the last occurrence is the one in effect;
the enum value of a parameter is not in the parameter itself, it is one level down
in BaseType/Value;
a channel counts as used when a variable is bound to SensorValueN.SensorValue —
InputStatus is a bad indicator, people deliberately bind it on spare inputs.

So the question. What else would you check automatically, given both the code and the
device tree? I am collecting rules from sites, not from style guides, and the
configuration side feels largely unexplored.

For what it is worth, the checker I use for this is free and runs offline (single exe,
no install, nothing uploaded anywhere): https://github.com/caspershes/plc-lint — 43 rules
at the moment, reads .export and PLCopenXML. Happy to add rules people here suggest.

Hilscher cards CoDeSys Control RTE

2026-10-23T07:50:29.700000Z

You have to know this (and the crap help site don't tell you):
- Changes in CODESYSControl_User.cfg, not in CODESYSControl.cfg (crash of PLC/Win possible)
- Redundancy is important for Profibus, also if you don't use it because the libarys depending on it
- The no. after the device is the slot numer for PLC device config

[ComponentManager]
Component.1=CmpDrvSchedulerAMP
Component.2=CmpCodeMeter
Component.3=CmpHilscherCIFX
Component.4=CmpNetXCanDlDrv ; this is not in help, but thats makes the internal driver load
Component.5=CmpRedundancy
Component.6=CmpRedundancyConnectionIP

[CmpHilscherCIFX]
TraceLevel=0xFFFFFFFF
InterruptMode=0
DMAMode=1
;DynamicFirmware=1
BootloaderFile=$Firmware$/HilscherCIFX/Firmware/NETX100-BSL.bin
FirmwareFilePath=$Firmware$/HilscherCIFX/Firmware
;non-dynamic declaration of FW-files:
; 100 !!! CIFIX50 cards but files called 100 !!! Device.0.BootloaderFilePath=$Firmware$\HilscherCIFX\Firmware\NETX100-BSL.bin
Device.0.Channel.0.FirmwareFile=$Firmware$\HilscherCIFX\Firmware\cifxcom.nxf
Device.1.BootloaderFilePath=$Firmware$\HilscherCIFX\Firmware\NETX100-BSL.bin
Device.1.Channel.0.FirmwareFile=$Firmware$\HilscherCIFX\Firmware\cifxdpm.nxf

;;;; And good luck, you will need it ! ;;;;

Hilscher cards CoDeSys Control RTE

2026-10-22T13:37:08.896000Z

the information "license completly by Codesys" is WRONG.
For DP Master function you need the license from Hilscher, too.

Block the program upload

2026-10-21T14:20:26.042000Z

Don't share your username and password.

Recent posts to Talk

Patched Wine packages for Ubuntu and CODESYS 3.5

From target start Win OnScreenKeyboard

From target start Win OnScreenKeyboard

SMC_Interpolator / CNC Abort – ControlAxisByPos Sometimes Remains Busy and Axis Continues Moving

From target start Win OnScreenKeyboard

From target start Win OnScreenKeyboard

Checking the device tree, not just the code: what else is worth a static check?

Hilscher cards CoDeSys Control RTE

Hilscher cards CoDeSys Control RTE

Block the program upload