Hi Sioan,
When you are observing the problem Linux is reporting that the write was successful, but that the read timed out:
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: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
This looks to me either like a problem with your device or with the serial port on Linux.
Here is how to test this. When it gets into this bad state simply connect a loop-back connector to the serial port on Linux. This is just a connector that jumpers pins 2 and 3 on the serial port. Using that everything that is written
to the port should then be read back. You can use the asynRecord with the asynOctet.adl medm screen to type some characters and see if they are echoed back. If they are then the serial port is working fine and the problem must be with your device. If the
characters are not echoed back then the problem is with the serial port.
Mark
From: Zohar, Sioan [mailto:[email protected]]
Sent: Wednesday, March 25, 2015 11:58 AM
To: Mark Rivers; [email protected]
Subject: RE: multiple asynRecord communication conflict
Thanks for the quick reply.
TMOD is set to Write/Read
Asyn trace reports the asynWrite is successful
Resetting the asynRecord connection restores communications
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).
____________________________________________________________________________________
trace report with observed problem
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
2015/03/23 14:47:04.454 wrote 18 to /dev/ttyS0, return asynSuccess
2015/03/23 14:47:04.454 L2 wrote
2015/03/23 14:47:04.454 23i:MO:PIE709:PZ:ReadADControl: nwrite=17, status=0, nawt=17
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
2015/03/23 14:47:05.554 wrote 5 to /dev/ttyS0, return asynSuccess
2015/03/23 14:47:05.554 L2 wrote
_______________________________________________________________________________________
trace report without observed problem
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
2015/03/23 14:46:05.453 wrote 18 to /dev/ttyS0, return asynSuccess
2015/03/23 14:46:05.453 L2 wrote
2015/03/23 14:46:05.453 23i:MO:PIE709:PZ:ReadADControl: nwrite=17, status=0, nawt=17
2015/03/23 14:46:05.453 /dev/ttyS0 read.
2015/03/23 14:46:05.508 /dev/ttyS0 read 8
2015/03/23 14:46:05.508 /dev/ttyS0 read 8, return 0
2015/03/23 14:46:05.508 L2 read
2015/03/23 14:46:05.508 /dev/ttyS0 read.
2015/03/23 14:46:05.531 /dev/ttyS0 read 7
2015/03/23 14:46:05.531 /dev/ttyS0 read 7, return 0
2015/03/23 14:46:05.531 L2 read
2015/03/23 14:46:05.531 23i:MO:PIE709:PZ:ReadADControl: inlen=40, status=0, ninp=14
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
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.
|