2023.0 to 2023.9 Firmware Upgrade
I was wondering if there was a streamlined process for updating a PLCNext project. Would it be safe to open a 2023.0 project and upload this to a 3152 which has a firmware version of 2023.9?
I was wondering if there was a streamlined process for updating a PLCNext project. Would it be safe to open a 2023.0 project and upload this to a 3152 which has a firmware version of 2023.9?
Comments
Currently, the 3152 has been upgraded to firmware 2023.9.0 and we were able to write the 2023.0.0 project to it. Does this have any issues in doing this or should we update the project to 2023.9.0?
Additionally, is it correct in saying that a 2023.0.0 project should be writable to any newer minor or patch releases (e.g. 2023.9.0)?
I've been working with PLCnext Enginner for several years now and I am loading projects containing old controller versions to newer firmware versions all the time. So far I did not run into problems because of that.
It blocks loading newer versions to old firmware so one might assume that it is perfectly okay the other way around.
However sometimes new nodes aka new features (at some point the OPC UA node appeared) appear in the plant view when you use newer PLC versions in your project.
Cheers
DivisionByZero
Not sure if it is a coincidence, but after powering off the PLC and powering it back on, no lights are showing on the PLC and PLCnext engineer cannot connect to it. I am still able to ssh to the PLC.
I attempted a manual reset with the push button, but it did not do anything (held it down for 30 seconds).
sudo recover-plcnext 1 did the job but it means I need to reconfigure a bit on the plc.
---
edit: it has occurred twice. Also have seen some strange behaviour with Security Profile being deactivated but still needing to enter the pass on web page.
Thanks for your response!
The general goal is that applications consisting only of a PLCnext Engineer project can be developed for one version of firmware and sent to a PLCnext Control device, and after that any firmware upgrade can be applied to the PLCnext Control device without impacting the correct operation of the PLCnext Engineer project (apart from the down-time required to upgrade the firmware). This means that a PLCnext Control device can get the benefit of security patches and bug-fixes in newer firmware versions, without any changes being required to the original PLCnext Engineer project. In theory a device like this should be able to run forever, getting regular firmware updates but never requiring any change to the PLCnext Engineer project.
This goal isn't possible for every application. For example:
As for the specific problem described in this case, we would need to get more information about the application - like the Output.log file from the device - in order to investigate further.
Hi,
I have been trying to downgrade from 2023.9 to 2023.0 as the marine approval only applies to LTS versions, but after installing the 2023.0 to a 2023.9 target, it still reboots to 2023.9.
Is there a special trick needed to downgrade?
Below is the output for the rauc status --detailed command:
=== System Info ===
Compatible: axcf3152_v2
Variant:
Booted from: rootfs.0 (A)
=== Bootloader ===
Activated: rootfs.0 (A)
=== Slot States ===
o [rootfs.1] (/dev/sda3, ext4, inactive)
bootname: B
boot status: good
slot status:
bundle:
compatible=axcf3152_v2
version=23.9.0.56
description=Update container for axcf3152
build=20240205145319
checksum:
sha256=cf13115692db88b3cf96004fc06903ca3a10e9d57c6e1f013e2ee3015c603e29
size=863798272
installed:
timestamp=2024-02-15T08:49:46Z
count=2
activated:
timestamp=2024-02-15T08:49:46Z
count=2
status=ok
x [rootfs.0] (/dev/sda2, ext4, booted)
bootname: A
mounted: /media/rfs/ro
boot status: good
slot status:
bundle:
compatible=axcf3152_v2
version=23.9.0.56
description=Update container for axcf3152
build=20240205145319
hash=75eb51a33347c96d41b6b23b2cf69f06ba4229d781607c01e10a9c7a54b2d1e7
checksum:
sha256=cf13115692db88b3cf96004fc06903ca3a10e9d57c6e1f013e2ee3015c603e29
size=863798272
installed:
timestamp=2024-02-21T13:42:55Z
count=2
activated:
timestamp=2024-02-21T13:42:55Z
count=2
status=ok
Hello fluxmodel,
according to the A partition, the FW 23.9.0.56 was successfull installed on 2024-02-21T13:42:55Z.
Could you check if the correct FW container 2023.0 was used, please?
BR Eduard
Here is how it looked when performing the firmware update both times.
Afterwards both partitions still reported 2023.9
When running on a test plc 3152 HW version 2. The Output.log has no new lines written to it when plcnext restart is attempted.
root@axcf3152:~# /etc/init.d/plcnext start
root@axcf3152:~# /etc/init.d/plcnext start
/etc/init.d/plcnext: line 31: kill: (3007) - No such process
Starting service plcnext
Set additional plcnext functions
plcnext started
root@axcf3152:~# /etc/init.d/plcnext start
/etc/init.d/plcnext: line 31: kill: (3007) - No such process
Starting service plcnext
Set additional plcnext functions
plcnext started
root@axcf3152:~# 2024 Feb 23 06:40:49 axcf3152 Arp.System.Acf.Internal.ApplicationBase FATAL - Fatal error occurs in application 'MainProcess':
2024 Feb 23 06:40:49 axcf3152 Arp.System.Acf.Internal.ApplicationBase FATAL - Exception occurs: Exception of type 'Arp::System::Commons::InvalidOperationException' was thrown
Could not start remoting server
at /usr/lib/libArp.System.Rsc.so(+0x1a902) [0x7f6e7dd04902]
at Arp::System::Rsc::RscManager::RscManager(Arp::BasicString<char, std::allocator<char> > const&, int, Arp::BasicString<char, std::allocator<char> > const&, bool)
at Arp::System::Rsc::RscManager::CreateInstance(Arp::BasicString<char, std::allocator<char> > const&, int, Arp::BasicString<char, std::allocator<char> > const&, bool)
at Arp::System::Acf::Internal::ApplicationBase::SetupRemoting(bool)
at Arp::System::Acf::Internal::ApplicationBase::SetupBasicComponents(Arp::System::Acf::Internal::ApplicationSetupKind, Arp::System::Acf::Internal::ProcessKind)
at Arp::System::Acf::Internal::ApplicationBase::Main(int, char**, Arp::System::Commons::Diagnostics::Logging::LogLevel)
at Arp.System.Application(+0x40cbc) [0x55add4b16cbc]
at /lib/libc.so.6(+0x2d57b) [0x7f6e7cf8657b]
at /lib/libc.so.6(__libc_start_main+0x80) [0x7f6e7cf86630]
at Arp.System.Application(+0x38625) [0x55add4b0e625]
Hello fluxmodel,
I can reproduce this behavior on AXCF3152 and will forward it to development. As workaround you can execute the reset type 2 (sudo recover-plcnext 2). Then you can update the FW to Version 2022.0LTS and in the last step to FW2023.0LTS.
BR Eduard
Thanks for your effort @Eduard PLCnext Team
Hello again,
I tried your suggestion:
The PLC rebooted and it now reported fw 2020.0 in WBM. So far so good.
Now the funny thing starts:
What more can I try ?
Never mind my last post.. someone disconnected my network cable when the PLC was rebooting during the fw upgrade.. 😒
Hello fluxmodel,
the reported behavior for FW downgrade from 2023.9 to 2023.0 is known and described in Chage Notes as follows:
Note for a controller with hardware revision 03 and older:
If you want to perform a firmware downgrade from firmware version 2023.9.0 or newer to a firmware version 2023.3 or older, you must first perform a “Reset to default setting type 2”. Then perform the update to the desired firmware version.
To following Error-State:
Please check if the SD-Card is inserted, if yes, please try to reme it and reboot.
If the reboot does not proceed successful, please try to execute the Reset Type 2 via Reset-Button again.
If the reset will be not successful, please contact the support deparment in your country and send the controller for repair.
I hope it helps.
BR Eduard
Hi @Eduard PLCnext Team
The procedure you originally provided worked like it should.
I was just confused because I lost connection to the controller after the first firmware upgrade after reset (from 2020 to 2022). The reason for the lost connection was that someone unplugged my cable by mistake exactly when the controller was rebooting. Thus the disconnection was as expected from my side, but when I never regained the connection, i feared the controller was broken. As the cable disconnect happened in a network switch under the table, i did not immediately notice it.
This is what i tried to explain in my previous post here