Reliable software updates in field

Chuck,

We struggle with the same issue. I just added an idea to have onboard USB port such that the end user could push the update.

I have updated about 200 machines remotely the all over the world, sometimes literally on the opposite side of the planet, and so far it hasn't failed a single time. 

Although a few times I thought it would fail because of one or several of the reasons below and every once in a while it required multiple re-connection attempts to finish the updating process.

Our machines has a setup with either MD4-5 + MC41 + MC43 + G11 or MD4-7 + MC42 + MC43 + G12.

Here is some advice:

- On machines with G11, don't attempt an update that replaces the entire firmware (like updating from 5.04 to 6.08) since that can take an hour, which can make it very time consuming if the connection is unstable. 

With G12 it seems okay to update the firmware remotely since it is much faster.

- If the machine requests the user to make a Bluetooth firmware update, make sure to get the Bluetooth update done before you start updating the software. 

The Bluetooth update appears to improve the stability of the connection and if the user would skip it and then has to reconnect and then accidentally interrupts the Bluetooth update once started, the machine can become difficult to access remotely.

- If you are using IQAN 7.00, make sure to update to 7.02 since 7.00 had issues that prevented it from finishing the remote update in a proper way. (MD4 gets stuck with blue screen until power cycled and IQANrun hangs)

- Make sure the user has decent cellphone signal and ask the user to switch WiFi off. If the phone switches between WiFi and mobile network it will interrupt the update process.

- If possible from a safety point of view, let the machine run at idle during the update process. Low battery voltage can cause all sorts of strange issues when attempting an update and the voltage doesn't have to go that low before it causes issues.

- In some cases, when the signal is poor, talking to the user in the same phone as is used for the data transfer will slow down or interrupt the updating process. Then tell the user to connect to the machine and call back later.

- If you have weird connection/transfer issues that doesn't seem to have any logical explanation, make sure the user's phone doesn't have any extra security layer that fully or partially blocks data traffic. Some security related organisations will add such limitations to their employees phones.

That said, a simple way for the user to push the update locally could be useful, but I am not sure how we would solve it from a safety point of view at out company.

Our project is very large 26.2megs big. how big it the project you are uploading?

recently updated to 7.02 "(MD4 gets stuck with blue screen until power cycled and IQANrun hangs)" is a big deal. what i was experiencing.

i have MC43 and MD7

G11 or G12, mostly G12

another thought i have is old computer with lots of drivers on it.

Our project file is 25,6MB, but most of that files content appears to be firmware for the display as it only uploads a fraction of the file if the new project was created in the same version of IQANDesign as the project on the machine.

i am going to try a newer laptop

Here is my report on the bluescreen issues at remote update that were fixed in 7.02, in case you want to confirm that you experienced the same issue: https://forum.iqan.se/communities/1/topics/3734-issues-with-system-reboot-after-remote-update-using-701

thanks for that. when i get hung, i always have to turn bluetooth off and back on too

okay i have done 3 remote update 2 worked and 1 bricked the mc43. we did the remote push with tech in field so we can hardwired to bricked machine.  honestly the upload for update is not reliable enough to use in my opinion. if i did a session with a customer and they get blue screen i would have to fly out to deal with it costing thousands of dollars. There has to be a better way. current way in not ! working.   i did see firmware update, it wasnt an option i could not elect to do, suggestions of where that option is would be helpful

It would be better if the system could use free memory, for example in the display, to download and temporarily store the entire file package, verify the files and then start the update process locally.

That would prevent issues with machines locked up half way through an update since it wouldn't start the process until all the files were transferred.

use free memory, for example in the display ??? i am not following your comments.

There is only one way to send files that i am aware of

Even thought I didn't have any issues with remote updating which I could not solve so far, there are many ways the update process could potentially fail, bricking the machine temporarily until someone manages to re-run and finalize the update process.

For example, something could happen to the phone or the network during the update process.

Our typical file size is 25MB whereof most of it is software for the display.

Usually, only a fraction of those 25MB is transferred and most of it goes to the MD4.

The MD4 has 2GB flash memory available.

Today the update process appears to transfer file by file over the network and hand it out through the CAN-network to each module.

Once the update process is started, the system is effectively bricked until the process is completed for all modules.

If something interrupts the update process half way though, the machine will be bricked until the software update is re-run and completed.

In my mind, I would prefer if the update process could allocate some space in the MD4 flash memory, transfer all files needed for the update and then start the update locally on the machine.

That way, if the connection fails, the machine will never be bricked due to an unstable connection, but the file transfer will just not work and the machine continues running on the old software.

I realize thought that such change to the system architecture might not be possible.

i have also seen comments about not allowing firmware updates, again no idea how this is done, there are no choices to do these things

I don't think Parker would ever decide to help and introduce a new path of updating firmware/software remotely. I think this might be simply by not understanding the challenges we face with large fleet of machines, across the country working days and nights. Setting up time windows with mechanics is one logistic nightmare.

I attended many automation shows in US, where I asked different vendors on how system can be updated. The answers are simple:

• Remote
• Local (laptop)
• USB

We had many instances where remote updates crashed the system. Sending a field service technician across the country in the emergency mode is in my option not the option not mentioning very expensive. G1x, although great concept, did not always work for us.

I am currently testing new control system (non IQAN) where the master module has an USB port from which you can update software and firmware. By using touch screen display you can select the update and have the system up and running in no time. Simple email password protected program to the end user and ask them to update the program when they have a moment.

Even older PLCs I used to work with had memory cards 

is  master module has an USB port from which you can update software and firmware  have parker equipment? or did you step away from it

Chuck,

The module firmware version follows the version of IQANdesign you save the file in.

If all you need to send is an update to application logic, a suggestion is to check what SW version you have in the MD4 before sending, and compare this to the file you plan on sending.

IQANrun helps with this by presenting a popup dialog that tells you if you are about to make a version update.

When you do update firmware in the IQAN module, this is saved in a separate memory area before switching over from the current firmware. 

An interrupted/failed update can leave you without a valid application in the module. But an IQAN module will never be completely "bricked", it will still have a firmware, which also means you can try again if an update failed. 

(merged duplicate posts)

This thread is of interest to me because of our company having issues with convincing customers, etc. to use there phone for he IQAN Go bluetooth connection. 

Have any of you tried using a cellur modem with vpn connected via ethernet? Is this possible? Could this potentially be faster and more stable than the bluetooth option?

Best Regards,

We use modems to update programs remotely however when you have a poor cellular coverage you might re-think if pushing the program is the right choice. 

What modems work best for you? Most of ours are in decent cell coverage, if they aren't, we will simply have to drive out to the machine.

@gustav  is parker going to address this? it is a difficult issue

I have updated many machines remotely. As the primary option I like to have a 4G modem with VPN in each machine, that works great in 99% of the cases.
I always connect ethernet from the MD4 to the modem, and diagnostic bus between MD4 and MC4x. This is because MD4 has the largest filesize and you want to avoid sending that over CAN.

In the few cases where it fails, every machine has a G11/G12, then you can have the customer update with IQANgo.