I am working on a project that involves using the digilent analog discovery 2 to act as a an input and output for a VI in LabVIEW. I have downloaded the Adept and Waveforms software to communicate with the discovery 2 and LabVIEW. In this VI, I am getting an error number 1097, which has to do with the call library function. The error is in an attached photo. I have tried the suggested fixes online but have not found one to work for me. The error does seem to occur at the sub-VIs I downloaded from National Instruments, built to work for the discovery 2 in LabVIEW. When I open the call library function of the sub-VI that seems to raise the error, I see the attached images. Does anyone know if the set values are correct or if I need to change something? I am hoping that the error may be fixed by changing one of the parameters or options listed.
Labview Call Library Function Node 1097
You can untick the automatic box and increase the samples, but you will likely be encountered with an error that says the system may not perform as you expect; be sure to the click the "Use Anyway" button rather than the reconfigure. When I first clicked reconfigure, an error kept popping up saying the system couldn't run (or something similar) every time I closed the error, effectively softlocking me out of LabVIEW and forcing me to use the task manager to shut down LabVIEW. The "use-anyway" option let me run the VI and did work as expected, but as I was warned by LabVIEW, the system definitely did slow down when the VI was running. You can slow down the sample rate from 250 MHz, though I don't know how much that will impact your intended application (especially at higher frequencies). So not an AD2 problem per se, but more of a limitation with what sort of configurations have been implemented into the VI's (since the VI's just call existing WaveForms SDK functions).
As LabVIEW developers, we are comfortable developing in LabVIEW. However, sometimes we need to leverage code from other languages. This is where DLLs come in. For those of us that are less than comfortable with coding languages outside of LabVIEW, using DLLs can be daunting and frustrating. The Import Shared Library Wizard can make your life easier, however, it is not very reliable when using custom data types. This forces us to use Call Library Function nodes (CLNs) for DLL calls, which can bring up a whole bunch of problems with no intuitive debug strategy.
I am trying to install the h5 library, but I am getting the following error. Main Package Name: Hierarchical Data Format (HDF5) v2.13.1.143 Package Name with Error: Hierarchical Data Format (HDF5) v2.13.1.143 Error Message: VIPM could not install the package h5labview2-2.13.1.143 . Error Code: 7 Error Source: PostInstall.vi Could not load HDF5. Ensure HDF5 v1.8.13 or newer installed. =============== I am tried it for LabVIEW 2019 32 and 64 bit. In both I am getting the same error. How...
Hi Scott- did you get anywhere with this? I'm keen to build h5labview for MacOS too, and have just come back to this since first looking at it last July...! I'm utterly clueless on building "real" (non-LabVIEW) software, however I note your commands were building a .dylib- but the library path constant in the VIs is looking for a .framework. And inspecting the Windows makefile, I see it Includes the LabVIEW cintools. -but beyond that, I have no idea what I'm doing... Any guidance much appreciated!...
For our project we save some hdf5 attributes, and to make this more generic we create key value pairs where the value is a variant. So writing the key value pairs to the HDF5 file works fine and I also get to see the correct datatypes when I open the HDF5 file in the HDF5 viewer, but when I try to read an attribute which has data type boolean, I get an error. When I dig deeper in the code I see that an error occurs in the Query Type vi, which calls the H5LVget_type method in the library. this dll...
In running on MacOS it seems to not be a big issue. I have installed the HDF5.10 (using the package manger "Fink") and in running the gcc compile for linux with appropriate flags, I can build the dylib. % gcc -c -fPIC -I /opt/sw/opt/hdf5.v1.10/include/ -I /Applications/National\ Instruments/LabVIEW\ 2020\ 64-bit/cintools h5labview.c -o h5labview.o % gcc -dynamiclib -undefined suppress -flat_namespace h5labview.o -o h5labview.dylib Is it simple to link the call library functions to this new dylib?...
I'm new the the h5labview library and am working on creating a data storage method where I am collecting images and other data in a streaming fashion. Ideally I would like to save each bit of data as a row in the hdf5 file i.e. Timestamp, X, Y, Z, I, J, K, image Where the majority of the data is just either a float or int, and then the image data attached to each data write / index if think of it as an array. I have review the save image example and can follow that such as I can save single images...
Almost certainly it's due to memory alignment. There are differences "under the hood" between LabVIEW on different operating systems which matter for efficient data IO as is used in this library. To avoid such problems requires costly/slow datatype conversions getting data in/out of the library, but on the other hand it can cause a lot of crashes in getting it right. The relevant documentation is here: -XX/help/371361R-01/lvconcepts/how_labview_stores_data_in_memory/,...
Thank you for your reply, this has given me some more insights on how to do this. So after a rollercoaster ride of trying to build the HDF5 library and modifying the make file to build your library on Linux, I have finally made some progress, but i'm also running into a few issues. I've added the build HDF5 library, the h5labview.so file and the makefile to this post, so if you want to use them, they are probably ready for all the NI RT Linux devices that have an x64 processor When I tried to run...
Thank you for your reply, this has given me some more insights on how to do this. So after a rollercoaster ride of trying to build the HDF5 library and modifying the make file to build your library on Linux, I have finally made some progress, but i'm also running in a few issues. I've added the build HDF5 library, the h5labview.so file and the makefile to this post, so if you want to use them, they are probably ready for all the NI RT Linux devices that have an x64 processor When I tried to run the...
Hi, Sorry I must have missed the notification on this one. I presume all that is required is a working GCC setup but I don't use OSX so I'm not sure what that involves on that system. The LabVIEW part is called "cintools" in your install directory which needs to be linked against the h5labview library. You should be able to find some information from NI about setting up a build environment relevant to you (check the documentation for Code Interface Node). It's possible that LabVIEW for Mac has some...
Oh, yes. H5close should never be used directly :) It is a last resort to force library cleanup in the case of memory leaks, but it should not be required in normal use. Every HDF call will fail until the library is explicitly reinitialised, which again should not be done directly.
Hi Martijn, I think I found the reason for this problem: it's me! :) I dropped a vi that calls H5close() directly on a location in my code that has nothing to do with hdf5 and forgot it there. This bypasses the h5labview-dll and seems to leave it in a corrupted state long before using hdf5-functions intentionally. After removing this vi, it worked fine. Sorry for all that noise and thank you... Christian
Hello! I got problems writing attributes with strings as content. The library in use is h5labview2-2.14.1.146. It is no problem writing integer, floats, or arrays of those but no strings. The error message is "Error occurred but no information available.". The attribute's datatype is created properly. The attached picture shows a tiny example to test this. Did I use it wrong or is this a bug? I'm quite shure that this worked before. I guess the error occurs in line 536 in readwrite.c but I'm not...
Hi- Noting your comment: Does h5labview work on OSX? Possibly. No developers have access to OSX and therefore cannot conduct testing. Some users have had success compiling h5labview on OSX systems, but it cannot be supported at this stage. I wonder if I could get in touch with anyone who has had success, and get some tips...? I'm impressed with the clean-ness of the h5labview VIs over LiveHDF5's (even their icons are ugly!), so I'd really like to get your library built on the Mac rather than theirs...
I started writing h5labview back in 2011 as part of a lab control and monitoring system for my PhD work. It was never intended to be the end-all solution to data storage, but provided a useful subset of the full HDF5 functionality. As HDF5 has matured, its functionality has expanded and some of that was supported in h5labview. However, I haven't been an active LabVIEW user since 2016 and no longer have interest in developing it further. However I may still do maintenance updates for some issues.... 2ff7e9595c
コメント