RE: multiple asynRecord communication conflict

["Zohar, Sioan" <sioan@aps.anl.gov>]

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 [rivers@cars.uchicago.edu]
Sent: Wednesday, March 25, 2015 10:56 AM
To: Zohar, Sioan; tech-talk@aps.anl.gov
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: tech-talk-bounces@aps.anl.gov [mailto:tech-talk-bounces@aps.anl.gov] On Behalf Of Zohar, Sioan
Sent: Wednesday, March 25, 2015 10:22 AM
To: tech-talk@aps.anl.gov
Subject: multiple asynRecord communication conflict

 

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