Question regarding functionality of "Search 1D Array Function" in TCP/IP context

[OliviaC]

Hi,

As smercurio_fc said, you need to know what the format of your binary file is. In general, you would use the Read Binary File.vi and wire in the expected data type for the information in the file. For example, if the data in the file are numeric, you wire a numeric constant to the data type terminal of the VI. There is a very simple example under Fundamentals » File Input and Output called Read Binary File, that simply reads a binary file and displays the data. 

[smercurio_fc]

---

nellium wrote:
Right. I can see that the manual describes how all the bytes are used on pages 36-39 of the manual, and provides a template of the waveform in appendix A.  However, I don't know how to take this information and actually parse the data apart using LabView, and I haven't yet found an example that shows how to do this.

---

Based on what's in the manual you would need to read the data in pieces and transform this into the appropriate human-readable values. Page 4-7 is quite detailed in explaining what the bytes mean. However, based on what's in the manual the example files you attached earlier do not conform. Specifically, there should be a 11-byte sequence near the beginning of the data that starts with the character "#", and it follows the first comma. After the "#" there should be 10 digits. In your files you have "#0", which means there is no waveform data. I do not know if this is a problem with the drivers or with the way you're using them. 

[alanjb]

Hello everyone,

Alan from LeCroy Tech support here.  The LCLSA driver includes all of the VI's needed to read back the waveform data and decode it.  Take, for example, the VI "LCLSA Read Wave 1 (Single)" VI. This VI first reads back the descriptor block with WF? DESC and decodes it by calling "LCLSA Base Read Descriptor", and then reads back the data block and decodes it by calling "LCLSA Base Read 1 (Single)".   The data block contains raw ADC codes, and the scaling information is contained in the descriptor block.

The query WF? ALL reads both the descriptor block and the data block (and other blocks as well).  The driver developer decided to send WF? DESC and WF? ALL separately, which makes a lot of sense.

One of the main reasons for having a driver is to eliminate need for users to need to learn how to decode the binary data, which can be quite tricky.

Best Regards,

Alan

[nellium]

I'm really close to having this program working as I want it to, but have 1 more thing to work out.  My program is the "XSCAN4.vi" in the attached ZIP file, which is a program that translates an ultrasonic transducer and saves a waveform after each translation step. Also included in the ZIP file (among other things) is a screenshot of the XSCAN4.vi after it's been run, and 2 output data files (June22_test4_0.dat and June22_test4_1.dat).

My question:

In the output files, why is the size of the data 0 bytes? (shown at "Size: #0")
I'm assuming this is the reason why after the "Data Follows: " text in the output files, the data are all 0's.

Any ideas why this would happen?

Link to the ZIP file:

https://mywebspace.wisc.edu/jjanderson1/shared/Scope%20Project.zip

Thanks,

Janelle

[alanjb]

Hi Janelle,

The screenshot certainly shows that you have non-zero data.  Which VI is writing the data to the file?  I don't see it in your zip file.  Are you writing the contents of the array that the driver returns, or are you decoding the data yourself?

Best Regards,

Alan

[nellium]

Hi Alan,

The VI I'm using to write the data is called "LCLSA Write Text File.vi" - it's a VI I made, and it's saved with the rest of the lclsa library.  It uses all of the parsed parameters directly from the "LCLSA Base Read Descriptor.vi" and the "LCLSA Base Read 1 (Single).vi".  Additionally, there were 3 parameters I still needed for my output text file:

1) A Time/date stamp, which LabView had a function for, so that was easy enough;
2) The Response Message from the LSA 1000 when sending the command "WF? ALL" (e.g. the first 10 bytes)

3) The size of the buffer, e.g. the nine ASCII integers giving the length of the block #9000000450, described on page 4-7 of the manual.

Numbers 2 & 3 above are called "Parameters 6", and my attemptto parse them out is shown in the LCLSA Base Read Descriptor.vi.

As for the actual data, I was trying to extract that from the "Wave Output" created by the "LCLSA Base Read 1 (Single).vi" by sending it to my Write Text File.vi and storing the 1D array of voltages ("Amplitude Array (Volts)").  However, since my signal is clearly non-zero, but my array is all 0's, maybe it's this piece that I'm doing incorrectly?

[alanjb]

Hi Janelle,

Your VI routes the waveform value array (type double) into the Number ot Decimal String node, which outputs integers. Thus you don't get the correct result.  You want to use Number to Fractional String instead.  (I've always thought the name Number to Decimal String is misleading...)

Best Regards,

Alan

[nellium]

Awesome.  Thanks!  That fixed it.

One other question: Even though I don't get non-zero data in my output file anymore, the byte size is still showing "#0".  Am I parsing this incorrectly, perhaps cutting it off in the wrong spot?

Thanks again for all your help!

[alanjb]

Hi Janelle,

I don't see anything wrong.  Run your program with the Write Text File and Base Read Descriptor VIs open.  What do you see in the Paramater6 clusters?

Best Regards, Alan

[nellium]

Hi Alan,

The Parameter 6 Cluster contains the following:

For the "RESPONSE", I get "C1:WF ALL,"

For the "SIZE", I'm getting "#0".

~Janelle