Re: devGpib problem

[Ron Sluiter <sluiter@aps.anl.gov>]

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
>
>
>