Firmware Resources and G11

I agree. I have had a new generation phone within 2 ft of a g11 and had one of the firmware take hours to push and the update was stored on the phone. I'm glad this didn't happen over a remote connection where it would have tied up the computer, as well as, the technition and the machine they were working on. 

The need for the system to download firmware resources is dictated by the IQAN design version that is used for the application. 

For example, if I send an application developed in IQAN design 6.01, the first time the firmware resources will be sent with the application.  Future application updates, still developed in IQAN design 6.01, will only update the application resources and will be much quicker. 

However, if I migrate my application to IQAN design 6.02, the next time I send a project to the system, the firmware resources will need to be updated as well.  This ensures that the firmware that is running on the target hardware matches the version of IQAN design used to develop the application.

Another thing to note is that if a MD4 (any size) is used in the system, it's resources that are loaded with the firmware upgrade is quite large compared to the non display master modules.  This is due to the display resources.  With the G11, the wired connection to the system is via CAN bus, which is a slow communication protocol compared to Ethernet.  We recommend loading files that update the firmware resources over Ethernet when communicating with the MD4's due to the file size.  In my experience, load a project file with a different firmware version in a MD4 over Ethernet takes roughly 5 minutes and loading the same file over CAN takes 20-30 minutes.  Again, this is due to the communication speed difference between Ethernet and CAN.

Have the IQAN team considered making a G11 that can be connected to either CAN or Ethernet ?  

There are wifi to Ethernet bridges available via 3rd party.  I believe they will work with the wifi connection via the mobile apps, but I have never tried to use it.

Edward, I agree, the root cause of firmware updates seems to be tied primarily to IQAN design versioning. There are additional factors though, probably the MD4 project dependencies Kerry alluded to. Even saving two different projects within the same version of IQAN design, I will hit this firmware issue trying to swap between them with the G11.  Project-dependent MD4 resources must not be cached on the MD4 at all.

With most embedded systems, firmware is a manually managed resource. IQAN has obfuscated the firmware to such a degree most of us can live in total ignorance of its existence or ramifications. That is great until you try to manage updates remotely through such constrained resources.  I have one colleague with another license of IQAN design. We have never made any effort to synchronize on the same minor version of IQAN design 5.04.XXXX or 5.06.XXXX.  I am worried this might be causing some of these headaches. Even if we were developing on the same minor version though. I believe we would occasionally run into unintended firmware migrations.

IQAN design and IQAN sync and IQAN go do not have any ability to report firmware resources incorporated into a certain project and no user interface for alerting of "minor" firmware mismatch before opening or sending a project file. At the very least, I think we need a method to view the firmware contained in a previously saved file or what version of the IDE it was even saved in.

The IQANdesign version you use control the firmware version in the project file. When you send from IQANdesign, or save in IQANdesign, the file is updated with the firmware from that IQANdesign version. The key idea is to always have a compatible firmware. 

A new major and minor version of IQANdesign always means a change in firmware. Sometimes when there are bug-fix updates, a new IQANdesign release version can also come with new firmware for one or more master modules.

For example, IQANdesign 6.02.10 contain the same master module firmware as the previously released, version 6.02.7.

While IQANdesign 5.04.14 on the other hand had updates on the MD4 firmware compared to the first 5.04 release.

One way to see the version of your existing files is to look at the file properties in Windows explorer. 

On the line where it says Master you see the version of the master module.

Not all firmware resources are modified in every version, so the full 25 MB doesn't have to be sent. But even for a small update, the new IQANdesign version means several MB has to be sent. 

What you also have is project specific resources like fonts and images. On an MD4, the images are saved in one resource file, a change to the images can give a noticeable impact on the time it takes to send an update. 

Thanks Gustav, that metadata is very useful.  With that information, I can start documenting all the firmware versions across our fleet and begin to truly understand the feasibility of remote updates over low bandwidth media like CAN, cellular, and bluetooth.

