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
|