LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

I have problems getting readings from an Agilent 34401 using the LabView drivers from the IDN. I get VISA timeouts, error code is -1073807339.

From time to time, it works, but most of the time (90%), it doesn't.

I have LabView 7 Express, VISA 3.0.1, communication is supposed to run via GPIB. "HP34401 Read Meas.vi" returns a timeout, and the device shows an error condition, -210 and -410. Everything else (communication tests etc.) work. There are no other devices on the GPIB.
0 Kudos
Message 1 of 17
(6,199 Views)
HP34401 Read Meas.vi has a TimeOut input. If this TimeOut is not long enough, the VI will consider that HP34401 took too much time to answer to the query. Try increasing the timeout. I think 500ms is about to be the minimum for this input (according to the multimeter I've got - HP34401A).
The -401 Error occurs in the multimeter when you send a query without emptying its buffer first. You probably have this problem when you rerun the VI after having error -1073807339 with LabView. This is just because the multimeter took too much time to answer so that you didn't read its last answer.

Hope this helps !

Julien
0 Kudos
Message 2 of 17
(6,199 Views)
Hi,

thank you for your comment. However, Timeout is set to 10000 ms - which is exactly the time that expires before Read Meas.vi returns the error.

BTW, the example apps delivered with the driver fail as well. Actually, I copied most of it into my program.

Also, I have the 34401 *A* as well.

I have attached a screenshot.

Regards,
Matthias
0 Kudos
Message 3 of 17
(6,201 Views)
With it being in a for loop and not being able to see the other frames in your sequence structure, I'm just guessing that you're sampling too fast. Turn off autozero and autorange and see if that makes a difference. Add some delay between measurments. You could also try software triggering.

p.s. You should be using a shift register to pass the error cluster between iterations of the for loop and if you used the flat sequence structure (or better yet no sequence structure at all) it would make all of your program visible.
0 Kudos
Message 4 of 17
(6,200 Views)

I have also today seen the same error messages while trying to use the example code for the 34401A...... Anyone since found a solution? it does appear to be a timing issue.

 

Thanks!

Adam

0 Kudos
Message 5 of 17
(5,884 Views)
Hi Adam,

Where exactly is the error occuring?  Have you tried the suggestions in this thread?  Here is a knowledgebase that talks about this error in one particular case.  It may be worth a look.

Hope this helps!

Adam W
Applications Engineering

0 Kudos
Message 6 of 17
(5,866 Views)
It was with the standard 34401 Plug and Play drivers I was seeing the problem. Running the examples within the driver was giving me a 410 error on the voltmeter. When I created a simple routine myself I also saw the same error.
 
I have since downloaded the Project style 34401 drivers and all works well..... I am not quite sure where these differ and the reasoning behind the two styles of drivers, but at least these work without needing to modify things!
 
I haven't tried the IVI driver.
 
Adam
0 Kudos
Message 7 of 17
(5,856 Views)

Hi,

What are in frames 0 and 1?

Always, have you tried using NI-Spy to see what is being sent and received?

 

Regards

Ray Farmer

Regards
Ray Farmer
0 Kudos
Message 8 of 17
(5,838 Views)
The project-style driver is new to LabVIEW 8 and above that leverages the LabVIEW project.  As this is a different driver, we were able to redesign the API to be consistent with the latest instrument driver templates.  There are also several more examples available in this driver.  Unless you need an existing Play and Play driver for backward compatiblity in your code, you should use a project-style driver for new application development if one is availble.
 
The existing hp34401a driver should function properly.

Message Edited by Jason Hobbs on 09-29-2006 09:33 AM

0 Kudos
Message 9 of 17
(5,824 Views)
I get that error every once in a while also.  I wrote my own drivers, and made sure that I specified a delay between each read/write etc., a *RST before I try to read/write anything at the start, and always make sure to set the proper range, read speed, resolution, etc.

I got so sick of this error I just started ignoring it.  If I make my delays any bigger, it alters functionality.  I feel like it might be a problem with the meter itself, not completely clearing the output buffer after a read (I have also made sure to read all data).

If it happened at regular intervals, I'd look to the software.  If it works for 20 straight minutes and all of a sudden it gets that error, I look to the hardware...
0 Kudos
Message 10 of 17
(5,818 Views)