So far, I have had zero successful attempts to flash 5.04.xxxx or 5.06.xxxx firmware resources to MD4-7+G11 on Android+IQANsync, Android+IQANgo, or IOS+IQANgo.

All attempts locked up/froze on the resources.ifr checksum calculation after 23-55 minutes of file transfers.  Disconcertingly, the system reboots into a functional but visually discordant system after power cycling instead of a blank program or some other safe state.  I have not tested the control system to gauge how functional it is in this partially broken state after the failed update:

That the display page look strange is probably because the images aren't updated.

From the photos, it looks as if one of the differences between the two versions of your project file is that the later one have PDF files in it. 

When adding PDF files for the first time, the PDF reader is added which grows the project file with about 6MB. Looks looks like it took 20 minutes to send that. 

The resources.ifr is the file that include your PDF files. Looks like it takes about one and a half minute to send, so it is not huge files in your project. What I don't understand is why it gets stuck on calculating checksum. 

There is no progress indication while checksum is calculated, but it shouldn't take that long. 

I let it sit in that Calculating checksum phase for 20-30 minutes each time before resetting power.  I'll try a firmware update without PDF files next.

Hi,

We're having the same issue as above with sending the project file with the G11 taking a long time. It seems that every time we modify/add/remove a PDF from the project takes 1+ hrs to send.

We did a test which seems to support this:

Test 1: Send project (which includes several PDF) over ethernet to MD4.

Result 1: <30s

Test 2: Send same project with G11 to MD4

Result 2: <1min

Test 3: Remove 1 PDF file from project file. No other change. Use G11 to send to MD4

Result 3: 1+ hr

Is this typical behavior? Any insight would be great.

Thanks.

When the update is sent, it is split up in a number of different files. If you for example change the application logic, and keep the same software version, fonts, images and pdf files in the project, there is only a relatively small file to send. 

The pdf:s you add to your project are combined in one file, so if one pdf is removed from the project, that changes this file, and it has to be sent again. 

Test 3 above froze on the checksum. 

I also have not been successful without it freezing on ->Calculating Checksum using the G11 dongle. 

It seems strange that you are both getting consistent problems with the MD4 getting stuck on the line where it is calculating checksum when projects with updated PDF:s are sent via G11. Investigating.

I have a remote client who is having the same problem onsite. They have 3 identical systems, MD4-7 (Master), LC5, G11, XC23, and 2x XA2 modules. I've sent them a program update (26,072,470 bytes), and they've been successful in updating only 1 of the systems. This system updated easily, in about 5 minutes. The other 2 systems get stuck on the Finalizing (App), and Calculating Checksum (MD4-7). They are unable to revert back to the previous software, as the the same thing happens. They now have 2 expensive paper weights, and 2 of their drilling systems are completely inoperable. The job site is nearly shutdown because of this.
We've tried both iQanSync, and iQanGo for the attempted uploads through the G11 modules (bluetooth), on both Android, and iOs devices. We've updated the Firmware on the G11 modules in another attempt. Same results. 
We have no PDFs in the .idax files.
Please help.

Whenever we add images to the project file, we are also running into it freezing on "Calculating checksum" every time when trying to do the update with the G11.

Still investigating, but to give a small update, we've managed to reproduce one situation situation when the MD4 gets stuck at calculating checksum for the updated pdf:s. 

So far, it has only been when making a local update via the app that it has been possible to reproduce. (copying the file to the phone and using the send to machine function). 

Interestingly, when instead trying the exact same update as a remote update via IQANrun-IQANconnect-IQANgo-G11, it has not been possible to reproduce. 

Update: there will be a new G11 firmare included in IQANgo 6.03 to fix this. 

The release is about two weeks away. 

IQANgo 6.03 is now released for Android and iOS, with IQAN-G11 firmware version 1.11 to solve this issue.

https://forum.iqan.se/knowledge-bases/2/articles/2538-software-news-iqango-603