Struggling to get Keithley 6517B working with LabVIEW 2025 (new to LabVIEW)

[pretendrabit]

Hey everyone, I’m having trouble measuring voltage/current with a Keithley 6517B electrometer in LabVIEW 2025 Q1 Community Edition. I’ve already installed the 6517B drivers but still can’t get it to work the way I want. I’m pretty new to LabVIEW, so any tips or guidance would really help me out. Thanks a lot in advance!

[GerdW]

Hi pretendrabit,

---

@pretendrabit wrote:

I’m having trouble measuring voltage/current

still can’t get it to work the way I want.

---

Which "trouble"? Any errors?

Which way do you want it it be?

On your image:

• You don't need an XYGraph, when the x axis is evenly spaced. Use a waveform graph (showing just the Y array) instead…
• You could even use a simple waveform chart and get rid of the X/Y arrays + shift registers…
• I recommend to use UnbundleByName instead of plain Unbundle to increase code readability.
• You could use the Stall.vim instead of that sequence frame with wait inside…

[altenbach]

Listen to Gerd. 😄

also...

• Your error wire is not connected correctly to the shift register. You never use the left output, so it just acts as a plain tunnel.
• The sequence is pointless because you get the same loop rate and pacing of the IO without it. If you want to delay the fist iteration, you can do that outside the loop.
• You only need one TRUE and one FALSE diagram constant. You can always branch the wire. Wire only inputs where you don't want the default.
• If your loop runs forever, you'll eventually run out of memory.
• ....

(I cannot comment on the instrument "train", because I don't really "do" hardware.)

[Bob_Schor]

A couple of points.

• You should take advantage of some of the basic LabVIEW Tutorials (see, for example, first page of this Forum, also search the Web).
• In particular, you should learn enough to understand how most LabVIEW Data Acquisition works (brief explanation below).
• I'm sure you are aware that the Community Edition cannot be used for either Academic or "commercial" use -- hobbyist (or self-learning) only.  The Keithley 6517B seems like an unlikely "hobbyist" instrument.

LabVIEW is a Data Flow language.  I'm guessing you don't know what this means, but it gives LabVIEW code the possibility of doing several tasks "in parallel".  For example, if you want to acquire a signal at 100 Hz (say, 100 points at 100 Hz), then every second you can expect to get another "buffer" of 100 points.  But while that second is ticking away, you could be processing the previous set of 100 points that you acquired.

LabVIEW (and DAQmx) are designed to facilitate this process.  Many instruments/chips/devices used for data acquisition have built-in "clocks" that specify the acquisition rate (say 100 Hz) far more accurately than Windows (and the LabVIEW "Wait" functions).  You set up your acquisition to acquire 100 points at 100 Hz, and to do it continuously until you say "Stop".  You then start a While Loop that (a) takes a  100-point sample (which takes 1 second) then repeats (unless you've pushed the "Stop" button to exit the While loop).  After it takes the sample, it "packages it up" (either in a Queue or a Stream Messenger) and "exports" it out of the Data Acquisition While Loop (sometimes called the "Producer") to a Data Analysis Loop, running in parallel, that processes these 100 points, perhaps displaying them or saving them to disk (this process is sometimes called the "Consumer".  No Timing functions are explicitly used in either loop -- the Producer runs at the speed set by the Data Acquisition (take 100 points at 100 Hz until told to stop) and the Consumer "consumes" everything it sees, getting one "chunk" of 100 points every second.  Note that the Producer uses no CPU Time except when sending the data to the Consumer (well, it might take a few hundred microseconds to write the 100 points acquired into a Data Buffer array, but that leaves >0.999 seconds left for the Consumer).

Bob Schor