Weird Behavior using LabVIEW Inst Driver with Agilent 3300A (CR mode)

[Ken3006]

Dear NI Support,

I am currently using LabVIEW with Agilent's USB GPIB hardware to control Agilent's 3300A Load.  I have managed to communicate with the device using the Instrument drivers provided by NI for this device.  However, I am experiencing some weird behaviour with one of the modes that is available to the 3300.

My program requires the use of all 3 modes of the 3300A.  Namely, Constant Voltage (CV), Constant Current (CC) and Constant Resistance (CR).

There are pretty decent examples from the instrument drivers to control 3300 to operate in CV and CC mode.  Hence, I modified the example for CR mode.  However, I encountered some weird behavior while doing so (I have attached the modified program).

When I set my active channel to be 1 for example and instruct the program to load the settings for my CR mode (i.e. desired triggered resistance, range and etc), the program will give an 'out of range' error.  However, if you change the active channel and update, it would have no error.

I tried it without the 'update' case in my other implementation and I kept getting the error.  My understanding of the instrument driver is that it would allow me to select my channel and configure my mode as well as the parameters for my measurements.

Please let me know if it is my implementation methodology that is incorrect; or if you are getting the 'out of range' error even when the settings are correct.

Thanks and Best Regards,

Ken

[UFOslava]

Same problem here, "CR" mode returns an error "out of range", no matter what values i write to it.

After the channel switch workaround and error disapperaring, does it executes the program?

I think it is Agilent's side issue though.

[Albert.Geven]

I did. Not check your vi but maybe it has something to do with the compliance settings. I've seen compliance problems in other systems. Be very careful when switching modes.

[Ken3006]

I have figured out the issue.  It is with the driver that is provided.  Apparently, the driver 'tries' to be an all-in-one; but after reading the Agilent's programmers guide for this instrument I found out that there is a difference between the NI IDnet's driver and the programmers guide.

The programmers guide can be downloaded on the Agilent's website.

Using the NI Idnet driver as a base, I modified the appropriate VI (CR/CC/CV config) following the command sequence as suggested by the programmers guide and it seem to work fine.

I can upload my modifications and the guide if you need an example.

Cheers,

Ken

[Albert.Geven]

Pleas upload your modification. The best way to work together on a good system.

[UFOslava]

Yesterday i have contacted Agilent representitive via phone, And the a possible sollution appears on NI forums.

Our appointment is next week. The race is on. Standard tech support VS wide NI community. Who will deliver? 😛

[Ken3006]

I have only modified the driver in a way that will allow my application to function properly (i.e. allowing user to select between modes of operations (CR,CV,CC) without error occuring).  The modification is only done on the Config Voltage, Current or Resistance subVI.

I have attached an example of the modification done below.

As you can see, I basically remove those 'call functions' that does not concern me and only include those commands that are used.  Almost replicating what I would do with the actual 3300 front panel controls.

Hope this helps.

Regards,

Ken

[UFOslava]

I'll review the driver files and write here how it worked out. I need the list functions though.

[UFOslava]

Ok, i saw the vi's, and to my surprise i didn't find any special tweaks that might have helped me...
Anyways, thanks for your help.

I managed to fix the problem with the resistance range. It appears i must set the resistance transient value within the same range as the value itself, even if I don't use it. So i just set the transient value to value if transient mode is off.

Thanks to everyone.

[SunshineDesign]

I have been programming many years and Labview the last 5 years and dealing with the Labview Drivers for Agilent and their many deficiencies for just the reason you stated. The Driver developers group too many and/or unrelated functions together, forcing the functions to work improperly or against each other. Clearly the driver developers in many cases are not advanced users/developers or they would never make the numerous errors designing the drivers that occur.

I have "fixed" them myself and tried to forward to Agilent and NI, Neither really worked to get the updates in place and my submissions languish. Just saying to inform you and adjust your expectation on the implementation of fixes...