OK I found it. Use 488.2 commands: SendIFC(0) to initialize the board, use
Receive() and Send() to talk to the device directly. How simple can it be...
when you figure it out.
"Hans D. Jensen" wrote in message
news:3a5471e6@newsgroups.ni.com...
> I have an instrument that appear extremely cranky with GPIB
communications,
> more specifically locking up very easily and doesn't allow multiple reads.
> Now, I am not a GPIB vizard, so I have not been able to find a
satisfactory
> solution and hope for some help for the process.
>
> Short version of my problem: ibwrt() and ibrd() doesn't work satisfactory,
> MLA, MTA combos do. How to get the same performance with high-level GPIB
> commands?
>
> I am using a NI AT-GPIB board under WIndows 95, and eventually want to
write
> a control program using LabWindows/CVI. For now, I am trying things out
> using IBIC and checking things with NISpy. The instrument is a resistance
> bridge, measuring on a platinum resistance termometer (Tinsley Consort
> 5840D)
>
> Problem: I initialize the instrument with ibdev(0,8,0,11,1,2060), ie.
> primary address 8, a short timeout, EOT on, and requesting EOI be set when
> writing the EOS character 0x0D (just to be sure). I can then read the
> current value using ibrd, which is terminated correctly and all that, or
> write a command using ibwrt terminated by the end-of-command character
0x0D
> ("\r") followed by a read. Observation: When writing a command, the bridge
> balance is upset, and it takes some 20 s for the reading to stabilize
again.
> After reading, I see that the END bit is set in ibsta. IF I do another
read,
> the instrument will lock up. If I wait for RSQ (ibwait(0x4800) nothing
> happens (also if I increase the timeout), if I do a serial poll ibrsp
> nothing happens, if I try to trigger the instrument with ibtrg it lock up.
> Observation: The END bit is still set in ibsta whatever command I use.
Only
> by writing an empty command ibwrt("\r") will allow me to read a new value
> (and clear the END bit). I simply cannot find a way to read subsequent
> values without writing a command to the instrument with the balance upset
> and a long waiting time for stabilisation, as a result.
>
> Alternative, that works: After contact to the company, which had no
> solution, but sent me a couple of lines of working code, I found that the
> old HP-Basic (or HT-Basic as you can find nowadays, also for Windows) can
in
> fact read the darned instrument without having to write commands to the
> thing. HT-Basic uses commands like ENTER , 708 to read an instrument
at
> GPIB 8. So with the help of NISpy I looked what was going on, and the
> following happens:
> The instrument is on GPIB address 8. Initially, the board is set up with
PAD
> 21, TMO 1s, no EOT. The interface is cleared(?) with ibsic, the REN is set
> with ibsre(1) and the controller is set on standby(?) with ibgts(0). Then
> comes the reading sequences; they are performed thus: ibcmd("H?5"), which
I
> interpret as MTA21, UNL, MLA8, ie. I talk on 21, unlisten, I listen on 8.
> Then follows a sequence of single byte reads, ibrd, until SRQI and some
> other bits are set in ibsta (ibsta changes from 0x1164 to 0x3164) and the
> read is complete. The next read sequence can start immediately after with
> the ibcmd and the ibrd's etc.
>
> My question: How can I (Can I?) reproduce this behavior with high level
> commands, without having to resort to direct board-device level
> communication? Any help appreciated.
>
> Hans D. Jensen
>
>
>
