03-06-2007 06:57 PM
03-08-2007 01:51 AM - edited 03-08-2007 01:51 AM
> - 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 が編集しています。
03-08-2007 09:42 AM
03-08-2007 11:00 AM
09-23-2021 06:18 AM
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.
09-27-2021 12:41 PM
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.