Jump to content

jdsommer

Members
  • Content Count

    10
  • Joined

  • Last visited

Community Reputation

1

About jdsommer

  • Rank
    Active

Profile Information

  • Gender
    Male
  • Location
    U.P. Michigan
  • Interests
    HDF5
    LabVIEW - C interfacing
    Xnodes
    Python
    Electric spacecraft propulsion

Contact Methods

LabVIEW Information

  • Version
    LabVIEW 2011
  • Since
    1998

Recent Profile Visitors

466 profile views
  1. 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 AdaptToInputs. (Note that DWarns normally only show during the *next* launch of LabVIEW, but with appropriate .ini magic they can be made to appear immediately.) A second effect is that, while the xnode generates mostly correctly, the terminal in question does not become a typedef, but a matching type that is not typedefed (U16 enum, in my case, with all the right items). This sent me on a long goose chase trying to figure out why some typedefs worked, and others didn't. It turns out, that the typedefs that worked were being used somewhere in my xnode ability VIs, while the ones that did not work were only used on the template VIs, but not in the xnode ability VIs. I dropped a typedef constant of the otherwise-unused-in-ability-VI typedef into my GetTerms ability VI, and voila, the DWarns stopped appearing. Problem solved. Analysis: I think we know that ability VIs run in a different instance of LabVIEW from the one into which the xnodes are dropped. I don't hold open a reference to my template VI throughout the ability VIs. (IIRC, I tried this and had numerous problems.) I open it for Initialize to find the term info which is shoved into State.ctl. When GetTerms is called, I simply get the terms from State.ctl and return them to the output. I open the template again in GenerateCode.vi. Therefore, there may be no reason for the xnode instance of LabVIEW to have my typedefs open in memory at the point that GetTerms is called. By placing the typedef into GetTerms we force LabVIEW to have it open and solve the problem. Here's hoping this helps someone else in the future! Jason
  2. 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 ModifyCode.
  3. 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 GenerateCode respond with ModifyCode. I was wrong. All this does is a) Not call ModifyCode and b) Cause LabVIEW to throw a DWarn on exit. Perhaps some more experienced xnoders have some insight as to why what I tried didn't work. In any case, I resolved it by having GenerateCode directly call ModifyCode rather than just responding.
  4. @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 try out the toolkit, even just for fun, I'd appreciate any feedback you might have.
  5. 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.
  6. @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 tools (like, 64-bit LabVIEW, for instance ). Regarding TDMS, I honestly don't know a lot about it, but I think you hit the nail on the head with your phrase, "it's better if you're going to stay in the NI world." You might not. My general impression is that HDF5 is much more flexible, but the flexibility comes at a bit of a performance hit in terms of streaming data. Because of the interoperability and open nature of the HDF5, I would choose it over TDMS unless I needed absolutely needed the speed. Of course, I'm also biased, having put 8 years (on and off again) into the toolkit. @PiDi: Xnodes over polymorphic. It really is not possible to use polymorphic VIs in this case. The library can handle nearly any datatype that you throw at it. Particularly when you start enumerating cluster types (was it a cluster of two doubles and an integer, or one double and two ints, or something else?) it is absolutely impossible. As the toolkit developer, I can't predict ahead of time every datatype that a user might try to shove into an HDF5 file. For the most part, the polys are used simply as means to pass any data type through to the DLL which does the main work. I would have chosen another path besides Xnodes, but it was really the only option available. @JKSH: I've looked at h5labview's code and, while it is generally similar, I believe that my code is more likely to work with a wide range of datatypes. I have particular concern about its ability to handle strings inside of clusters--a corner case, to be sure, but one which my toolkit does handle. I'm also unclear on h5labview's ability to read and write complex selections. However, the primary difference between the two toolkits is the completeness of the interface, as I mentioned above. There may be a few functions that have been added since HDF5 1.6, that I haven't implemented, but nearly every library function that can be called is exported. Also, I provide a number of higher level tools that are not included in h5labview, such as the ability to read and write a dataset and all attributes in one VI which I find to be useful. All that said, I have not really given h5labview a fair shake, and I don't want to disparage Martijn's work. It requires a deep level of knowledge of LabVIEW datatypes to make anything like this work at all. The fact of the matter is, since I'm going to be biased towards my own toolkit anyway so I'd prefer to have someone else do the comparing and contrasting. As a final note, the reason that the two cannot be installed simultaneously is that we both have chosen some obvious names like "H5Dread.xnode." If your calling VI loads the xnode from the wrong toolkit, then all kinds of broken wires ensue. LabVIEW libraries (.lvlib) were supposed to handle make this better by providing a namespace, but, correct me if I'm wrong, xnodes already are a LabVIEW library and, thus, cannot be put into one.
  7. 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 on the xnode-related pages pages for the past three or four years while slowly building up this revamped toolkit. It would not have been possible without their efforts.
  8. Okay, its fixed. Sorry for the hassle. Jason
  9. 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/ I hope you find it useful! Jason
  10. 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 then one in an external VI using the NumText.Text and UnitLabel.Text properties. The basic idea was to write the data in text form in, and then read the PQ out with the value property. This doesn't work because one is not allowed to change the base units of a control via these properties, apparently even if the VI containing the control is not running. So, at the moment I'm contemplating writing my own unit parser (or finding one already written), but this seems redundant to what is obviously included in LabVIEW, somewhere. Am I missing something really basic somewhere? If not, does anyone have any brilliant ideas? I'm using LabVIEW 7.1, so if there's anything cool in LV8 that would help out, I'm unaware of it. Thanks, Jason
×
×
  • Create New...

Important Information

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