(no subject)
john-morgan-fs
wiki
(Thread)
Last updated: 2026-07-06
code Discussion
daniel
code
(Discussion)
Forum for code comments
Last updated: 2026-07-07
Home
daniel
home
(WikiPage)
Project Members: danieltraxyl (admin)
Last updated: 2026-07-07
Home (version 1) discussion
daniel
home
(Thread)
Home (version 1) discussion
Last updated: 2026-07-07
daniel SVN repository
daniel
code
(SVN Repository)
Last updated: 2026-07-07
Home (version 1) discussion
adamhacia
wiki
(Thread)
Home (version 1) discussion
Last updated: 2026-07-08
Home (version 1) discussion
SpB-IEC
home
(Thread)
Home (version 1) discussion
Last updated: 2026-07-08
Home
brugletoa9
wiki
(WikiPage)
Project Members: brugletoa9 (admin)
Last updated: 2026-07-08
(no subject)
brugletoa9
wiki
(Thread)
Last updated: 2026-07-08
Post by salvatorethomas on Generic Variables and FDB
CODESYS Forge
talk
(Post)
Hi Marco, What you are seeing looks less like a coding mistake and more like a limitation or bug in the FBD editor parser when handling VAR_GENERIC CONSTANT specializations. The fact that the same FB works correctly in ST and only fails when instantiated on the FBD canvas strongly suggests that the graphical editor is not resolving the generic parameterized type correctly. One thing I would try is creating a non-generic wrapper FB around your specialized instance and exposing the required methods through that wrapper. In other words, keep the generic implementation in ST, but let FBD interact with a concrete FB type that has a fixed maxEvents value. Several IEC 61131-3 environments handle generic FBs correctly in ST but struggle with their graphical representation in FBD. Another possibility is that the editor expects the specialization to be defined through a type alias rather than directly in the instance declaration. If your environment supports it, something like: TYPE Coil5 : CDL.Coil(maxEvents := 1); END_TYPE VAR coil1 : Coil5; END_VAR may avoid the parser issue because FBD only sees a concrete type. Given that auto-completion and compilation work while the FBD instance name fails, I would definitely report this as an editor bug to the vendor. Your workaround through ST is valid, but the wrapper or type-alias approach may let you keep the logic fully compatible with FBD. Hope this helps, and please let us know if the type-alias approach works in your setup. Slope 2
Last updated: 2026-07-09
Phantom Test Slot Preventing Suite Completion
CODESYS Forge
talk
(Thread)
Phantom Test Slot Preventing Suite Completion
Last updated: 2026-07-09
Home
ophelia
wiki
(WikiPage)
Project Members: ophelia (admin)
Last updated: 2026-07-09
Post by ophelia on Phantom Test Slot Preventing Suite Completion
CODESYS Forge
talk
(Post)
Hi all, I'm working with a CODESYS 3.5 unit test framework on an embedded Linux PLC and running into an issue where a phantom test slot appears in the results that never completes, preventing the full test suite from ever finishing. The symptom: A blank-named test entry appears in the results table with an ever-increasing action count. It stays as "Testing" or "Failing" indefinitely. Because it never closes, bAllFinished never goes TRUE and the final report is never generated. Question: Has anyone seen this kind of phantom slot issue in a CODESYS unit testing setup? Thanks
Last updated: 2026-07-09
Home (version 1) discussion
achedlund
wiki
(Thread)
Home (version 1) discussion
Last updated: 2026-07-10
wiki Discussion
dukksi
wiki
(Discussion)
Forum for wiki comments
Last updated: 2026-07-10
blog Discussion
dukksi
blog
(Discussion)
Forum for blog comments
Last updated: 2026-07-10
(no subject)
dukksi
wiki
(Thread)
Last updated: 2026-07-10
Home
dukksi
wiki
(WikiPage)
Project Members: dukksi (admin)
Last updated: 2026-07-10
Post by yannickasselin on Beckhoff CX9240 : Using Internal EtherCAT Bus
CODESYS Forge
talk
(Post)
Control RTE is for Windows. @arj3090 specified Linux.
Last updated: 2026-07-10
See if application is running
CODESYS Forge
talk
(Thread)
See if application is running
Last updated: 2026-07-10
Post by ttvs on See if application is running
CODESYS Forge
talk
(Post)
Hello, Is it possible to check if PLC application is running or stopped from linux shell? I am using codesys control for linux arm64sl. Tried accessing the plc shell, but get auth errors. Also, when starting/stopping the program via plc shell from codesys IDE it doesnt report that information to log
Last updated: 2026-07-10
Post by hhermsen on Codesys v3.5.22.10 - Internal error:System.AggregateException...Value cannot be null...Parameter name: expLValue
CODESYS Forge
talk
(Post)
I pinpointed down 4 possible causes for this compiler error: Bare/empty statements (;) standing alone inside an IF/CASE branch — just removed two instances. The optimizer that tries to inline/replace expression statements may choke when a statement has no actual assignment to extract. A VAR_IN_OUT parameter used directly as a FOR loop's own control variable (FOR X := X TO Y DO) General deep-nesting complexity — every one of my decode routines has the same shape (IF busy THEN ... FOR loop containing nested CASE/IF chains ... END_IF), and the crash trace consistently shows for loop → sequence → ifst → sequence → ifst → sequence regardless of the code change. This raises the possibility that it's not one specific statement but a structural depth/complexity limit in SP22.x's compiler optimizer — which would mean no small code change fixes the issue. Only restructuring to reduce nesting depth, or downgrading the compiler will. Something entirely outside my library files — which cannot not ruled out since the exact stack trace was triggered by a Visualization object, in a totally different codebase. This means the same crash signature can come from unrelated causes. IMHO cause 3 seems the most probable one..
Last updated: 2026-07-11
Post by hhermsen on Codesys v3.5.22.10 - Internal error:System.AggregateException...Value cannot be null...Parameter name: expLValue
CODESYS Forge
talk
(Post)
Internal compiler error in SP22.x (expLValue null) — SP21 unaffected — need help isolating root cause I'm hitting the same internal compiler crash reported here. Same exact stack trace (AssignmentStatementReplacer → CreateAssignmentExpression → ArgumentNullException: Value cannot be null. Parameter name: expLValue), but in my case triggered by a self-written library, not a Visualization object — so this looks like a general SP22.x codegen regression rather than something tied to one specific language feature. What I've confirmed: Reverting to SP21 — no issue, builds clean SP22.x — internal compiler crash during Build > Application, code generation phase, with zero useful location info (no POU, no line number) check_for_errors/precompile-only passes cleanly; the crash only happens on a real full build, meaning static analysis never sees it coming What I've tried to isolate the cause (without success): Removed a suspected pattern involving a VAR_IN_OUT parameter used directly as a FOR-loop control variable, combined with early RETURN inside the loop — crash persisted identically afterward Confirmed no Visualization Manager or similar object in the project (ruling out the trigger in the linked report) Used an AI coding assistant (Claude Code) to search for other suspicious patterns — no luck pinpointing the exact statement Question @codesys-com Since the compiler gives no location info at all, is there any way to get more diagnostic output from the SP22.x codegen phase (verbose/debug build flags, log level settings, etc.)? Without that, isolating this in a large library means blind bisection — cutting the codebase in half repeatedly until the crash disappears, which is slow and error-prone without official tooling support. Happy to share the affected project or a minimal repro if that helps CODESYS engineering track it down.
Last updated: 2026-07-11
blog Discussion
mohammad
blog
(Discussion)
Forum for blog comments
Last updated: 2026-07-11
wiki Discussion
williamcorlin
wiki
(Discussion)
Forum for wiki comments
Last updated: 2026-07-14