Jump to content

jdsommer

Members
  • Content Count

    12
  • Joined

  • Last visited

Everything posted by jdsommer

  1. 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.
  2. 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. (
  3. I've spent two weeks banging my head against this problem and finally found the solution. I thought I'd post it here for posterity. I have a set of xnodes (in the Live HDF5 toolkit) which are based off of the common use-template-VI-to-generate-diagram-code paradigm. I recently added a number of typedefs into the template VIs. After doing so, when placing or editing the xnodes, I received the following dwarning Internal warning 0x0 : "xstuffprivate.cpp", line 2211 LabVIEW Version 11.0.1 but only for certain typedefs. The warnings occurred after GetTerms was called and before AdaptT
  4. Yup, you've got the main idea of ModifyCode, so far as I'm using it anyway. Since I've got xnodes in xnodes in xnodes, completely regenerating the nodes was taking an irritating amount of time. In my case, ModifyCode simply handles type repropagation after AdaptToInputs if the code has already been generated. I also keep track of whether or not the VI has been generated and use that to trigger whether to call Modify or Generate from AdaptToInputs. I suppose having some conditional code in Generate also would have worked. I just didn't think of it, perhaps being misled by the existence of
  5. This is about a problem that I had with xnodes and its resolution, just any case some other poor sap finds themselves in the same situation. There may be others that have done more research on xnodes that are aware of this, but I didn't come across any info when searching. In a set of xnodes I recently created, I attempted to have ModifyCode called immediately after GenerateCode. The last step of GenerateCode, in my case, was always going to be identical to the complete step for ModifyCode. Since GenerateCode has a Response output, I thought a nice clean way to do this would be have Genera
  6. @JKSH: I've rarely found that any one project requires a wide array of datatypes. However, I have found that very few projects seem to require exactly the same datatype as a previous one. This is in part because I generally find the most natural representation of data that I acquire and process an array of clusters, (which translates to datasets of compound element types in HDF5). No two cluster types are usually the same. When I set out to build this toolkit (actually, the original version 0.9) I wanted to make a toolkit that would work for any project. In any case, if you get a chance to
  7. It's sounding like I should try to put the xnodes into a library, but go cautiously. Of course, that's probably good advice any time one is dealing with xnodes! In any case, I'll consider it for the next revision. In the meantime folks will just have to uninstall h5labview to use my toolkit.
  8. @hooovahh: Yes, h5labview is similar. Version 0.9 of my toolkit which did not use Xnodes, but some horrid flattening of variants was started long before h5labview, and appears to have been the inspiration for Martijn. While I should have been aware of h5labview, I was not, and worked independently. Naturally, I'm biased, but my toolkit provides nearly complete access to the library and a number of useful utilities besides, so I think it's better. On the other hand, h5labview works with 64-bit LabVIEW, a failing I'd like to remedy in my toolkit. However, I don't currently have access to the too
  9. It's been a long time in coming, but I have completed a new version of the HDF5 Toolkit for LabVIEW that was first released in 2006. The aptly named LVHDF5 Toolkit (version 1.0) is a hefty redesign of the original toolkit (version 0.9) and should solve most of the performance issues with that library while maintaining the flexibility of the the original design. The toolkit is free to use but does have restrictions on redistribution. http://www.upvi.net/main/index.php/products/lvhdf5 In particular, I'd like to thank the members of LAVA who worked on xnodes. I've been lurking o
  10. Okay, its fixed. Sorry for the hassle. Jason
  11. I have been developing a new HDF5 interface library for several months, and have finally managed to get it adequately packaged for distribution. I didn't find the NI-provided library to be sufficiently easy to use, or sufficiently complete for my needs. So, I've been developing my own. At this point, it is essentially complete, and I have been successfully using it in my research for several months. However, it should still be considered beta quality. It is available for Windows and Linux. Further details and the library itself may be found at: http://www.me.mtu.edu/researchAreas/isp/lvhdf5/
  12. I'd like to be able to scan a physical quantity from a string that contains a number and a unit string. Basically, the user should be able to input "2.36 mtorr" or "20 Pa" or whatever and my VI be able to parse that and convert it into the appropriate physical quantity datatype. The base units can be specified at compile time. I thought this was going to be relatively easy, but I'm walking down ever more complex roads. First off, Scan from String does not work as the unit specifier only is valid for Format into string. My other attempt was to print the data into a control, first local, and
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.