07-24-2024 05:13 AM - edited 07-24-2024 05:21 AM
Hello everybody,
When reading a waveform in a binary file, this error is raised: LabVIEW: (Hex 0x7A) The resource you are attempting to open was created in a more recent version of LabVIEW and is incompatible with this version.
However, the LabView version of the program that writes data and the program that attempts to read are the same: LabView 21.0.1f6 (32-bit).
The only subtlety is this:
- the PC I am using to read data is the "development PC" with the full LabView project. I am attempting to read the data in the LabView development environment.
- the PC that writes the data uses an executable version (installed with its package) with builds generated in the "development PC" (using the same LabView project).
Therefore I do not understand why the version should differ, being the builds deployed in the "data writer PC" from the same LabView version of the development PC that attempts to read.
I checked for updates in NI Package manager and there were none.
The binary writer and reader (in attachment) are very simple.
I just use binary write/read of an header string and a waveform.
The error is raised when attempting to read the waveform.
I read in other posts (such as this one https://forums.ni.com/t5/LabVIEW/Why-is-a-flattened-variant-different-in-LabVIEW-2012-and-LabVIEW/m-...) that LabView changes the variant in every version, so since the waveform type definition includes a variant, this may cause the problem.
In principle, I could solve this issue by manually decoding the vaveform data, without looking to the variant, however I want to pursue this solution only as the last resort.
What puzzles me is that the LabView version is the same in my case.
Another bit of information is that I am still able to read data taken some months ago (probably prior to updating to LabView 2021 patch f6).
Any chance the issue could be related to the LabView RunTime?
I attach the Dependency form the Package Properties.
Solved! Go to Solution.
07-24-2024 06:40 AM
@StefanoD wrote:
Any chance the issue could be related to the LabView RunTime?
You will need to confirm this, but the scenario that immediately entered my mind is as follows:
1. You built the application with the "Allow future RunTime Engines to run this application" (or whatever the text exactly is).
2. You have another application or driver on the deployed machine that uses a newer RTE.
3. Given 1 and 2, your application will run in the newer RTE, making your development PC unable to read the variant.
You just have to fix 1 or 2. The simplest is 1 in that you just uncheck that build option, rebuild, and deploy.
07-24-2024 07:11 AM - edited 07-24-2024 07:13 AM
Thanks for the quick feedback crossrulz.
Indeed:
1. Right, the build was with that option, which is enabled by default
2. Yes, besides the LV RunTime 2021 SP1 f6, also a 2023 Q3 Patch 1 was installed somehow.
I have re-built the application without the option and waiting for new data to be acquired by the team.
I will let you know the result.
In any case, would you suggest to uncheck that option for new projects? What would be the benefit of using a newer RTE, considering that the package installer comes with its own?
07-24-2024 08:28 AM
@StefanoD wrote:
In any case, would you suggest to uncheck that option for new projects? What would be the benefit of using a newer RTE, considering that the package installer comes with its own?
It is one of those features we thought we really wanted, but found it often causes problems. My current recommendation is for applications to have that option turned off. I still have it enabled for my Packed Project Libraries, which will then use whatever RTE version the application using them uses.