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 <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
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

Replies:: RE: multiple asynRecord communication conflict Mark Rivers

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

Navigate by Date:: Prev: Re: pyepics not updating pv.enum_strs after connection Dirk Zimoch; Next: Re: pyepics not updating pv.enum_strs after connection Dirk Zimoch; 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: RE: multiple asynRecord communication conflict Mark Rivers; Next: RE: multiple asynRecord communication conflict Mark Rivers; 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, 16 Dec 2015

· Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System