Experimental Physics and Industrial Control System
|
Hi Michael,
There have always been issues with "I/O Intr" mode but I thought that version 2
is more stable than version 1. Unfortunately asynDriver does not natively
support unsolicited messages from a device -- at least not without blocking the
port for all other users. Thus I have to poll frequently for new messages. This
makes the code quite hard to debug. (Messages during polling would flood the
screen and change the timing behavior of the system.)
Changing SCAN from "I/O Intr" to anything else aborts the currently running
protocol. Going back to "I/O Intr" restarts the protocol. Thus I guess the
record is waiting for a reaction (data or timeout) and sees neither. The driver
_should_ restart a timer in that case and try again later. It seems this does
not happen. It may be a race condition somewhere in the code (e.g. between
timeout and incoming data). That would explain the rare occurrence.
At the moment, I do not have much time but I will have a look at the problem in
August.
Dirk
Michael Abbott wrote:
Dear Dirk,
I'm sorry this isn't a more helpful report, but I'm continuing to see
problems with stream Device version 2 (my latest test was with version
2.4, I believe) with I/O Intr records.
For a long time (a couple of years, I think) my IOCs would see crashes
when using stream Device v2 on my configuration (which I'll describe in a
moment), so I'm currently running them with stream Device v1 (ported to
3.14). There were some bug fixes in the last year which seem to have
removed the crashes (I think there was some stack overflow). I believe
you've been in communication with some of my colleagues on this.
Unfortunately, in my latest test with v2, I see the following behaviour:
records with I/O Intr processing will suddenly stop processing. This is
*very* rare, on around thirty IOCs I saw this occur twice in a fortnight.
Curiously, if the .SCAN field is changed to Passive and back to I/O Intr
then processing resumes normally!
My IOCs are configured with Hytec 8516 RS-485 cards connected to CMS ION
radiation monitors which send long packets with many fields to decode. A
packet is automatically sent every second, and one record is configured
with SCAN="I/O Intr", and processes the remaining 14 fields contained in
the record. I'm using asyn version 4-10 (and a fair number of other
components on each IOC).
It's a difficult bug to track down, as it seems almost unreproducible, but
alas it occurs often enough that I can't run v2 on my IOCs. I know that
some of my colleagues also see intermittent I/O Intr related issues, but I
don't have details.
I wish I could be more helpful!
Michael Abbott
--
Dr. Dirk Zimoch
Paul Scherrer Institut, WBGB/006
5232 Villigen PSI, Switzerland
Phone +41 56 310 5182
- References:
- Stream Device I/O Intr bugs, ongoing Michael Abbott
- Navigate by Date:
- Prev:
Waveform record updating problem Prachi Chitnis
- Next:
--more-- Waveform record updating problem Prachi Chitnis
- 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:
Stream Device I/O Intr bugs, ongoing Michael Abbott
- Next:
Waveform record updating problem Prachi Chitnis
- 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
|
ANJ, 31 Jan 2014 |
·
Home
·
News
·
About
·
Base
·
Modules
·
Extensions
·
Distributions
·
Download
·
·
Search
·
EPICS V4
·
IRMIS
·
Talk
·
Bugs
·
Documents
·
Links
·
Licensing
·
|