EPICS Home EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

Format page
for printing


Search Tech-talk
1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  <2010>  2011  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  <2010>  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>
Subject: Re: devGpib problem
From: Rod Nussbaumer <[email protected]>
To: [email protected]
Date: Fri, 16 Jul 2010 15:01:27 -0700
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.


Often, there is enough context in the ASCII data returned by instruments to qualify the data of interest. If the power supply returns any sort of header/trailer information along with the data, then one could probably at least use that to identify inappropriate data. Asyn + StreamDevice seems well suited to this problem. Using protocols with exception handlers such as @readtimeout, @replytimeout, and @mismatch as well as using terminators as available would probably go a long way toward handling the problem you describe.

Rod Nussbaumer
ISAC Controls, TRIUMF
Vancouver, Canada


References:
devGpib problem Mark Rivers
Navigate by Date:
Prev: WINDOWS OS Version versus EPICS Ernest L. Williams Jr.
Next: MEDM crash when "Plot Array" of sscan detector with large value J. Lewis Muir
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  <2010>  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: devGpib problem Eric Norum
Next: Soft IOC on Windows PC Gorka Ronda
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  <2010>  2011  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 ·