jdsommer Posted January 3, 2021 Report Share Posted January 3, 2021 (edited) It's been a long time coming, but I've updated my HDF5 toolkit. I'm preparing to put the update out on the NI Tools Network soon, but I'd like to go a little slow on the release, so I thought I'd announce it here first. For those unfamiliar, HDF5 is a binary data format widely used in the sciences. It's similar to TDMS in some ways, but more flexible and less proprietary. Keeping up with the ever changing ABI of the underlying HDF5 library has been a losing battle, so I quit a long time ago and accepted that Live HDF5 would most likely only work with the version of HDF5 it release with. (Fortunately, while the ABI changes a lot, the file format itself has always been backwards and mostly-forwards compatible.) Some features in version 1.12 of HDF5 were very attractive to me and prompted the update. The update also provided a chance to weed out some long-standing bugs. The toolkit may also be of interest to those who like playing around with Xnodes. https://www.upvi.net/main/index.php/products/lvhdf5 Edited January 4, 2021 by jdsommer Fix image Quote Link to comment
X___ Posted January 4, 2021 Report Share Posted January 4, 2021 Are you forcing a conflict with Martijn Jasperse's H5labview package, or is this something made up by VIPM? Quote Link to comment
jdsommer Posted January 4, 2021 Author Report Share Posted January 4, 2021 I am forcing a conflict. The toolkits do, in fact, conflict, and always have. We both chose very obvious names for the VIs and were created before lvlibs were popular (or maybe even implemented). Mine is further complicated by the use of Xnodes. Quote Link to comment
ensegre Posted April 6, 2021 Report Share Posted April 6, 2021 (edited) A project benefiting from HD5 data saving came up to me, so I'm looking at your package. For now nothing beyond just dumping some heterogeneous datasets into a single file, but I'm already having a few issues. All together your package looks so well invested into, so I think there is point in reporting them, and ask for assistance. I've been trying 1.1.1.86 (offered by VIPM) and 1.2.2.5 (your link). Single dev machine for now. LV20.01 32bit, Up/Downgrading between the two is not completely flawless, sometimes VIPM fails, but nothing that can't be solved with restarting LV a few times and clearing the compile cache. My issues: I have something working in the IDE, I can build it into an exe, but the exe is broken-arrowed. Pressing the arrow I get a dialog with a long list of "missing external function h5helper.dll". hdf5.dll and hd5helper.dll get copied into the built application data/ directory though. What am I missing? I made a minimal snippet and a more real VI using v1.1.1.86, both work (modulo some lack of understanding on my part about why certain datasets need to be declared as Unlimited etc., but whatever for now). However: the "real" VI (having some event structure, shift registers and a bit of other code) is very sluggish when being edited. I would tend to blame the fact that so many calls (essentially Simple HD5write) are Xnodes. If I upgrade to v1.2.2.5 and open the "real", in the IDE, I get Error 1055 complaining about invalid references. The thing goes on compiling and opens as white-arrowed, but if run, it fails in writing one of the datasets (not the first, by chance). I'm afraid I'd have to unwire and rewire it all again in order to convince shift registers to update stale references or something the like, Xnode weirdnesses.... If I end up with an opened hd5 file (e.g. because my writing chain errored somewhere), it stays locked till I quit LV. It seems that Close HDF5 File (HF5Close.vi) even with Force close=true cannot against it (modulo that I understood something wrong...). I can't either replace the file with LV, or delete it from OS. Open/Create/Replace HDF5 File, with argument "create or replace", when called on an existing filename still offers an "open" button in the dialog, which is wrong logic, imho. That in both package versions, though. Your comments highly appreciated! Edited April 6, 2021 by ensegre Quote Link to comment
ensegre Posted April 6, 2021 Report Share Posted April 6, 2021 (edited) The LV error of point 2. above, BTW. on the second HD5write (create) of the chain, the first succeeds, apparently. Error 402760 occurred at Check Object Existence.vi Possible reason(s): An HDF5 Error Occurred Major: H5E_ARGS (Invalid arguments to routine) Minor: H5E_BADTYPE (Inappropriate type) invalid location identifier Complete Call Chain: Check Object Existence.vi OpenCreateReplace Dataset.vi Simple OpenCreateReplace Dataset (Variant).vi Simple H5Dwrite (Variant).vi Edited April 6, 2021 by ensegre Quote Link to comment
ensegre Posted April 6, 2021 Report Share Posted April 6, 2021 Ok. For most of the points, I'm feeling a bit dumb now that I searched for it..... 6 hours ago, ensegre said: I have something working in the IDE, I can build it into an exe, but the exe is broken-arrowed. Pressing the arrow I get a dialog with a long list of "missing external function h5helper.dll". hdf5.dll and hd5helper.dll get copied into the built application data/ directory though. What am I missing? https://www.upvi.net/main/index.php/products/lvhdf5/lvhdf5-forum/11-standalone-exe-doesn-t-work#18 Quote the "real" VI (having some event structure, shift registers and a bit of other code) is very sluggish when being edited. I would tend to blame the fact that so many calls (essentially Simple HD5write) are Xnodes. If I upgrade to v1.2.2.5 and open the "real", in the IDE, I get Error 1055 complaining about invalid references. The thing goes on compiling and opens as white-arrowed, but if run, it fails in writing one of the datasets (not the first, by chance). I'm afraid I'd have to unwire and rewire it all again in order to convince shift registers to update stale references or something the like, Xnode weirdnesses.... Write 100 times: Thou shall not use "Use Default If Unwired" for references Thou shall not use "Use Default If Unwired" for references Thou shall not use "Use Default If Unwired" for references ....... https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z0000019L75SAE Quote If I end up with an opened hd5 file (e.g. because my writing chain errored somewhere), it stays locked till I quit LV. It seems that Close HDF5 File (HF5Close.vi) even with Force close=true cannot against it (modulo that I understood something wrong...). I can't either replace the file with LV, or delete it from OS My coding mistake, I thought I was calling HF5Close when I wasn't. And closing the containing project was sufficient to remove the lock anyway. Sorry for the noise, I hope it may help someone else in future. Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.