Ctrlx Autmation Core

[Olorin]

Is it possible to use an older version of the automation core on a newer CtrlxOS release. For example could I use version 1.2 Automation Core with version 2.4 OS. The idea is to update the OS without having to update any application built with the RT-SDK so 1 install can go into any CtrlxCore, regardless of the OS version.

[Sgilk]

The short answer is no, as Automation Core is itself a component of the ctrlX OS. Many of the other applications included in the OS are dependent on the Automation Core at the same version.

[CodeShepherd]

The limiting factor here is not only the automation core but also the Ubuntu core. You can install an core20 beside your system 2.04 (core22) to get NRT apps to work that were created in 1.20 (core20).

But beware that various system interfaces have changed. Especially our real time framework got an update so that old application cannot run in the new system.

[olorin_1990]

Thanks for the reply... not sure why it's making me make a new user name but i am the OP I was able to get an RT app for 1.2 running on 2.04 by using the UbuntuCore 20 runtime and downgrading the automation core. The ethercat app is also running. Is the only downside not being able to have the latest Apps? Being forced to update your app everytime a customer wants to update their OS for security is somthing we would like to be able to avoid

[olorin_1990]

Thanks for the answer, for some reason the system made me change my Username.... but I am the OP.

Currently have ehthercat app V1.2 and an RT app running that was built for version 1.2 on V2.04 by adding the Core20 runtime and downgrading the automationCore. Is the only limitation that we cannot use apps that require the newer automation core? or are there other problems?

The customer doesn't want to have to send a new compiled app everytime their client's IT forces an OS update by their security policies for Linux, so not being able to run the old software on the newer OS is a pretty big issue. Given it's all SNAPS I would expect that as long as they don't use any apps that require the newer Automation Core it should be ok, and at least in a simple test seems ok. Are there any gotcha's I'm not seeing?

Thanks

[CodeShepherd · Accepted solution]

So why updating the the OS in the first place? All ctrlX OS LTS or ‘Long Term Support’ versions (see Release cycle of apps and engineering software) of our system will get security patches.

The main thing by ripping the system apps apart is, like mentioned above, that various snaps could use interfaces and so are relying on each other. Also the AutomationCore that uses and brings base functionality like realtime framework, data layer, system diagnostics, REST interfaces..., so it can work but not necessarily. Also this app could need security patches. For such reasons ctrlX OS is only allowed to be used in consistent versions and we do not give any warranty or support otherwise.

[Olorin]

Thanks for the response. For the record this was for a machine builder client who would rather not have to keep re-compiling their realtime app for different versions of the OS,maintian multiple bundle activation and cmake files, and retest on each OS build. Many of their client's IT departments have OS version requierements for Linux. This means if the client's customer wants to update the ctrlX OS then the client would have to send them a new snap with their RT-app in it, instead of just having the client downgrade the automation core and keep the OS update.