LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

VI Works Single Step at a Time, But Not When Run Normally

Solved!
Go to solution

I'm very new to LabView and have created a simple VI to record a single measurement from my HP 34401A Multimeter over an RS 232 connection.

 

The problem that I'm having is that the VI only works when I run it a single step at a time (clicking the single step button until it's completed).  When I try to run the entire thing though, I get the following error:

 

Error -1073807339 occurred at VISA Read in Untitled 2

Possible reason(s):

VISA:  (Hex 0xBFFF0015) Timeout expired before operation completed.

 

 

After reading through the help page for that error, I tried adding a time delay, but that did not fix the problem.

(http://digital.ni.com/public.nsf/allkb/874B379E24C0A0D686256FCF007A6EA0)

 

NI I/O Trace didn't provide any answers for me, but I've attached a shot.  Lines 1-13 are from the single step run, the rest are from attempting to run the entire thing at once.

 

Can anyone please help me understand what's going on here?  Thanks in advance!

 

If anyone is interested:

Windows 7

LabVIEW 2009

HP 34401A Multimeter

RS 232 connection is through a USB-Serial adapter

Download All
0 Kudos
Message 1 of 7
(2,498 Views)

Please remove the flat sequence. Put a while loop around visa read

0 Kudos
Message 2 of 7
(2,490 Views)
Are you sure that you will get 200 bytes of data? Why don't you try using the "bytes at the port" property to find out how many bytes available to read.
-----

The best solution is the one you find it by yourself
0 Kudos
Message 3 of 7
(2,489 Views)

The termination character is turned on, as it should be.  That instrument puts out a termination character at the end of its data.  So you don't need the Bytes At Port in this code.

 

Put in a Simple Error Handler at the end of your sequence.  When the VISA Read has an error, it should tell us what the error is.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 4 of 7
(2,466 Views)
Solution
Accepted by topic author rjohnston

The only thing I can think of is that you are sending the remote command and then not waiting long enough for it to complete.  The manual states:

 

It is very important that you send the

SYSTem:REMote command

to place the multimeter in the remote mode. Sending or receiving data

over the RS-232 interface when not configured for remote operation can

cause unpredictable results.

 

And I think we are experiencing unpredictable results.

 

i don't know if you can change the command into a query by using the *OPC? command, but using that could solve it - or we could run into the same issue because of the caveat mentioned above.  Maybe you have to put a manual wait in between the remote command and the write command.

 

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 5 of 7
(2,449 Views)

Thank you all for your help.  It is working now.  I had to manually add substantial time delays (200ms or more) between each command sent to the meter.  I suppose it is a very old device, but I feel like there must be a better way to work around this.

0 Kudos
Message 6 of 7
(2,385 Views)
Why aren't you using the driver that comes with LabVIEW? It's on your palette and there are examples in Help> Find Examples under Hardware Input And Output.
0 Kudos
Message 7 of 7
(2,368 Views)