IMAQdx 14.5 breaks compatibility with IMAQdx 14.0?

[JKSH]

Hello,

I deployed an application that used IMAQdx 14.0 to acquire images from a GigE camera and save them to disk. Nothing fancy.

Recently, I upgraded my development PC to IMAQdx 14.5. As a result, the executables I create no longer run on the same deployment PC, even though I didn't change the code:

 

Upgrading the drivers on the deployment PC removed the issue.

Is this inteded? I would've expected things to still work, since I'm only using features that were already present in IMAQdx 14.0. (In contrast, DAQmx retains backwards compatibility: I can have DAQmx 14.5 on my development PC, while deploying to a PC that has DAQmx 14.0 drivers installed)

[BlueCheese]

Hi,

The behavior of being able to develop an app with a newer version of the driver and then deploy to a system with an older version of the driver is by no means guaranteed, though sometimes it does work. Often times new functionality is introduced such that it cannot still work with older versions of the driver.

I believe you are running into an expected failure here (though the error code you see seems not what I would expect). I think the Get Image VI was updated with some new typedefs in 14.5 (for new buffer modes) and so it does not retain compatability with the older one. If you develop an app using the 14.5 version of Get Image, I think it intentionally won't load on the 14.0 driver.

Note that the reverse is always expected to work. An application developed with the 14.0 driver should remain compatible with a system using the 14.5 version.

Eric

[JKSH]

Thanks for clarifying, Eric.

Is there there a formal policy on driver updates? This info would help us manage our toolset versions. For example, LabVIEW has a policy where LabVIEW 201(x) SP1 is a bugfix/stability/performance release only, while LabVIEW 201(x+1) can have new features. I had assumed that IMAQdx 14.5 was also be a bugfix/stability/performance release for IMAQdx 14.0, but it looks like that's not the case.

For my current case, the customer is currently field testing the device in another city, so I've rolled back my development machine to IMAQdx 14.0 for now (since I can't have 2 versions co-existing, and I don't want him to upgrade drivers on-site).

[BlueCheese]

Good question. I'm not so sure the various drivers have such a strict policy the same as LabVIEW. I think some drivers even have large feature changes intentionally off-cycle from LabVIEW.

[BlueCheese]

I'm not sure this is the best option for a workaround, but if you wanted, you could copy/rename the Get Image Vi from your 14.0 install and build it into your app with 14.5. The resulting binary should deploy just fine to 14.0 systems in that case.

[SamiBenF]

Hi,
When a vi is modified in a way that it would basically modify the way it is linked to callers for instance, don't you usually proceed by renaming it (something like Imadx Get Image2.vi) and keep the old one in some compatibility library so that the old code can still be maintained ?

[BlueCheese · Accepted solution]

Yes, absolutely. In 14.5 there is a new Get Image2 VI that is the one on the pallete and has some new functionality. The old Get Image VI with the existing functionality still exists in the library as well. The reason for the breakage is that they both use the same Buffer Mode enumeration typedef, but the old entrypoint used by Get Image didn't handle the new enumerations properly. The updated Get Image VI in 14.5 (for compatibility) links into a "fixed" entrypoint that handles all the new modes as well.

In general, any old VI code is expected to load/run identically between 14.0 and 14.5, and new code developed with 14.5 (using new Get Image2 from the palette) would have new functionality as well. The one broken case is if you built an EXE with 14.5 and then tried to deploy to a system with 14.0. Given that you could have unexpected runtime failures due to differences in functionality, we took a route that prevented this from deploying at all.