USB Communications Work in Visa Test Panel but not in VI

[Cannon_Controls]

So I am trying to communicate with a Clarke Hess Model 2600 Phase Angle Voltmeter. I first started by using the VISA test panel in NI MAX and using all of the default settings there, the commands all worked perfectly. I was able to go through all of the ones that I needed and verify that they all worked how I intended. I am now trying to take that into LabVIEW and I can't get any of the commands to work. I get a timeout error on the VISA read function every time. If I understand correctly the VISA read should finish either once it receives a termination character (if enabled) or if it gets the specified number of bytes, although I may be wrong on that. 

I've tried playing with quite a few settings in the property nodes. I've also tried changing the number of bytes to exactly what I expected to receive with no success. I've used the bytes at port and didn't have any luck. I've tried converting my ASCII text into hexadecimal and that didn't help. In the VISA Test Panel I was using a Line Feed termination character and I have tried manually typing that into the end of my messages and using the property nodes to add it. I haven't had any luck at all. Attached is the basic VISA vi that I am using and also attached is an I/O trace file that I made. The start of the file shows the VISA Test Panel successful commands. Afterwards my unsuccessful commands are shown. Any help or guidance would be greatly appreciated.

[ErikL68]

Hi,

I'd start by replacing your hard-wired VISA device with a control, and see what your computer can detect. I don't have experience with the CH device, but with a Yokogawa WT5000 USB-connected power meter, the device name was something along the lines of "USB0::0x0B21::0x0025::<USBID>::INSTR", not "CH2600", though perhaps that's because you've named it in NI-MAX?

From there, wire all your error ports, and at the end of the string of VIs, add an Error Indicator to the end (or a error dialog).

From your trace, it looks like the commands that were working were to device "ASRL3::INSTR", but your VI has the device name "CH2600" - and those looked like they never worked.

Also - if you have the Termination Character disabled, you don't need to set the Termination Character. You may also want to try other settings for the "Send End Enable" and "IO Protection" parameters. The Yokogawa didn't want either of those (it also wanted the VISA I/O Session Type set to "Instrument", not "USB Instrument").

Good luck!

[JÞB]

It's almost assuredly simpler than that.

My 8-Ball suggested that the VISA Test panel in MAX is open.  That would exhibit like the OP described. 

Yeah, serial bosses use finite numbers of copper conductors.   So VISA sessions can't be opened by more than 1 application. 

[Cannon_Controls]

Unfortunately, neither of those suggestions were the solution. The VISA test panel being open is not the issue. I did do that originally but instead I get an error that says that the resource is valid but unavailable. The error I'm getting now is entirely different. The program opens the connection and writes the message without any error but it gets a timeout error on the read function.

The device is currently called CH2600 because I named it that in NI MAX. I've tried getting rid of that and using it's default name with the same result. For some reason the VISA Test Panel didn't use that alias.

I've tried playing with the "Send End Enable" and I've tried every single option for "IO Protection" without any luck.

[JÞB]

---

@Cannon_Controls wrote:

Unfortunately, neither of those suggestions were the solution. The VISA test panel being open is not the issue. I did do that originally but instead I get an error that says that the resource is valid but unavailable. The error I'm getting now is entirely different. 

---

Oh, NIFTY, I almost have to write a detailed message about the difference between Monty Python and Douglas Adams. "And Now for Something Completely Different"  a was a Monty Python movie that involved random changes that you didn't suspect (don't ask about the cut scene to the spokesmanforthe producers, we aren't looking for an R rating here!)  In Douglas Adams' "A Hitchhiker's Guide to the Galaxy" we found out that - 42 is the answer to life the universe and everything (and incidentally, the reason that -42 was selected as the general error.) Now, what is your completely different error

[ErikL68]

Hi CC,

In that case, I'd tweak your code to lower the timeout very low (1 ms), and keep reading 1 byte at a time, appending data to a "results" field when a Timeout isn't seen, until you get a Timeout repeatedly for a few milliseconds. Be sure to clear the Timeout errors from the error line. If you're not getting a response, it's likely the device didn't recognize what you sent. You may need a terminator character or have other issues.

If this doesn't solve it, post a capture of NI-MAX open to the device, please.

Good luck!

Erik

[Cannon_Controls]

So still not entirely sure of the issue. I used the I/O assistant and everything works perfectly. For what I am trying to do, the I/O assistant works perfectly fine so I will probably just use that in my program. I've tried all of the suggestions but I still don't seem to get any response from the device using the VISA API. I've played with different termination characters with no success. I'd like to use the lower level API if I could but don't think that I have the time to troubleshoot through this. Thank you all for your suggestions but I believe that I'll just continue with the IO Assistant. 

[Kevin_Price · Accepted solution]

Looking over your .nitrace file, I focused on the command that was common between the 2 approaches, INPH?

With your first approach you got a reply, the second approach did not.  Here's why:

Double-click the line where you send that command with your first approach.  Choose the "Buffer" tab.  Notice that you sent 6 bytes with hex 0A as the final byte (a.k.a. '\n' as a line terminator).

Compare to where you send that command with your second approach.  Only 5 bytes this time, no trailing hex 0A.

That's what your instrument is looking for.  It wants a hex 0A byte as a line terminator before it tries to process the command that precedes it.  Without that line terminator, the instrument never replies so your Read times out.

-Kevin P