Skip to content

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?

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.

  • 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:

    • The firmware developers cannot anticipate how every app (including every library for PLCnext Engineer) in the PLCnext Store is written. If an app uses a system feature that changes between firmware versions, then the app (or library) may not work as expected after a firmware upgrade. In this case the app (or library) should only be used with one of the firmware versions specified by the app (or library) developers.
    • If you develop your own application that runs on the device outside PLCnext Engineer, e.g. a native executable, then this might also depend on system features that could change between firmware versions. In this case you should thoroughly test your application with the new firmware version before applying the firmware upgrade to the running device.

    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

  • edited February 2024

    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

  • Hello again,

    I tried your suggestion:

    • Run "sudo recover-plcnext 2"



    The PLC rebooted and it now reported fw 2020.0 in WBM. So far so good.

    • I then proceeded to install fw 2022.0.8, and the PLC reboots.

    Now the funny thing starts:

    • I am no longer able to contact the PLC
    • There are three active LEDs: RUN (steady green), D (steady yellow), BF-D (steady red). All IO-cards are flashing a yellow D LED
    • Rebooting does not work (returns to the same state)
    • Using the reset-button to perform another type 2 reset does not work (hold reset 30 secs after boot until all lights are yellow). It still returns to the same state.
    • Searching for device in PLCnext Engineer does not work (no device found)

    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:

    • Rebooting does not work (returns to the same state)
    • Using the reset-button to perform another type 2 reset does not work (hold reset 30 secs after boot until all lights are yellow). It still returns to the same 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

Sign In or Register to comment.