Bug in Cont Acq&Graph Voltage-To File(Binary).vi:create header.vi example

[minnellac]

I believe there is a bug in the example vi used to create a header when streaming binary data to disk. The example vi is Cont Acq&Graph Voltage-To File(Binary).vi and the subvi in question is create header.vi. I've included an image with the problem highlighted in red.

The way the scaling coefficient array is built, it grows by adding new data at the top of the array instead of the bottom, so that if four channels are configured in ascending order, the header will contain the information in the order of channel 3, channel 2, channel 1, channel 0. When the file is read, the information is read and scaled as if it were in ascending order. The displayed data would be incorrectly scaled if the channels were configured with different scaling coefficients (for example, if engineering units were used instead of Voltage).

Can someone please confirm, or am I missing something.

Chris

[TylerS]

Chris,

From what I can tell, the example program seems correct. Each iteration of the For Loop in the Create Header subvi reads a channel's scaling coefficients and these channels progress in ascending order. So it will read the scaling coefficients for channel 0, then channel 1, etc. and build the array in that way, concatenating each channel to the data from the previous data. Does this answer your questions?

TylerS

[minnellac]

Sorry, I just realized that I did not include the image on my previous post. TylerS, what you describe is the way the vi should work. By making the previous data the last element of the build array, it is always being pushed down. The end result is that the coefficients for channel 0 are the last set in the header array (instead of the first).

[minnellac]

Here's a vi that helps illustrate my point.

[TylerS]

I see what you mean, but if you take a look at the help file on the scaling coefficients property node in the header subvi it says it "indicates the coefficients of a polynomial equation that NI-DAQmx uses to scale values from the native format of the device to volts....Scaling coefficients to not account for any custom scales or sensors contained in the channels." So when you say that using engineering units instead of volts would invalidate the file, you're right. The construction of the header file does not account for custom scales. In this case, though, it isn't a bug but the expected behavior.

[minnellac]

Ahh, good point. That may just make it an insignificant bug though. The other half of the equation is in Graph Acquired Binary Data.vi. As established, create header.vi puts the coefficients in reverse order (channel wise) and stores them in the file that way; they are then read in by Graph Acquired Binary Data in what should be the correct order (ascending) and applied to the channels in that way. If there are any circumstances where the coefficients could be different from channel to channel, then the data read in will be incorrectly scaled.

I had thought that the coefficients would change when some engineering units were used, but that appears to be incorrect (based on the help information that you cited). I am still not convinced that there are no circumstances where the coefficients could be different though. If that were the case, then this code is buggy and inefficient. If the scaling coefficients for all channels in a task are by definition the same, then it is a waste of space to write them for each channel (as the sampling rate is also duplicated - for convenience, I assume). Unfortunately, I don't have any hardware handy to play with this now, but the limits can be changed on a channel by channel basis. I believe this would change the scaling coefficients between channels.