EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  <20152016  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  <20152016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: RE: multiple asynRecord communication conflict
From: Mark Rivers <[email protected]>
To: "'Zohar, Sioan'" <[email protected]>, "[email protected]" <[email protected]>
Date: Wed, 25 Mar 2015 21:50:51 +0000

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

 

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
Sent: Wednesday, March 25, 2015 10:22 AM
To: [email protected]
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


References:
multiple asynRecord communication conflict Zohar, Sioan
RE: multiple asynRecord communication conflict Mark Rivers
RE: multiple asynRecord communication conflict Zohar, Sioan

Navigate by Date:
Prev: Re: pyepics not updating pv.enum_strs after connection Andrew Johnson
Next: Re: pyepics not updating pv.enum_strs after connection Michael Davidsaver
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  <20152016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: RE: multiple asynRecord communication conflict Zohar, Sioan
Next: Record issue - to set aother record value Amien Crombie [TLABS]
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  <20152016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 16 Dec 2015 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·