Controlling a Triple Output Agilent Power Supply

[clg6621]

I posted this already under GPIB, but maybe it fits better here...

Hi all,
First let me say that I am a novice when it comes to LabVIEW.

I am trying to send different voltage values to the +6V side and +25V side of an Agilent E3631A Triple output power supply. According to the front panel of the power supply, its working, but when I scope the output, only one side of the power supply is actually changing the voltage... I have tried several different power supplies, so its not a hardware problem. Does anyone have any ideas about what could be causing this?


I have also tried to go around the problem by controlling 2 different power supplies, but I couldn't get the 2nd one to do anything. I'm assuming its an
addressing issue/problem, but I couldn't figure it out. Any ideas on this issue?


A solution to either method would be very helpful, as either one would help me get this project done. Please help!


Thanks in advance!


P.S. I'm using LabVIEW 6.0"

[Dennis_Knutson]

Can you get the output voltage to change manually? I may be confusing this model with another but I seem to remember that one of the outputs is a floating one so you may need to reference the com output to gnd in order to see anything with a scope. Also, the output may need to be enabled. Are you using the driver from NI or are you sending your own commands? If you are using the driver, which VI?

As far as controlling a second ps, you have to make sure that each has a unique address. The instrument manual describes how to change addresses. If you open MAX (Measurement & Automation Explorer), you should be able to right click on the GPIB card listed and select Scan for Instruments. If you get two found, then you should have no problem programming either
or both.

[kphite]

I've built drivers for this instrument. Post some of your code and I'll take a look at it.

[thehobbs]

Hi kphite,
We have LabVIEW Plug and Play, CVI Plug and Play, and IVI drivers for this instrument available on the Instrument Driver Network (ni.com/idnet). I'm interested in understanding your reasons for creating your own drivers for this instrument. Did you know about the ones on IDNet, or were there additional features you needed or ways where our drivers did not meet your needs? I'm curious to know because we are always looking for ways to improve the instrument drivers that we provide.

Thanks,
Jason Hobbs
Instrument Drivers

[LesHammer]

Well, I've written drivers for this instrument too, but I was working at Agilent at the time. 🙂

We still need to see the code to see if we can spot an error.

Les Hammer

[kphite]

There are several reasons.

1) VISA is SLOW. And it adds a level of complexity that is not always needed. I've used NI drivers with VISA and I've written my own GPIB. I use VISA in some cases and not in others.

2) The instrument driver structure that NI has chosen is good for generic use but for more specific applications the UI's are not very intuitive. And the low level drivers usually have to be assembled to create a complete driver.

3) In some cases the NI driver doesn't include all of the programmatic controls that are available and these must be added.

4) When a driver is built around a dll it doesn't allow for an in depth understanding of what is actually happening.

[thehobbs]

Thanks for the feedback. I encourage you to submit any drivers that you have created that are not available on IDNet:
http://sine.ni.com/apps/we/niid_web_display.sub_driver

[LesHammer]

As a driver writer myself, I agree with your assessment, and have an explaination why it is this way:

> 1) VISA is SLOW. And it adds a level of complexity that is not always needed.

Granted. OTOH, VISA means I can switch from GPIB to LAN or USB by simply changing an address. It increases the ability to maintain the system. What happens when next year's computer doesn't have GPIB?

> 4) When a driver is built around a dll it doesn't allow for an in depth understanding of what is actually happening.

That's part of the purpose of a driver - you tell the driver which channel and how many volts, it takes care of the syntax - the deep understanding.

Les

[kphite]

I agree with you that VISA is a good thing in many cases. I was just trying to show times when it might not be good. One example is when I need to take thousands of measurements on one UUT, I don't want the VISA overhead.

I don't agree with you about the dll point. If you create a labVIEW wrapper around a dll all you have really done is create a GUI for the REAL driver which is the dll. In this case you can't easily make modifications to the driver. JMHO

[thehobbs]

We appreciate all of the feedback from everyone. Please don't hesitate to provide more in the future. NI's instrument driver strategy is to provide the best driver for the ADE in which it is used. We believe that the "best" option is to supply a driver with source code native to the ADE where it is used. We do distribute some drivers with LabVIEW wrappers as a "good" option (or "better" if it is certified). It is less ideal than having source code, but can still beneficial if it meets the needs of your application.