Reading from a GPIB device

[LarsUlrich]

I've been trying to make a driver for the keithley 181 but have gotten way to frustrated, so I went with the MacGyver method thinking this would be much simpler, but I still am having problems.

My "GPIB write" function works like a charm, the GPIB address is 5, and to interpret the big large string (in case you are interested) here is what all the letters/numbers mean.

X - initializes the communication

T0 - sets to continuous on talk mode

M0 - sets SRQ to off

R2 - sets my range to 20mV

B1- turns on Hi Res mode

P1 - sets the filter to off

D0 - turns off damping    

The problem is that something goes wrong with either the GPIB Read or the Fract/Exp String to Number, and I can't get the measurement out.

The 5 is the GPIB address again (and is correct because the top part works fine)

The 0 is the mode, which is the default

and the 14 is the number of bytes to read. 

My guess is either the "14" needs to be a different number (does this matter?  If I tell it to read more bytes then the output string actually is, will it not just have extra zeros?)

or I am using a wrong function, either the GPIB read and/or the Fract/exp string to number need(s) to be replaced with another GPIB function.

[LarsUlrich]

[LarsUlrich]

*edit

when I took this screenshot, the bytes to read was at 12, I had been changing it around to see if there was an effect.

[smercurio_fc]

LabVIEW does not exectute code top to bottom or right to left or any other direction when you have code that has no data dependency. In the code you show you have no way of knowing which function will execute first, since there is no data dependency between the two functions. One easy way to do it is to wire the error cluster from the Write into the Read.

You may need to insert a wait between the write and the read. You can use the Time Delay Express VI as a convenient way to do this, as it has error clusters in/out.

For new code you should be using VISA instead of the lower-level GPIB functions.

[LV_Pro]

The first thing I see is that there is nothing that defines which action occurs first. You have both write and read functions in the same loop, without anything forcing the order of execution. You want to wire the error out wire of the GPIB write into a "Time Delay" function with error in/error out terminals, then the error out of that function into the error in of the GPIB read function. Alternatively, at the risk of the wrath of the LabVIEW community, put down a sequence structure, with three frames, put those functions in the frames in the correct, left to right order. The error cluster is a better way, make the loop also conditional on the error not being true. Then you can see what, if any, errors any step generates, by putting an indicator control on the read's error output.

[LarsUlrich]

I was under the impression that it wouldn't matter which one was excecuted first, since the whole thing is looped to infinity.  The device is just a multimeter, and all the top part does (when I say top I only mean the spacial area that the GPIB write function resides in) is set the range to look at.  So even if it excecutes the measure function first, before the range/filter/resolution etc are set, it loops back around and then just takes the measurement again, shouldnt it?

[LarsUlrich]

There is something a should have made a little more clear first: I know that there are correct conventions that you guys like to see in these drivers/VIs, like the visa functions, like not having the GPIB address hardwired to the block diagram (or the control parameters for that matter), or just using the create a driver wizard.

Well, I don't care.

I have been trying to make a respectable driver for this p.o.s. for the past 4-5 days and have come out with nothing but a headache.  I am new to labview and all of those things just make it more complicated.  I would like to be able to write something that works first, and then I can clean it up so its up to todays standards. 

On that note, the stacked sequence may solve my issue if its an order of operations problem, but (see my previous post)

[LarsUlrich]

It is NOT a problem with the order.  I have tried puting them in a stacked sequence loop and that doesn't change anything.

[smercurio_fc]

We have no idea what the top part does. You indicated the commands, but does this mean you get a response? We don't have the instrument or the manual. Is this in reference to other postings? If so, did you indicate what the command does in those other postings? There are literally hundreds of postings on this forum each day. The community isn't following your particular issue alone. All we're responding to is this posting, and from our point of view we see a Write and a Read, disassociated. Hence, with no other information to the contrary, the natural conclusion is that the Write tells the instrument to return some value, and the Read does this. If the Write simply does a configuration, why is it even in the loop?

[LarsUlrich]

I guess it doesn't need to be in the loop.  I do get a response from the write function, the read function doesn't work for some reason though.