EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  <20142015  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  <20142015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: Processing a record a in loop
From: David Michel <[email protected]>
To: Mark Rivers <[email protected]>
Cc: EPICS mailing list <[email protected]>
Date: Wed, 3 Sep 2014 16:09:27 +0100
Hi Mark,

>I don’t think you need to do anything to guarantee that you will not send a request until the first one returned; that is the way asynchronous record processing with StreamDevice works.

Fair enough. To be honest, I wasn't entirely sure of that thus me trying to level my doubts. 

>Are you aware of the asynTrace facility?
No, I wasn't - thanks for that! Though all I can see from it is: 
[timestamp] [ip:port] read 3
[timestamp] [ip:port] write 5
...
So not learning much from this

David



On 3 September 2014 15:14, Mark Rivers <[email protected]> wrote:

> So no evidence... but that's why I wanted to try only sending a request after the first one returned to see if that fixes it.

 

I don’t think you need to do anything to guarantee that you will not send a request until the first one returned; that is the way asynchronous record processing with StreamDevice works.  Once the record sends a request the record is busy (PACT=1) until it either gets a response or times out.  If I understand what you are worried about it is that EPICS could send a second request (“Done?”) before the first one returns a response or times out.  But that should not happen.  Thus if your record is processing with 0.1 second and the response takes 0.2 second then it will not process the record again until the previous processing is complete.

 

Are you aware of the asynTrace facility?  I would highly recommend that you set the ASYN_TRACEIO_DRIVER and ASYN_TRACEIO_ESCAPE bits on the underlying asyn port.  That way you will see all of the communication to and from the device, including time stamps.

 

> Not sure what I would learn from using asyn directly ? Are you thinking of ruling out (or not!) streamdevice as the cause of the issue?

 

Yes, but as I said I think that you will see the same behavior.

 

Mark

 

 

 

From: David Michel [mailto:[email protected]]
Sent: Wednesday, September 03, 2014 9:02 AM


To: Mark Rivers
Cc: EPICS mailing list
Subject: Re: Processing a record a in loop

 

Hi David,

 

Good point about the buffer filling up vs. restarting the IOC... The buffer being full was simply a speculation of mine as to what might be going on... but you're right, restarting the IOC would not be affecting this of course. So no evidence... but that's why I wanted to try only sending a request after the first one returned to see if that fixes it.

 

I think I've managed to do this using the EVENT record... but the problem still persists, so it might not be the device's buffer after all...

 

Not sure what I would learn from using asyn directly ? Are you thinking of ruling out (or not!) streamdevice as the cause of the issue?

 

David

 

p.s. when I say "custom"... I mean a non commercial product made by 3rd party suppliers... nothing that I have direct control of. Just trying to work things out before contacting them.

 

 

 

 

 

 

 

 



---
Dr. David Michel
Address: 8 Viking Drive, Didcot, OX11 9RD, Oxfordshire
Mobile: 0789 670 98 01 - Home: 0123 581 46 93

 

On 3 September 2014 13:39, Mark Rivers <[email protected]> wrote:

Hi David,


In your original message you said:

> Problem is that after a while (~ couple of hours), the device's buffer fills up and doesn't reply anymore.

But in your last message you said:

> The only remedy is to kill and restart the IOC.

That does not really make sense to me.  If the device buffer is full why does restarting the IOC fix the problem?  How does the device know that you did that?

What is the evidence that a buffer is filling up on the device?

You could use an asyn record to do a write/read operation to the device, rather than streamDevice, for testing.  Just put the "done?" in the AOUT field and set the asyn record to periodically process at 1 second.  Do you get the same behavior?  I suspect you will, but it would be interesting to find out.

If it's a custom device can you fix the buffer problem on it if that is indeed the problem?

Mark


________________________________
From: David Michel [[email protected]]
Sent: Wednesday, September 03, 2014 7:24 AM
To: Mark Rivers
Cc: EPICS mailing list
Subject: Re: Processing a record a in loop


Adjusting the time is the first thing I tried of course... but although the typical response time is very short, i.e. a couple of ms, after a while, I get the "No reply from device within x ms" even with a timeout set to something ridiculous like 10000ms

The protocol is very simple:

are_you_done {
    out "done?";
    in "%b";
}

used with a BI record.

I just tried to use an EVENT record: i.e. FWDLINK the BI record to the EVENT record and set the SCAN field of the BI record to that event... but same error eventually comes up.

The only remedy is to kill and restart the IOC.

David


On 3 September 2014 13:08, Mark Rivers <[email protected]<mailto:[email protected]>> wrote:
What is the maximum/typical time between when you send a query and receive a response?

You should be able to set the timeout to a value just longer than the maximum and then you can process the record with any fixed rate (1 seconds, 10 seconds, etc.).  The record will be busy (PACT=1) if the next scan interval happens before the reply from the previous one.  So it will not keep sending query messages, it will wait for a reply before proceeding.

What does your protocol file look like?  Is it a single query per response, etc.?

Mark

________________________________

From: [email protected]<mailto:[email protected]> [[email protected]<mailto:[email protected]>] on behalf of David Michel [[email protected]<mailto:[email protected]>]

Sent: Wednesday, September 03, 2014 6:02 AM
To: EPICS mailing list
Subject: Processing a record a in loop


Hi All,

I'm using StreamDevice to talk to a custom device that doesn't support I/O interrupt so one has to keep sending commands to it to get status information.

Problem is that after a while (~ couple of hours), the device's buffer fills up and doesn't reply anymore. Increasing the ReplyTimeOut improves things slightly, but the problem still eventually occurs.

One potential solution would be to send the next command only once the previous one has returned in a loop (instead of using a set frequency).

Making the record FWD link to itself doesn't seem to do it... I started something using purely database trickery with a FANOUT record set with a fixed SCAN field and disabling it depending on whether the streamdevice record has finished processing or not... but it's getting messy

Is there an elegant way of doing this?

David




 



Replies:
RE: Processing a record a in loop Mark Rivers
Re: Processing a record a in loop Pearson, Matthew R.
References:
Processing a record a in loop David Michel
RE: Processing a record a in loop Mark Rivers
Re: Processing a record a in loop David Michel
RE: Processing a record a in loop Mark Rivers
Re: Processing a record a in loop David Michel
RE: Processing a record a in loop Mark Rivers

Navigate by Date:
Prev: RE: asyn record Mark Rivers
Next: RE: Processing a record a in loop Mark Rivers
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  <20142015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: RE: Processing a record a in loop Mark Rivers
Next: RE: Processing a record a in loop Mark Rivers
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  <20142015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 17 Dec 2015 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·