AGILENT 34401A Timeout

[JT Law]

Hi I'm reposting this, I think it was in the wrong place before..

With the Agilent 34401A Digital Multimeter I am getting the timeout error ( 0xBFFF0015 (-1073807339) )  that others have mentioned, yet none of those solutions have worked for me. The error:

VISA Read in Agilent 34401.lvlib:Control Mode.vi->Agilent 34401.lvlib:Initialize.vi->Agilent 34401 Acquire and Graph - SW Triggered.vi

A history of my troubleshooting:

-Had LabVIEW 7.1 installed. Tried using the "Getting Started.vi" but would get the same error as above. Probing the error signal the error was traced to the first 'Visa Read' command.  This command is directly after 'Visa Write': *OPC?.
 
- Updated to VISA 4

- Tried Wiring in the termination character to both  \n and  \r (ASCII  10 and 13) respectively.

- Connected to 34401A with Hyper terminal, no flow control. Sending *OPC? recieves '1' as return data.  'SYST:REM' and *RST and *CLS also works.

- Using Agilent Interactive IO: *OPC? "send and read" command only works when the EOL sequence is \n...   \r, \r\n, or \n\r cause the same timeout error in this application.

-Upgraded to LabView 8.2. Downloaded and installed 'project based' vi's.  Loaded Agilent 34401 Acquire and Graph - SW Triggered.vi. This works fine with Agilent 34410A over USB. I can see the changes that have been made in the Initialize.vi and Control Mode.vi, so I know that these sub .vi's have been updated.

- Run Acquire and Graph - SW Triggered.vi with 34401A over Serial : COM8, n,8,1. Get the VISA error 0xBFFF0015 (-1073807339) in VISA Read in Control Mode.vi as Described above.

-Can acquire data over serial with same port settings using Agilent's Excel Toolbar Addin or Word Toolbar Addin.


So the firmware, Null modem cable, port setting suggestions are all mute. I probe the VISA Resource and it has the correct setting.  I think this must be a timing error (for which there was a suggestion, but that was vor VISA Wait on Event ASync, which doesn't seem to be in my execution heirarchy. I get the sense that adding a short delay between the VISA write *OPC? command and the VISA read would solve the problem, but I don't know how to try that.

Any Ideas ? Please ?!

Jesse Law

[Makoto]

> - Run Acquire and Graph - SW Triggered.vi with 34401A over Serial : COM8, n,8,1. Get the VISA error 0xBFFF0015 (-1073807339) in VISA Read in Control Mode.vi as Described above.

As I remember, 34401A serial interface requires hardware flow control with DSR/DTR lines, therefore the null-modem cable requires not only TX/RX cross-link but DSR/DTR too. 

As for termination character, the instrument is based on the SCPI std.  When receiving a command, it only checks LF (0x0A) (and likely semicolon too) and ignores CR (0x0D).  When transmitting a response data, it adds CR+LF after the string. 

Also the typical operation model of 34401A is, the instrument requires to be "remote" state for remote measurement.  Immediately after booting up the instrument, it is "local" as default but can be switched to enabled state by SYSTem:REMote\n command is sent.  Under "local" state, the instrument never accepts measurement commands such as INITiate/MEASure/FETCh etc... causing a command execution error.   This may cause a timeout error when attempting to MEASure while in "local" state.  (I don't know if the recent 34410A remains the same architecture. )

このメッセージは　03-08-2007 04:53 PMに Makoto が編集しています。

[thehobbs]

You mention that operation is successful over USB....are you using a USB to serial converter?  If so, you might be successful because of additional hardware memory buffer on this serial chip than on the one you are using as COM8.  You are probably on the right track in thiking the issue is caused by timing.  One thing you can try is to slow down the buad rate.  You can do this in the Initialize VI, make sure the settings on the instrument match exactly.  Another thing to try is running the VI with Execution Highlighting.  This will slow things down to help determine if timing is causing the problem.  You can also try inserting delays at various placed in the Control Mode VI.  There is already one delay in that VI so you can use it as a reference of how to insert others.  I recommend having a 'large' delay (at least 1000ms) at first as you are troubleshooting.

If communication is working successfully through your USB approach, why not use it?  Just curious.

[JT Law]

Thanks for the suggestions. I'll try to get a delay worked in there. Also I am connecting over COM8 now, which is through a USB adapter, I hadn't thought about it, but I'll try going straight through the native COM port too.

  The USB is working over a 34410A, not the 34401A. Subtle difference I know, and for once not a typo!. Our lab just bought one of each meter, and I'm wishing we'd just got two of the -10A now. I just tried that to make sure the .Vi was working. Anyhow, when I get a chance to dig in again, I'll let you know how I solved it. (Always an optimist)

Cheers, Jesse

[gdargaud]

I know this is a long dead thread, but I had that exact problem recently with the 34401a with programs that had been running fine for years. Some progs (based on VISA) would work fine. Others (based on the base serial driver) would write fine but couldn't read any reply (timeout).

After a very long debugging session (comparing configs  with NI I/O Trace, trading cables, trading system, trading OS, eliminating factors one after the other) I figured out that the problem was the driver of the USB-to-Serial connector. I upgraded the UC232a driver on Win10 to the latest version and it magically started working again.

[Minions]

NOTE: Be aware what the *OPC? command implies.  The *OPC? command (Operation Complete) tells the system to wait until the previous command is completed before returning a True.  For some instruments, a command may take up to 10 seconds (*TST or *RST) or more to be performed.  If the previous command takes near the timeout window, it is possible too have an unstable response while running that causes an erratic timeout response.