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 | 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 |
<== 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 15:02:27 +0100 |
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: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?
> The only remedy is to kill and restart the IOC.
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:From: [email protected]<mailto:[email protected]> [[email protected]<mailto:[email protected]>] on behalf of David Michel [[email protected]<mailto:[email protected]>]
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
________________________________
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