Upload from an Electroglas prober

[RussB]

I am having trouble uploading a file (auto alignment data) from an Electroglas 2001 prober using a Windows Forms application developed under Visual Studio 2010.  When I write the "UP" command to the prober, the prober's screen shows XIO BUSY as though it is responding to the request, but I never get a service request from the prober  - i.e. mygpibdevice.Wait(GpibStatusFlags.DeviceServiceRequest) throws a timeout exception, as does mygpibboard.WaitForSrq().  A serflags = mygpibdevice.SerialPoll(); returns 0x00 in serflags.  A statflags = mygpibdevice.GetCurrentStatus(); returns GpibStatusFlags.IOComplete.  Any suggestions on why I'm not getting a DeviceServiceRequest from the prober?  Anyone have code that successfully uploads a file from the prober?

[cstorey · Accepted solution]

Does it expect a termination character at the end of the command string?  Usually you need a specific character at the end of the string you write to an instrument, like "\r" or \n", to tell the instrument that the command string is finished, and it should now go do some work.

I don't have experience with the Electroglas probers, but the Dynamix ones expect a "\r".

Also, you may need to enable the SRQ in order to get it to respond.  If you get a timeout, then set the wait period to something ridiculously long like 10mins and see it transfers in that time.  Remember some of these things have very little memory and take a long time to parse files. 

[RussB]

The required termination character has been set to EOI (which means no terminating character).  After sending the command I use the National Instruments mygpibdev.Wait(GpibStatusFlags.DeviceServiceRequest) command to wait for the SRQ line to be set.  It seems that it is never being set.  All of my other commands function just fine, with the mygpibdev.Wait(GpibStatusFlags.DeviceServiceRequest) command returning right away and the prober doing what I have asked.  I will try your idea of increasing the timeout value (currently at 1 min), but the current timeout already seems excessive for just dumping the first 64 bytes of a file.

[cstorey]

Good that you have the SRQ working for other commands!  Makes it easier to tackle only 1 issue.

64bytes seems like it should process quickly.  How is the file made?  Have you tried various files?  Perhaps there are characters in the file that it doesn't support and it times out trying to parse those?  Try something really simple, perhaps copied from the manual or that was known to work before.  Then build to what you actually want.  

[RussB]

I'm trying to get an internal file out of the prober (there are three or four files that can be obtained from it, I have the same problem regardless of which file I try).  The file is much larger than 64 bytes, but the prober sends it out 64 bytes at a time.  My understanding of the sequence is that I send the command asking for the file, the prober requests service, I perform a serial poll, then I perform a read (repeating the last three steps until no more data).  This sequence is the same as that which I have successfully used to get various pieces of status information (except they are a single read).

[RussB]

cstorey - thanks for the timing suggestion.  Hard for me to believe, but it simply took the prober longer to "prep" the file for transfer than I would have expected.  I set my timeouts to 100s and I got the file.  After a long delay for the first SRQ, the following blocks came through real quickly.

[cstorey]

Ok, I found the manual here - http://www.semistarcorp.com/wp-content/uploads/2014/05/EG2001X-EG-2080-OPERATION-MANUAL.pdf

p138 details the upload protocols.

Sounds like you are doing everything correctly.  Is there a PRU list ready to upload when you are making the call?  Perhpaps it hasn't been aligned and its an empty list?

Note that it says default EOL is \r\n and you say you aren't using termination characters.  Perhaps this is required for uploading?  I wouldn't be surprised if this was undocumented..

[cstorey]

Great to hear!  Yeah these old instruments usually have 8bit processors, and struggle to format and output data quickly.  It always pays to set the timeouts to ridiculously long on the first try and then shorten if needed.

Good luck with the rest of the automation.

Craig