Instrument Control (GPIB, Serial, VISA, IVI)

cancel
Showing results for 
Search instead for 
Did you mean: 

triggering Keithley model 2000 DMM

Hello All
I decided to post my message on NI forums although I am not sure if I should not ask Kethley about my problem. Maybe I will do ask them too.
I am writing a simple program in VB 5.0 which reads resistance (4wire method) from Keithley model 2000 DMM, converts it to tempearure and shows it on the screen. I communicate with that DMM through GPIB-PCII/IIA board. I installed the driver (Windows 95) and can communicate with the DMM through NI-488.2 Communicator. Then I downloaded sample Test program from NI.COM (it was for FLUKE 45 meter) and started from there. In that program there were two subroutines which are relevant. One initiates the device (called "Meter_Init") and onother one which resides in main loop which takes the readings (called "Meter_Get_Reading").
So in the Meter_Init subroutine I am sending the following series of commands to the multimeter:
"*RST; :INIT; :FUNC 'FRES'; :FRES:NPLC 0.1; :INIT:CONT 1; *SRE 16"
and in my subroutine Meter_Get_Reading I send just ":SENSE:DATA?"
When I run my program it works. When I touch my litle silicone diode of which resistance I am measuring the values change and everything seems to be ok but last night I decided to implement a new feature in my code. I wanted to be able to set the time interval between measurements. While playing around I changed :FRES:NPLC 0.1 to :FRES:NPLC 1 and I noticed that my program reads the same value over and over. That led me to think that I am doing something wrong. I should also mention that my program never puts the DMM into REMOTE mode but I am not sure if it is neccesery. However I noticed while playing with my friends setup who is using LabView that his multimeters always are in REM mode.
When I change my code to the following sequence:
"*RST; :INIT; :FUNC 'FRES'; :FRES:NPLC 0.1; :TRIG:SOUR BUS; :INIT:CONT 1; *SRE 16"
"*TRG; :FETCH?"
It looks like the device is triggered every iteration of my loop but it is slow compared to the previos method.
My questions are the following:
1.Am I doing something wrong with the Triggering?
2. Should my DMM be in REM mode? If yes how to set it up?
2. In the second case is it just my code which slows data collection?
3. What sequence of SCPI commands will give me the fastest data collection rate?

Any suggestions are greatlu appreciated

Marek
0 Kudos
Message 1 of 5
(4,634 Views)
Hello,

Hopefully the following responses to your questions are helpful:

1. Setting up triggering by writing commands over GPIB will be entirely dependent on the instrument and the command syntax it expects for such commands; the user manual is likely the most efficient resource to determine this.

2. Your dmm should go into remote mode when you communicate with it. In particular, if you are able to communicate with it, you likely don't need to worry that it doesn't digitally display that for you. To be sure, note the following:

REM indicates whether the board is in the remote state. REM is set when the Remote Enable (REN) GPIB line is asserted and the GPIB interface detects that its listen address has been sent either by the GPIB interface or by another Controller. You can enable remote communication using the following call in VB:

