Experimental Physics and
Industrial Control System

Eric Norum <[email protected]> · Thu, 15 Jul 2010 16:42:42 -0700

I'm not sure how this could be fixed completely reliably.

Suppose we added a flush before every write operation.  Then:
	A record starts to process and requests a Write-then-Read operation
		devGpib does a flush, which does nothing
		devGpib does a write
		devGpib does a read -- which times out
		devGpib reports an error condition and the record processing finishes
	Another record starts to process and requests a different Write-then-Read operation
		devGpib does a flush, which does nothing
		devGpib does a write
		devGpib starts a read operation
		the device finally produces a response to the first operation
		devGpib reads this value and interprets it as the response to this command (thus 'volts' are read as 'amps' or some such mess)

It's likely that the next operation would get things straightened around, but I can certainly see pathological cases of timing between write operations and device responses that could keep the above error happening for quite a while.

However, I agree that adding a flush at least prevents the error condition from persisting forever.

Have you looked at the devGpib code at all to see where the flush could be placed?  I have a feeling that there might be several locations that need to have this added.

On Jul 15, 2010, at 4:17 PM, Mark Rivers wrote:

> Folks,
> 
> I was helping Shifu Xu from APS debug a problem talking to a power
> supply using devGpib today, and I think I've found a problem with
> devGpib.  I have never used devGpib myself, so I could be mistaken.
> 
> Shifu's device is a TCP/IP power supply, talking a simple ASCII
> protocol.  When talking to the device it usually responds quickly, but
> occasionally the responses are very delayed.  Whether this is due to the
> device or to the APS network is not clear, but in any event sometimes
> the response does not occur until after the 2 second timeout specified
> in the devGpib file.  However, the device does appear to always
> eventually reply.
> 
> The records in question are input records (volts, current, status, etc.)
> that are periodically processing, and each sends a query and reads the
> response.
> 
> The problem occurs when there is a timeout.  The device does eventually
> send the requested response.  This stale response is read by the TCP
> driver.  The devGpib driver does not appear to do a "flush" before it
> does its atomic write/read operation.  Because it does not do a flush,
> it does a write, but then when it does a read it does not get the new
> data from the device, but rather it gets the stale response to a
> previous command.  Because it is getting stale data, it is not even
> necessarily the response to the correct command, so volts are getting
> read as current, etc.
> 
> It would seem to me that this is really a bug in devGpib, and it should
> always flush any stale data from the port driver before it does the
> write/read operation.
> 
> Is there anyone more familiar than I with devGpib who can comment on
> this?
> 
> Who is taking ownership for devGpib?  It is part of asyn, for which I am
> nominally the contact person, but I really don't want to maintain
> devGpib.
> 
> Eric?
> 
> Thanks,
> Mark
> 

-- 
Eric Norum
[email protected]

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System