Multifunction DAQ

cancel
Showing results for 
Search instead for 
Did you mean: 

problem with example VI's

I am trying to get two example VI's to work together.  I read in an analog voltage from a USB-6210, streaming it to a binary file using the example VI:
 
Cont Acq&Graph Voltage-To File(Binary).vi
 
This seems to run fine and creates a binary file.
 
Trying to read the binary file with:
 
Graph Acquired Binary Data.vi
 
results in a garbled waveform of numbers as large as 2E+10.  Usually, I see this behavior when I read in values from a binary, and I'm off by a byte.   I have tried:
 
switching all of the binary file read and writes within the two VI's to byte order 2 (little endian).  Seems like a good idea since I'm using winXP.  Didn't help
 
Switching over to Analog 2D I16 on the DAQ.mx READ vi since my USBDAQ is 16bit.  Also switched the divide by 4 to divide by 2 for the calculation of how many samples are in the file.  Didn't help.
 
I'm a bit frustrated that the simple examples don't work together...  I checked the file header written in the first VI, and read in the second, and it seems to be transfered correctly, though the fourth and fifth values are awfully small to be believable (2E-14, 2E-18).
 
Any help would be much appreciated.
0 Kudos
Message 1 of 4
(3,121 Views)

 

So, in the absence of responses, I'll add a few more details.  I found a post in the archive that had the identical problem that I'm having:

http://forums.ni.com/ni/board/message?board.id=250&message.id=4389&query.id=13679#M4389

Unfortunately, nobody had any suggestions Smiley Indifferent

0 Kudos
Message 2 of 4
(3,092 Views)

I figured out what was wrong.  It wasn't a big-endian-little-endian problem.  It wasn't a I16 vs. I32 read problem.  The Cont Acq&Graph Voltage-To File(Binary).vi was the problem.  Just after the DAQ.mx read, and after displaying the samples read, somebody decided to "transpose the unscaled array of data and append it to the file." - Step 7.  This transposition garbled the bejeezus out of the binary.  I read the raw, garbled binary into another program, Igor, and was completely unable to get it to look right... so the "Graph Acquired Binary Data.vi"  was not the likely problem, the binary write routine was.  Getting rid of the Transpose 2D array widget solved my problem, now I can store a waveform, read it from the drive, and display it.  Question is - why is the transposition there in the first place?  I think it's a mistake.  Other examples, like the TDMS ones don't transpose...

-gerald

0 Kudos
Message 3 of 4
(3,069 Views)
 

Hi Gerald,

This was reported to R&D (4DP855N3) for further investigation. This behavior is described in LabVIEW 8.5 Known Issues.

I don't know why this line is blue, but I've tried to change it several times. Here is the link to LabVIEW 8.5 Known Issues.

Possible workarounds include:

1.       If you do any array operations such as index array or transpose array, before writing the new array to the write binary file primitive, insert an Always Copy primitive on the wire. A copy will be made, but it will write the correct values to the file.

2.       You can use Flatten to String function to flatten data into a string before writing to file.

Thanks for the feedback!



Message Edited by Mark E on 12-04-2007 05:31 PM

Message Edited by Mark E on 12-04-2007 05:31 PM

Mark E.
Precision DC Product Support Engineer
National Instruments

0 Kudos
Message 4 of 4
(3,044 Views)