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: | Emmanuel Mayssat <[email protected]> |
To: | David Michel <[email protected]>, EPICS mailing list <[email protected]> |
Date: | Wed, 3 Sep 2014 16:17:30 -0700 |
Are you using an ethernet link between your IOC and your device?
If so, I have seen this behavior quite a few times. The first thing to try in this case is to set a point to point connection between the IOC and the controlled device. The asynTrace will not help you except to report that... you have lost connection. I think you should share more about your setup. -- Emmanuel Date: Wed, 3 Sep 2014 12:02:01 +0100 Subject: Processing a record a in loop From: [email protected] To: [email protected] 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 |