LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

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

Solved!
Go to solution

I tried running the "LCLSA Getting Started" vi (I'm assuming this one can run independently?) and am getting stuck at one spot:

 

Within the Getting Started vi --> LCLSA Application Example vi --> "LCLSA Read Wave 1 (Single).vi" -->

 "LCLSA Base Read Descriptor.vi" --> "tcp_Instr_Read.vi"

 

Inside tcp_Inst_Read, the program gets up to the "TCP Read Function" just inside the loop and doesn't go any further (see screenshot attached).  I understand that the "-1" input to the "TCP Read Function" prevents it from timing-out, but I don't understand why the program gets stuck at this point time after time.

 

0 Kudos
Message 11 of 31
(1,251 Views)
Did you change the constant? I downloaded the drivers from the NI site and I see a constant of 5000 (i.e., 5 seconds), not -1. If it's sitting there waiting it means there are no bytes available to read. I'm not sure why this would be the case. Perhaps there's no waveform due to a trigger not having occurred?
0 Kudos
Message 12 of 31
(1,247 Views)

Alan form LeCroy Tech Support here...

 

If the Initialize VI works, then any subsequent errors calling the Write or Read VI's are somewhat of a mystery, since the Initialize VI calls these functions.

 

The best solution might be to re-write the driver to be a VISA driver.  This entails swapping out the TCP read/write calls with VISA open/close calls, and changing all of the VIs that you use to use a VISA Resource control in/out instead of TCP sessions in/out You would use the LeCroy VICPPassport as the NI-VISA passport to handle communications.  I'm thinking this is the best solution.   I'm curious to hear from any of the other people posting on whether or not they think there is a problem with this idea...

 

Best Regards,

Alan

--------------------

Alan Blankman, Software Engineer
Teledyne LeCroy
800-425-2000
http://www.teledynelecroy.com
alan.blankman@teledyne.com
0 Kudos
Message 13 of 31
(1,240 Views)

Alrighty, here's where I'm at: I went through all the VIs used by the "LCLSA Getting Started" VI with the VISA read/write functions instead of the TCP/IP functions.  As a result, the Getting Started VI runs without error, but the lack of output doesn't make sense.  After running the program, the wave graph remains black with no plot on it.  Additionally, I get a message in the Error Out box (see attached screenshot)...thoughts?

 

0 Kudos
Message 14 of 31
(1,220 Views)

For whatever reason, I'm having file upload difficulties, so here's a link to the files:

https://mywebspace.wisc.edu/jjanderson1/LSA1000_VISA.zip

0 Kudos
Message 15 of 31
(1,216 Views)
Solution
Accepted by topic author nellium

Some browsers have problems adding attachments to posts. There is some sort of incompatibility with the forum software.

 

The screenshot doesn't show the full code, but I'd guess it's probably 1073676294, which means that there was no error, but there were more bytes available to be read. The reason why this would be happening is that in the "LCLSA Base Read Descriptor" VI the "byte count" input of the VISA Read function is being set to the same value as the "return count" of the VISA Write. Those two values are two different things, and it's not necessarily the case that they will be equal. In fact, in 99.9% of the time they are not. You need to set the "byte count" to how many bytes you expect to read. An alternative is to set it to some really large number, and use the termination character so that the VISA Read will know when it has received the end of the data. Typically the termination character is a linefeed or a carriage return. This would be configured in the Initialize VI. However, in this particular case I don't think you're going to be able to use the termination character since that character could very well be part of the waveform data. Thus, you're going to have to know how many bytes to expect and wire that value to the VISA Read. 

0 Kudos
Message 16 of 31
(1,213 Views)
Hey, it finally all works!  Now I just need to figure out how to read the data from the binary file...
0 Kudos
Message 17 of 31
(1,184 Views)

Anyone good at figuring out how to write to a file?  I've made an attempt in my XSCAN4.vi, but get a lot of jumbled characters (see the folder "Test Writing Files" for examples).  I've never worked with converting binary data to something useful in LabView (i.e. ascii), and would love some pointers.

 

Link to all files is here:

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

0 Kudos
Message 18 of 31
(1,141 Views)

I don't quite understand what you're asking. The binary files are meaningless without knowing what the structure is, so as far as we can tell, it all looks jumbled.

 

Converting binary data to LabVIEW depends on the format of the binary data. As I've already pointed out, you need to understand what the instrument is returning when you send the "WF? ALL" command. This would be in the documentation. This will tell you how to parse the data.

0 Kudos
Message 19 of 31
(1,138 Views)
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.
0 Kudos
Message 20 of 31
(1,125 Views)