VISA timeout errors with AmRel 488.1 power supply

[Underflow]

I'm running into a problem communicating with an AmRel PD8-2D 488.1 power supply. Communication between the LabVIEW program and the power supply is done using NI-VISA 3.1. Once in a while, on either a Write, or a Write/Read function, communication appears to be lost, and cannot be recovered short of restarting the power supply. The error most commonly seen with this is a timeout error from VISA.

In the past, we have successfully communicated with the power supply using another company's VISA implementation, but would like to switch to NI's version now.

Any suggestions?

Thanks!

[JLS]

Hello,

You should be able to communicate seamlessly with the power supply using NI-VISA with LabVIEW. How often do you encounter this problem? Can you regularly reproduce it by writing a given command? One thing you may look into is that some instruments expect an end-of-string character either in addition to or in place of asserting the EOI (end or identify) line to indicate that the last byte of a transmission has been sent. You can check the user manual for the power supply to see what termination preferences to use. You may also simply need to wait longer on the read side to receive all of what you expect from the supply. To look into this, one thing you can try is increasing the timeout value of operations and see if this takes care of the problem (you c
an locate a VISA Set Timeout function in the VISA Advanced palette in LabVIEW; it is actually just a property node with the general settings timeout value selected). Also, what are the VISA commands you are writing (the order of such commands would be helpful)? One reason this may be significant is that you may be entering your read or write process more quickly than you expect in your application due to the asynchronous vs synchronous settings of VISA VIs. This should default to asynchronous, which will cause the VIs to return perhaps more quickly that you anticipate. You can see if this is the problem by right clicking on the VISA write and read functions and selecting Do I/O Synchronously.

Let me know if any of this was helpful in alleviating your problem. Also, feel free to repost with answers to those questions above, which may elucidate other potential solutions.

Thank you,

JLS

[Earentzen]

The problem was occurring intermittently during the execution of a ~15 minute TestStand 3.1 sequence with LabView 7.1 calls, and it usually manifested itself as a VISA Write timeout error. I was not able to reproduce the error manually in a reliable fashion by executing our drivers manually, but I found that a VISA Clear command would re-instate instrument communication without having to turn the instrument off manually. Increasing VISA timeout values had no effect (just increased the wait before the error message would appear). Synchronous vs. asynchronous had no effect either, although the AmRel documentation specifically states that it supports asynchronous communication (as I believe all 488.1 instruments must?).

We contacted AmRel about our problem, and their response was:

"There are no known communication issues with National Insturments [sic] VISA. However, the PD8-2D (488.1) firmware does not have command flow control. If a fast computer is use [sic], e.g., P4 computer we suggest adding about 50~70mSec after each read or write command."

I made this change to our drivers, and the power supply now appears to be communicating just fine in our sequences. I believe that the instrument was slow to respond to VISA Read requests, and occasionally data would be "left behind"; thus, the bus would be tied up at the next VISA Write occurrence. I'm not excited about inserting a "guesstimate" delay into the drivers, particularly one prone to variation from one execution to the next, but I certainly prefer it to the prospect of having to manually reset the power supply during production testing!

As a sidenote, this is basically how the drivers (written in LV 4) that AmRel ships with the power supply are constructed. We had re-written the drivers to eliminate the delays, and they worked fine with our previous test station configuration. It was only upon switching to a new test station configuration (which included a faster computer, LV and TS version upgrades, and new VISA drivers) that the problem appeared.

In any case, problem solved. Thanks for the advice!

[Underflow]

For clarification, Earentzen is the test engineer in charge of that project, local Test Stand guru, and really darn handy in LabVIEW as well :).