EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  <20102011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  <20102011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: devGpib problem
From: Maren Purves <[email protected]>
To: Mark Rivers <[email protected]>
Cc: [email protected], [email protected]
Date: Thu, 15 Jul 2010 13:25:50 -1000
Can you set the timeout to something long enough to always
catch the response?
(we occasionally do things like that on serial lines)

Maren

Mark Rivers wrote:
One more point: once a timeout occurs the device is hopelessly confused
from that point on, because devGpib is always reading stale responses
from the driver, not the response to the current query.

-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Mark Rivers
Sent: Thursday, July 15, 2010 6:18 PM
To: [email protected]; [email protected]
Subject: devGpib problem

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





Replies:
RE: devGpib problem Mark Rivers
References:
devGpib problem Mark Rivers
RE: devGpib problem Mark Rivers

Navigate by Date:
Prev: RE: devGpib problem Mark Rivers
Next: RE: devGpib problem Mark Rivers
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  <20102011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: RE: devGpib problem Mark Rivers
Next: RE: devGpib problem Mark Rivers
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  <20102011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 02 Sep 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·