From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
09-23-2020 05:48 AM
Dear community
I am again struggling with a translation of a .NET call in NXG 5 compared to LV2020
I just make one call to get the lib version of the library.
When I do this in LV2020 all is fine and the values are shown correctly.
When I do the same with the *.dni integration in NXG5 the call does not return an error (so all seems to be fine) but the lib version is not
filled with the expected values.
I have attached the vi from LV2020 and also the project from NXG5.
this is related to the following thread to find the used .net assembly.
https://forums.ni.com/t5/LabVIEW/NXG-5-quot-Big-quot-dni-chrash/m-p/4082783#M1174633
Thank you for your valuable input.
09-29-2020 02:04 AM - edited 09-29-2020 02:08 AM
Hi Gernot,
I believe the issue you are facing is that the hdf5.dll file is not being found by HDF.PInvoke.dll (which is registered in GAC).
Here is the MSDN page explaining the locations (and the order) where the runtime finds for the DLLs. As per the details in this page, I copied all the files from "HDF5 NET\HDF.PInvoke.1.10.6.1\build\bin64" folder in your attachment to my "C:\Windows" directory. Once I did this and ran the VI, I got this result.
Regarding the issue of no error being thrown, that's a bug and should be fixed in the upcoming version of NXG. Sorry for the inconvenience.
Hope this helps.
09-29-2020 04:45 AM
Hi Sujay Narayana
I think I am to stupid to solve my issue.
I did what you suggested and then even i checked via process explorer if the HDF5 dll is loaded.
The result is fine (see here)
I did this on two computers, both are running LV 2020 x64 and NXG5 with the same result that the call does not result in the same way as you has shown above.
My version numbers are always zero.
Do you have a further suggestion ? I added the H5Pinvoke to the GAC using the Visual studio 2019 GACUTIL and it is located in "C:\Windows\assembly\GAC_MSIL".
I copied the other files to c:\windows (the plain files HDF5.dll, HDF5_Hl.dll, szip.dll and zlib.dll).
Please can you also tell me if in your case it also solves this eventually related issue ?
https://forums.ni.com/t5/LabVIEW/NXG-5-quot-Big-quot-dni-chrash/m-p/4082783#M1174633
Thank you for your very useful help
10-01-2020 03:03 AM
Could you create an indicator for the "error out" terminal of "get_libversion" call and see if there is any error reported? I tried again on another clean machine with NXG 5.0 installation, and your attached VI worked fine for me.
Some things to check:
My NXG 5.0 build number was 8.1.0.50414. In case yours is older, please update from the NI Package Manager utility.
10-01-2020 03:10 AM
After doing this, the other issue still happens in NXG 5.0 unfortunately. When I selected all the namespaces/classes and try to save the DNI, I get this error - "H5.dni failed to save. The given path is not valid."
I have created a bug (ID: 1132272) for this issue so that we can fix it in the next version of NXG.
10-06-2020 01:39 AM
Hi
I am really sorry but I am not able to make it working.
I have the same NXG version as you stated.
When I remove the HDF5.dll from the windows directory i have a nice error.
So it seems to me the HDF5.dll is on the right place and the call is "fine" but the expected result isnt.
It is interesting that calls to create a file (H5F create) gives correct pointers and also the file is created and closed.
So in this case it seem to be OK but in the (get_lib_version) there is something going wron on my system.
I think I need to wait for the next version when hopefully the other problem of adding the Items to the *.DNI is solved.
Because there are many calls neccesary which are not able to call due to the "related" problem with the (ID: 1132272)
Greetings from Austria