Please also send the complete output when you boot the IOC.
And when it hangs up please send the output of
asynReport 10 "myPort"
Mark
________________________________
From: Mark Rivers
Sent: Thursday, September 04, 2014 8:07 AM
To: David Michel; Emmanuel Mayssat
Cc: EPICS mailing list
Subject: RE: Processing a record a in loop
> although very useful, it didn't really as everything appears normal until the connection is lost...
It would be interesting to see what happens when you let it run for a long time after the errors start. Initially you should get a message about "temporarily unavailable". But if the connection is really dead then eventually the OS should determine this and then asyn will report that the port is disconnected. If the autoconnect flag is 1 then it will try to open the socket again. In some ways that would be equivalent to restarting the IOC.
Can you send the complete asynTrace output with the ASYN_TRACEIO_DRIVER, ASYN_TRACE_ERROR, and ASYN_TRACE_FLOW bits set? Set the timeout to 2 seconds or so to minimize the output.
Mark
________________________________
From: [email protected] [[email protected]] on behalf of David Michel [[email protected]]
Sent: Thursday, September 04, 2014 4:19 AM
To: Emmanuel Mayssat
Cc: EPICS mailing list
Subject: Re: Processing a record a in loop
Hi Emmanuel,
Yes it's an ethernet link using a standard "dumb" network switch and you're quite right about the debugging asynTrace... although very useful, it didn't really as everything appears normal until the connection is lost...
What did you mean exactly with a point-to-point connection? Did you mean no switch and using crossover ethernet cable between the IOC and the device?
Interestingly, the device has a USB port as well. Although I've not tried that with the IOC, the supplier provide a windows app to control the device which works like a charm using the USB port. I've not tried the windows app with the ethernet connection yet though.
So, I was about to try the EPICS IOC with the USB interface, try the windows app with the ethernet interface - this might help me find where the fault lies. Also, I was about to write a simple python script to control the device without EPICS and see If I can reproduce the problem this way or not.
David
On 4 September 2014 00:17, Emmanuel Mayssat <[email protected]<mailto:[email protected]>> wrote:
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]<mailto:[email protected]>
To: [email protected]<mailto:[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
- References:
- Processing a record a in loop David Michel
- RE: Processing a record a in loop Emmanuel Mayssat
- Re: Processing a record a in loop David Michel
- RE: Processing a record a in loop Mark Rivers
- Navigate by Date:
- Prev:
RE: Processing a record a in loop Mark Rivers
- Next:
RE: scalcout with streamDevice - request for guidance and example Mooney, Tim M.
- 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: Processing a record a in loop Mark Rivers
- Next:
Re: Processing a record a in loop David Michel
- 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
|