Ron,
It is TCP/IP communication between the power supply and IOC, the device
support is devGpib.
Shifu
On Fri, 2010-07-16 at 12:54 -0500, Ron Sluiter wrote:
> 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
> >
> >
> >
>
- References:
- devGpib problem Mark Rivers
- Re: devGpib problem Ron Sluiter
- Navigate by Date:
- Prev:
Re: devGpib problem Ron Sluiter
- 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
- Navigate by Thread:
- Prev:
Re: devGpib problem Ron Sluiter
- 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
|