CALL EnableRemote (boardID%, addrlist%()), where you may simply want to use your board ID (i.e. 0 if your board enumerates as GPIB0, and your single instruments primary address.

3. and 4. To really understand what those commands are doing to your instrument, again the user manual is the likely the best resource. In general, this should expose which method of data acquisition and subsequent transfer is fastest for that instrument; in general, it should be the method which minimizes instrument I/O by transfering larger amounts of data for a given I/O operation (assuming the total amount of data sent is the same).

OK, I hope this sets you in the right direction and feel free to repost if you have any other questions! In general, you may want to see if there is a driver for your instrument already made; the best places to look are ni.com\idnet and the instrument manufacturer website (and perhaps call them just in case they don't post it).

Thank you,

Best Regards,

JLS
Best,
JLS
Sixclear
0 Kudos
Message 2 of 5
(4,612 Views)
Hi
Thank You for Your Reply JLS. I was working on my code over the weekend and it is working fine right now. I noticed that the original code for Fluke 45 meter was never setting REN line. The sequence inside Meter_Init procedure was:
Call SendIFC(0) - makes my GPIB board a controller in charge
Call FindListen(0, instruments%(), results%(), 31)
Then inside a loop
Call Send(o, results%(k%), "*IDN?", NLend) - to querry for names of different devices
Call Receive(0, result%(k%), Readings$, STOPend) - to read the results of the above querry
Then
Call DevClear(0, Fluke%) - to clear Fluke multimeter
Call Send(0, Fluke%, "series of SCPI commands", NLend) - to set the meter functions
As can be seen from the above list of calls REN line was never beeing set.
I added the following two calls between DevClear and the last Send command:
Dmm% = ildev(0, Fluke%, 0, 1, 1, 0) - to get unit descriptor for my DMM (now I see that tha is probably not neccesery)
Call ibsre(0,1)
(After each call I am checking ibsta for errors)
I also contacted Keithley and got some help on the sequence of SCPI commands to send to DMM for initialization purposes and for taking reading.
My only question now would be: What is the difference between unit descriptor and its address? Is it neccesery to use unit descriptors or I can get by with just an address?
Thank You kindly for your response

Marek

Message Edited by Marek2005 on 05-17-2005 10:55 AM

0 Kudos
Message 3 of 5
(4,611 Views)
Hello,

Glad your program is working! As for unit descriptors vs addresses, the idea is that you use an address (the logical address of your board and device) to obtain a unit descriptor which you can pass to subsequent commands. You can think of the unit descriptor as a reference to your instrument or communication session with that instrument. Thus, you should pass the unit descriptor to functions which take a unit descriptor as a parameter, and not try to pass the address to that parameter.

Repost if you have any other questions or problems!

Best Regards,

JLS

PS - as you program you may find the NI-488.2 User and Function Reference Manuals useful; here are links:


User Manual:
http://digital.ni.com/manuals.nsf/websearch/4FB1A6F4B7FBE91086256F12006DAC33

Function Reference Manual:
http://digital.ni.com/manuals.nsf/websearch/29DA1FC12FBEAF0586256DB300509A79
Best,
JLS
Sixclear
0 Kudos
Message 4 of 5
(4,592 Views)
Thanks again for the reply JLS.
I already have bouth of that documents on my computer. My confusion about unit descriptor and addresses came from the fact that I noticed that some of API functions require udnit descriptor and other an address. I also noticed that the example program is not sending using ibdev function to the Fluke 45 multimeterto get the unit descriptor. But that is all fixed now. I think that I could use some information on two more issues though:
1. Is there a recomended sequence of steps to do at the beggining of each end every program commuinicating with any device through GPIB interface?
I know that first thing is to get an address/es for all the devices. Then it is probably wise to clear all the devices and probably get a unit descriptor for each. But I have read somewhere that I have take my device offline at the end of my program. Why is that? And which function is putting my device online?

2. Another question is about gpibnotify ActiveX component which I am plannig to use soon. I think I have a good idea how it works but my question is about the mask I shoudl set up. I will again talk about the example programm for Fluke 45 multimeter. There is a function Meter_Get_Reading which takes care of transferring data from the meter at appropriate time. It goes like this
A. Call Send(0, Fluke%, "SCPI commands", NLend) - sends SCPI commands to the meter (so this is device dependent)
B. Call WaitSRQ(0, SRQasserted%) - checks if SRQ was asserted by Fluke 45 (service requested)
C. Call ReadStatusByte(o, FLuke%, Status%)
Checks if MAV bit was set by Fluke 45 (it in the status byte)
D. Call Receive - gets the data
My question is How does that sequence of commands translate into properly set mask for GpibNotify ActiveX component?

Thanks again
Marek

Message Edited by Marek2005 on 05-18-2005 05:39 PM

0 Kudos
Message 5 of 5
(4,591 Views)