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: Ron Sluiter <[email protected]>
To: Mark Rivers <[email protected]>
Cc: [email protected]
Date: Fri, 16 Jul 2010 12:54:43 -0500
Mark,

I'm confused, you said Shifu has "a problem talking to a power supply using devGpib".
But then you said, "Shifu's device is a TCP/IP power supply" and "This stale response
is read by the TCP driver".


What is the communication connect to EPICS; GPIB or ethernet?

Ron


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




Replies:
Re: devGpib problem Shifu Xu
Re: devGpib problem Eric Norum
References:
devGpib problem Mark Rivers

Navigate by Date:
Prev: Re: devGpib problem Ralph Lange
Next: Re: devGpib problem Shifu Xu
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 Ralph Lange
Next: Re: devGpib problem Shifu Xu
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 ·