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: multiple asynRecord communication conflict |
From: | "Zohar, Sioan" <[email protected]> |
To: | "Rivers, Mark L." <[email protected]>, "[email protected]" <[email protected]> |
Date: | Wed, 25 Mar 2015 16:57:34 +0000 |
Hi Mark,
Thanks for the quick reply.
TMOD is set to Write/Read
Asyn trace reports the asynWrite is successful
Resetting the asynRecord connection restores communications
Running on Linux
I have not run asynReport. I'll give that a try.
I'll put a larger chunk of the trace results below (two are provided. One with the first occurrence of the problem, and one with out the problem for comparison).
Thank you,
Sioan
____________________________________________________________________________________
trace report with observed problem
1=1
2015/03/23 14:47:04.454 23i:MO:PIE709:PZ:ReadServo: inlen=3, nbytesTransfered=3, ntranslate=3
2015/03/23 14:47:04.454 asynManager::portThread port=L2 callback
2015/03/23 14:47:04.454 23i:MO:PIE709:PZ:ReadADControl: asynCallbackProcess, state=3
2015/03/23 14:47:04.454 L2 flush
2015/03/23 14:47:04.454 /dev/ttyS0 flush
2015/03/23 14:47:04.454 23i:MO:PIE709:PZ:ReadADControl flush
2015/03/23 14:47:04.454 /dev/ttyS0 write.
2015/03/23 14:47:04.454 /dev/ttyS0 write 18
SPA? 1 0x06000500
2015/03/23 14:47:04.454 wrote 18 to /dev/ttyS0, return asynSuccess
2015/03/23 14:47:04.454 L2 wrote
SPA? 1 0x06000500
2015/03/23 14:47:04.454 23i:MO:PIE709:PZ:ReadADControl: nwrite=17, status=0, nawt=17
SPA? 1 0x06000500
2015/03/23 14:47:04.454 /dev/ttyS0 read.
2015/03/23 14:47:05.383 L2 addr -1 queueRequest priority 0 not lockHolder
2015/03/23 14:47:05.383 L2 schedule queueRequest timeout
2015/03/23 14:47:05.383 L2 addr -1 queueRequest priority 0 not lockHolder
2015/03/23 14:47:05.383 L2 schedule queueRequest timeout
2015/03/23 14:47:05.449 /dev/ttyS0 timeout handler.
2015/03/23 14:47:05.554 /dev/ttyS0 read 0, return 1
2015/03/23 14:47:05.554 23i:MO:PIE709:PZ:ReadADControl: inlen=0, nbytesTransfered=0, ntranslate=0
2015/03/23 14:47:05.554 asynManager::portThread port=L2 callback
2015/03/23 14:47:05.554 23i:MO:PIE709:PZ:doRead: asynCallbackProcess, state=3
2015/03/23 14:47:05.554 L2 flush
2015/03/23 14:47:05.554 /dev/ttyS0 flush
2015/03/23 14:47:05.554 23i:MO:PIE709:PZ:doRead flush
2015/03/23 14:47:05.554 /dev/ttyS0 write.
2015/03/23 14:47:05.554 /dev/ttyS0 write 5
POS?
2015/03/23 14:47:05.554 wrote 5 to /dev/ttyS0, return asynSuccess
2015/03/23 14:47:05.554 L2 wrote
POS?
_______________________________________________________________________________________
trace report without observed problem
1=1
2015/03/23 14:46:05.453 23i:MO:PIE709:PZ:ReadServo: inlen=3, nbytesTransfered=3, ntranslate=3
2015/03/23 14:46:05.453 asynManager::portThread port=L2 callback
2015/03/23 14:46:05.453 23i:MO:PIE709:PZ:ReadADControl: asynCallbackProcess, state=3
2015/03/23 14:46:05.453 L2 flush
2015/03/23 14:46:05.453 /dev/ttyS0 flush
2015/03/23 14:46:05.453 23i:MO:PIE709:PZ:ReadADControl flush
2015/03/23 14:46:05.453 /dev/ttyS0 write.
2015/03/23 14:46:05.453 /dev/ttyS0 write 18
SPA? 1 0x06000500
2015/03/23 14:46:05.453 wrote 18 to /dev/ttyS0, return asynSuccess
2015/03/23 14:46:05.453 L2 wrote
SPA? 1 0x06000500
2015/03/23 14:46:05.453 23i:MO:PIE709:PZ:ReadADControl: nwrite=17, status=0, nawt=17
SPA? 1 0x06000500
2015/03/23 14:46:05.453 /dev/ttyS0 read.
2015/03/23 14:46:05.508 /dev/ttyS0 read 8
1 0X0600
2015/03/23 14:46:05.508 /dev/ttyS0 read 8, return 0
2015/03/23 14:46:05.508 L2 read
1 0X0600
2015/03/23 14:46:05.508 /dev/ttyS0 read.
2015/03/23 14:46:05.531 /dev/ttyS0 read 7
0500=2
2015/03/23 14:46:05.531 /dev/ttyS0 read 7, return 0
2015/03/23 14:46:05.531 L2 read
0500=2
2015/03/23 14:46:05.531 23i:MO:PIE709:PZ:ReadADControl: inlen=40, status=0, ninp=14
1 0X06000500=2
2015/03/23 14:46:05.531 23i:MO:PIE709:PZ:ReadADControl: inlen=14, nbytesTransfered=14, ntranslate=14
2015/03/23 14:46:06.382 L2 addr -1 queueRequest priority 0 not lockHolder
2015/03/23 14:46:06.382 L2 schedule queueRequest timeout
2015/03/23 14:46:06.382 L2 addr -1 queueRequest priority 0 not lockHolder
2015/03/23 14:46:06.382 L2 schedule queueRequest timeout
2015/03/23 14:46:06.382 L2 addr -1 queueRequest priority 0 not lockHolder
From: Mark Rivers [[email protected]]
Sent: Wednesday, March 25, 2015 10:56 AM To: Zohar, Sioan; [email protected] Subject: RE: multiple asynRecord communication conflict There should be no possibility of such a conflict. asynManager keeps a lock on the drvAsynSerialPort driver so that only one thread can talk to it at a time.
What TMOD are you using with your asyn records, Write/Read, Write, etc.? If you need to do both a write and then a read you should use Write/Read, because that is atomic, no other thread can do a write before the read is performed.
Have you tried turning on asynTrace for the drvAsynSerialPort port? You can then see what is happening.
Have you run asynReport on the drvAsynSerialPort port when it is no longer responding?
Are the asyn records actually still processing when the serial port is no longer communicating?
I have many IOCs with multiple asyn records talking to the same serial port and have never seen a problem.
Is this on Linux or Windows?
Mark
From: [email protected] [mailto:[email protected]]
On Behalf Of Zohar, Sioan
Hi,
I have several asynRecord instances running in a softIOC talking to a single serial port and I suspect they are conflicting.
Everything runs fine for several hours, and then the asynRecord writes stop reaching the serial port. (I confirmed this by sniffing the serial output using the serial port from another computer).
This error is not observed when there is only one instance of the asynRecord.
This problem does not occur on every computer, so perhaps it depends on environment settings?
I've tried daisy chaining the asynRecords by flnk'ing them. Two asynRecords are set to scan = passive, and the other is set to scan = 1 second. I thought this would prevent the possibility of multiple asynrecord instances from talking to the port at once, but the problem persists.
Thanks in advance for your help.
Sioan |