Build error using Revolution Pi Library for CODESYS v1.4.1.0 and v2.0.0.0 with CODESYS v3.5 SP21 (64bit)

[rossanoparis]

I have updated CODESYS development tool to the version v3.5 SP21 (64bit)
The previous version was v3.5.20.40

Compiling two existing application with the new evelopment tool I get the following errors.

Revolution Pi Library for CODESYS v1.4.1.0

kunbusiodrvrevpibridge, 1.4.1.0 (kunbus gmbh): IoDrvScanModules [IoDrvRevPiBridge](Line 51, Column 1 (Impl)):
Internal Error (ARM): Unsupported conversion!

Revolution Pi Library for CODESYS v2.0.0.0

kunbusiodrvrevpibridge, 2.0.0.0 (kunbus gmbh): IoDrvScanModules [IoDrvRevPiBridge](Line 51, Column 1 (Impl)): Internal Error (ARM64): Invalid type for zero extension

These errors were not reported in the previous compiler version.
They've got a different description, but they have in common the same source code.

The error is due to the following conversion:
m_udiError := TO_UDINT(excCode);

The excCode variable is a system type, declared as shown below, and should be converted to a UDINT
excCode : __SYSTEM.ExceptionCode;
m_udiError: UDINT;

We would appreciate it if someone could provide feedback on this issue.
It i simportant for us, as we have to maintain two different OS; Stretch 32bit and Bullseye 64bit
That's why we are using two different version of "Revolution Pi Library"

[nicolaiB]

Codesys sp21 isnt supported (yet). We're about to publish a beta release with sp21 support soon

[rossanoparis]

Thank you, may I ask you whether even for the following version?
Revolution Pi Library for CODESYS v1.4.1.0

[nicolaiB]

Unfortunately not fornthe older library. Stretch was end of life in 2020 and even the lts support ended in 2022. Is there are particular reason why you cant update ro a recent os version?

[rossanoparis]

This would really be a big issue for us, as we manage a single software that we distribute to around a hundred electromedical machines worldwide.
These machines are already installed in the field, and it's not possible to update their operating systems.
Internally, we’d have to handle multiple software versions and try to keep them in sync, and from a management point of view, it would also mean dealing with more internal items.
The machines have already been certified, and this would force us to go through a full recertification process.
In short, it would be quite a mess.
We kindly ask you to consider releasing at least one final version of 1.4.1.
Thank you very much!

[nicolaiB]

We have received your request and will discuss this internally. For recent systems we have just published a beta version with SP21 support. You can find details in this thread: viewtopic.php?t=4716

Nicolai

[rossanoparis]

Thanks Nicolai for the information.

Regarding version 1.4.1 of the library, I’d like to point out that, in addition to what we’ve already mentioned, there are further implications.
A lot of the code used in our applications is part of libraries included in various projects, so these libraries are shared with our standard production environment.
If your library isn’t updated, we’d be forced to maintain multiple versions of libraries containing identical code, but compiled with different compiler versions.

CODESYS has always maintained portability for its runtime systems, even on operating systems considered obsolete.
Even if an operating system is considered obsolete, you can’t just wipe out dozens or even hundreds of applications already in the field.
CODESYS approach ensures that the code we produce remains portable too; just as we've made efforts to write code that works across different ARM architectures, whether 32 or 64 bit.

We now find ourselves in a really difficult situation, all because of a third-party library that requires a relatively simple type cast fix.
Please do consider the challenges we’ll face if version 1.4.1 isn’t updated.

Kind regards
Rossano