Can't read GPIB status byte from Electroglas 4080 Prober

[j_osh_o]

I am controlling an Electroglas 4080 prober with GPIB and LabVIEW 7.0 on Solaris.  When I execute a VISA Read STB, the result is always 0.  I want to check the MAV bit in the status byte, and any query command should set this bit.  For example on any other instrument:

Write: *IDN?

Read STB: 20 <== MAV bit 0x10 toggles high (Message AVailable)

Read: <instrument name>

Read STB: 4 <== MAV bit toggles low after message is read and no further messages are queued

The EG4080 documentation states that the prober is equipped with a 488.2 compliant National Instruments GPIB chip.  The *IDN? query works as expected on the prober, other than the fact that it does not set the MAV bit on the STB.  I have used the exact same hardware and software setup on several old instruments in my lab, and in all cases the MAV bit toggled as expected.  Is there a setting I can change to enable the Read STB command?

[Al.B]

hi J_osh_o,

It does seem strange that this status is always returning 0 for this instrument.  Does the computer controlling the EG4080 get a valid status bit for older instruments?  I'd like to see if there is some small setting on this particular computer causing this problem. You also may want to check in the EG4080 documentation to see if there are any settings there that may be preventing this bit from being enabled.  Let me know what you find, and we can continue troubleshooting from there.

[j_osh_o]

The EG4080 does not respond to *STB?, *ESE?, or any of the other standard 488.2 queries other than *IDN?.  This makes me think that the documentation is wrong, and the interface is not 488.2 compliant.  The only GPIB options available through the EG software are serial poll or parallel poll, and SRQ enable/disable.

I have found a way to get my software working without polling the STB.  VISA read is performed repetitively in a while loop with timout set to 50ms.  Then I put the "code" part of the error cluster into the select port of a case structure.  If the error code matches a read timeout, the error is cleared.   There are two more parallel loops: one for UI input, and one consumer loop.  The UI and VISA read loops generate commands and push them onto a queue, and the the commands are executed by the consumer loop.  Since the reads are short, if it is necessary to write to the 4080 over the GPIB bus, it is only necessary to wait 50ms for the read to timeout, and then the write can be performed.

[NimbleThink]

IEEE488.2 compliant does require a small standard set of commands, c.f. http://zone.ni.com/devzone/cda/tut/p/id/3388, of which the Electroglas prober appears to respond only to *IDN?.

Attached is a version of the EG Commander External I/O Commands document, valid for versions 4.8 and up.

It may be wholly or partially applicable to your 4080 prober; most of commands work on my 4090 prober.

Unfortunately I find no descriptions in this manual regarding the Electroglas prober behavior as regards status byte bits; i.e. how do I know when it has a message waiting?

Best of luck with the manual.

Sincerely,

Leif S. Kirschenbaum, Ph.D.

[j_osh_o]

The EG prober can act as a master by sending unsolicited messages to the host.  The problem is that I need to be always listening for these messages, and still be able to send messages back to the prober when I want to.  I have discovered a nasty problem, if the host is not actively waiting for a message on the GPIB bus when the EG prober sends the unsolicited message, the message evaporates and the program hangs because it is waiting for a message from the prober that never comes because the EG thinks it was already sent.  I am not sure if this is the way GPIB is supposed to work, I had assumed that the EG would just buffer the message until the host initiates a read, but this does not seem to be the case.  When I use a VISA_read vi, it locks up the GPIB bus and prevents writes until it times out.  I am using a 2 second timout, so after two seconds the VISA_read vi exits with an error that I clear programmatically.  Then I have a chance to perform any pending writes, after which I read again for messages from the EG.  The host is reading 99.99% of the time, and this seems to be good enough for my application.  Earlier I had set the read timout to 50ms, and this was not enough, I was missing a lot of messages from the EG.  I think the moral of this story is that GPIB is not a good bus if you have asynchronous two way communication.  Luckily is seems my workaround is good enough for my purposes.

[NimbleThink]

Unfortunately such constant VISA reads not only ties up the GPIB bus it also ties up the PC to some extent.

With experimentation with my EG4090 I have found that it asserts the RQS (service request) bit as read by GPIB Serial Poll with a serial poll byte of 64.  This RQS assertion and presence of the status byte 64 (in response to *IDN? or ?MD0S0) lasts until either:

1) I read the available message from the prober

2) the prober times out

I find on the EG4090 that under the Ext I/O configuration there is a setting for the SRQ timeout, and sure enough if I set it to 1 second, 2 seconds, etc. I can repeatedly perform GPIB serial polls and see the RQS bit and value of 64 disappear after that amount of time.  Since this option can take the value of -1 I am assuming that this means that the prober will never time out; i.e it will wait until its message is read.  You may have a similar configuration setting in a menu or a configuration file on the EG4080.  I would assume that even the unsolicited messages (such as the BC1 message I receive when loading the first wafer from a cassette) will assert this bit.

The next step is to use the LabVIEW function "Wait for GPIB RQS" which will perform a wait until the RQS bit is set and then return the serial poll byte.

Regards,

Leif Kirschenbaum

[NimbleThink]

Oh, and I just found that if I issue a *IDN? command and read back 30 bytes to get:

4090.EGCMD-000-5.1.02-0016a.H9

the prober leaves the RQS bit set because I didn't read all of its message, which is actually:

4090.EGCMD-000-5.1.02-0016a.H997090326

So good practice will be to perform a serial poll of the EG 4090 prober after each read to make sure all the bytes have been read.

Leif Kirschenbaum

[Dennis_Knutson]

Or simply request 300 bytes or even 3000 bytes. A read will automatically terminate when EOI is detected. You never have to worry about requsting too many bytes. Doing a serial poll is just not required.

[j_osh_o]

On my prober, SRQ is set to "disabled".  It would be great if there were some setting of the prober so that unsolicited messages would wait for a GPIB read from the host.  My big problem right now is that if the host is not actively reading when the onsolicited message is sent, the message is gone and the program hangs.  The typical sequence is:

1)TS (test start) message is sent from prober.  This tells the host to start testing the die.

2)When die test is complete, host sends TC (test complete) message back to prober.

3)Prober moves to the next die and sends a TS message, and the cycle repeats.

If the host misses the TS message, the program hangs forever, because the host thinks it is still waiting on the prober to finish moving.

My vi has a GPIB read loop, a UI loop, and an action loop.  The action loop is a queued state machine that accepts inputs from the UI and GPIB read loop.  The action loop runs the test, logs data, and sends GPIB messages to the prober.  I guess my design flaw was to design the read loop to just repetitively read until timout and add commands to the QSM when a message is recieved from the prober.  What I should do is make a functional global that tracks exactly what state the prober is in, and use that to determine if the read loop will read or just do nothing. 

I assume someone somewhere has made a control program for the 4080 (likely in Rocky Mountain Basic or C) I would be curious to know how they solved this issue of duplex communication using GPIB.