Copyrighrt (c) 2014-2020 UPVI, LLC

Xnodes vs. Polymorphic VIs vs. Malleable VIs vs. Variants

Last Updated: Sunday, 03 January 2021 Published: Saturday, 02 January 2021
Written by Jason D. Sommerville

A question I am frequently asked is "Why do you use Xnodes in the Live HDF5 toolkit?" It's usually followed up with "Couldn't you just use Polymorphic VIs or Mutable VIs?" In short, the answer is "No." In this article, I'm going to explain why.

If you're wondering, "What is an Xnode?" the answer is that it is a mechanism introduced in LabVIEW 8 that allows the creation of a special, scriptable node. One can use LabVIEW scripting to generate LabVIEW code when a node--an xnode--is dropped on the diagram. They allow for the creation of LabVIEW code that, among other things, responds to the wired input and output terminals of the node. For more info, I will point the reader to the LabVIEW Wiki. Xnodes are not and never have been a supported feature of LabVIEW, and so using them is, perhaps, not the best choice for a toolkit that is intended to be stable. But, they are also the only way to achieve one of the main goals in the Live HDF5 toolkit: the toolkit should be able to store any LabVIEW datatype and read it back. This is not completely achievable, (though close, as I will show). It is therefore desirable that the toolkit should inform the programmer at compile-time rather than at run-time if it is unable to handle the datatype. To summarize, we have two objectives:

Read more: Xnodes vs. Polymorphic VIs vs. Malleable VIs vs. Variants

LabVIEW Error Handling, DLLs, and Threads

Last Updated: Saturday, 02 January 2021 Published: Saturday, 12 December 2020
Written by Jason D. Sommerville

Version 1.2.1 of Live HDF5 was a major pain to create, but it addresses a problem that has existed in Live HDF5 since the beginning. The problem is that in the LabVIEW threading model multithreaded DLL calls can happen from any of LabVIEW threads in the execution system under which the calling VI is running. Unfortunately, many external libraries, including a few minor ones like, say, the Windows API, and, of course, HDF5 use thread-local state data to keep track of errors, among other things. The net result of this is that if a Call Library Function Node (CLFN) is configured to run in any thread, and the function generates an error, and a second function call is required to retrieve the error information, there is no guarantee that the error retrieval call will be called by the same thread as the first. In the event that the error retrieval does not happen in the same thread, improper error information is returned. The example below, shown calling the (deprecated) Windows API function OpenFile demonstrates this. (Why would you ever want to implement OpenFile like this in LabVIEW? I have no idea. That's not the point.)

Option 1 (wrong): Thread-local errors in external code can't be handled properly

Read more: LabVIEW Error Handling, DLLs, and Threads

Saving Data -- Text Files

Last Updated: Wednesday, 24 September 2014 Published: Wednesday, 24 September 2014
Written by Jason D. Sommerville

The First Entry

Welcome to Article 1 of the UPVI Blog! I intend to use this space on a bi-weekly basis to gush forth on a variety of issues in the field of data acquisition, analysis and control that I have come across over the years. I'm not going to claim that anything written here will be revolutionary, but it is my hope that struggling developer or student may wonder across this site and their work will be a little better for it.

Given that I am launching my company with the release of version 1.0 of the LVHDF5 toolkit, I thought it fitting to spend the first few articles discussing data formats for saving scientific data. While I would love to regale you, dear reader, with the wonders of HDF5, I found it best to start as simple as possible. That leads us straight away to...

Storing data in an ASCII text file

Pros and cons of ASCII

Yes, ASCII text. It's old. It's trusty. Everything can read it, even Excel, even Notepad. You can give your data file to a complete stranger and, at the very least, they'll be able to figure out how to look at the numbers inside of it. It's been working for over 50 years, and, if I had to guess, it will be working for another 500, barring a return to the Dark Ages. It always works--maybe not well, but it always works. That is ASCII's only advantage, but it is a huge advantage that should not be lightly disregarded.

Read more: Saving Data -- Text Files