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: Stream device error when processing unsolicited commands
From: Dirk Zimoch <[email protected]>
To: <[email protected]>
Date: Mon, 5 Jan 2015 11:29:35 +0100
Hi Andrew,

This message does not ring a bell. StreamDevice does "lockRequest" at the first 'out' command in a protocol. It unlocks the device at the end of the protocol (or at error). The "I/O Intr" handlers for unsolicited messages normally do not lock the device because they usually do not have 'out' commands. But this seems to be different in your case, right?

Without the protocol it very hard to guess anything. And impossible to test anything. If you do cannot send the real protocol, you may send a "replacement" protocol in which you replace any command with a different string.

Dirk


On 03.01.2015 00:31, Andrew Gomella wrote:
Hi Everyone,

I have a particularly tricky serial device I am working on programming.
To make matters worse it has a very slow response speed to commands.

It sends unsolicited commands, but also does normal request response
messages. I am usually polling the device every 4 seconds while it is
running. Very often when receiving the unsolicited commands I receive
the following error:

2014/12/30 20:14:13.939 timerQueue XR:Message lockRequest:
pasynManager->queueRequest() failed: asynManager::queueRequest is
already queued

I tried searching techtalk but cannot seem to find anyone with a similar
issue. This is very problematic because this device is very slow and the
unsolicited messages are the most important.  Also I should mention that
all commands I receive from the device need to be acknowledged, so
immediately after the "in" string in the protocol follow I have an out
string with the same format.

(Another problem I have is that if the device has messages to send very
close together in timing it will group them into a single message but
with an unpredictable order. I have no idea how to deal with this. I can
imagine a cascading mismatch sequence but this would be very complex. Is
regex the only other option? When it does group the messages they are
delimited by a space, but in all other instances it is just single
messages with no space. I almost need some sort of function to search
for a space and if it finds it to separate the messages, but otherwise
ignore the normal messages).

I'm using stream device 2-6 and asyn4-21. Unfortunately can't post the
db or protocol file because I had to sign a NDA for this device.

Thank you!
Andrew


Replies:
Re: Stream device error when processing unsolicited commands Dirk Zimoch
References:
Stream device error when processing unsolicited commands Andrew Gomella

Navigate by Date:
Prev: Re: Need to migrate from 3.14 to 4.4 Ralph Lange
Next: RE: Need to migrate from 3.14 to 4.4 Mark Rivers
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: Stream device error when processing unsolicited commands Eric Norum
Next: Re: Stream device error when processing unsolicited commands Dirk Zimoch
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 ·