That would be a workaround, and might solve this problem. But I think
there is a design problem in devGpib that should also be fixed.
Mark
-----Original Message-----
From: Maren Purves [mailto:[email protected]]
Sent: Thursday, July 15, 2010 6:26 PM
To: Mark Rivers
Cc: [email protected]; [email protected]
Subject: Re: devGpib problem
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
>
>
>
- References:
- devGpib problem Mark Rivers
- RE: devGpib problem Mark Rivers
- Re: devGpib problem Maren Purves
- Navigate by Date:
- Prev:
Re: devGpib problem Maren Purves
- Next:
RE: Using Motor Record with READBACK Deadband and number of Retries. Rarback, Harvey M.
- 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 Maren Purves
- Next:
Re: devGpib problem Eric Norum
- 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
|