Problem with VISA Read

[laps682]

Unfortunately, yes, I have done both already.

[laps682]

Hello to all,

Are there any ideas you might have that I could try?

[billko]

Usually the manual will tell you exactly what the instrument expects from you and what you should expect from the instrument.  You never mentioned your troubleshooting skills; they seem to be high.

One thing that might help you troubleshoot is to reset the instrument each time you fail, as sometimes an error from one mistake may affect the success of any subsequent commands.

Might be time to break out the manual, though.

[cstorey · Accepted solution]

Make sure you've closed the PuTTY session and NI-MAX test panels before running the VI.   

I suggest you also use a VISA resource control/constant, rather than just a string constant for VISA Open.  (Only because I've never tried just a string constant.  It might work, its just not standard practice.) 

Double check the name for typos like 0 and O (zero and Oh).

Next try sending a VISA clear before VISA write, and setting a longer timeout.  Not sure what the instrument expects or requires, but 5s is an eternity and usually modern instruments respond much faster.

So try the attached.

[billko]

---

@cstorey wrote:

Make sure you've closed the PuTTY session and NI-MAX test panels before running the VI.   

I suggest you also use a VISA resource control/constant, rather than just a string constant for VISA Open.  (Only because I've never tried just a string constant.  It might work, its just not standard practice.) 

Double check the name for typos like 0 and O (zero and Oh).

Next try sending a VISA clear before VISA write, and setting a longer timeout.  Not sure what the instrument expects or requires, but 5s is an eternity and usually modern instruments respond much faster.

So try the attached.

---

You're just suggesting the VISA clear as a t-shooting aid, right?  If you have to use VISA clear before writing in your dev code, something is seriously wrong with the way you are communicating with the instrument (either HW or SW).

[laps682]

Hello guys thank you for all your help!

cstory the file you gave me works, in that I was successfully able to send SCPI commands through LabVIEW and have the "read indicator" produce results like the device name, and current temperature. If you check my attached image, the same "error" occurs although I am not sure how that is affecting the script now...

Thank you all again!

[RavensFan]

Change the read buffer show it shows \code display mode.

If you are getting a timeout error, my guess is that you either not enabled the termination character, or you enabled it for one thing and it is another.  (carriage return vs. line feed).  Showing the \code in that indicator will show us which termination character the device is sending.

[cstorey]

Ok, you've passed hurdle #1.

Now, as Bill points out, that VISA Clear is a debugging tool and not a good solution for a stable program. 

First try RavensFan's suggestion to look at the termination characters.  It seems like there's a difference between what is set for send and receive.  (What's the manual have to say about defaults?)  

Here's a bit more severe test to try.  It uses property nodes to read the termination character and then make sure it's set for both send and receive.

Does it run indefinitely without error until you press Stop?  If so, remove the VISA clear and try again.  If that works I think you are good to go.

Craig

[laps682]

Hello all,

So I ran the new code cstorey posted and it ran continuously with and without VISA Clear. I posted the result without VISA Clear below.

I read the manual over and there was no mention of termination characters although from my image I believe the correct one is newline. 

The status is a checkmark although there is still an error code; again I'm pretty new to this so I'm not sure how to interpret that.

[RavensFan]

That's not an error code, but a warning.  ("Status" is good, and the code is positive.)  I've never seen this one before, but perhaps it is related to the TCP/IP side of things.  It seems very similar to the code when working with serial that is a warning where you if you request X bytes and receive X bytes, it warns you that "there may be more bytes available.

If your code consistently shows what you are seeing in that screen shot, you no longer have any problems.