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: Stream device error when processing unsolicited commands |
From: | Mark Rivers <[email protected]> |
To: | "'Andrew Gomella'" <[email protected]>, "[email protected] Talk" <[email protected]> |
Date: | Mon, 5 Jan 2015 18:22:37 +0000 |
Hi Andrew, The error message appears to be coming from StreamDevice AsynDriverInterface.c::lockRequest: // interface function: we want exclusive access to the device // lockTimeout_ms=0 means "block here" (used in @init) bool AsynDriverInterface:: lockRequest(unsigned long lockTimeout_ms) { int connected; asynStatus status;
debug("AsynDriverInterface::lockRequest(%s, %ld msec)\n", clientName(), lockTimeout_ms); lockTimeout = lockTimeout_ms ? lockTimeout_ms*0.001 : -1.0; ioAction = Lock; status = pasynManager->isConnected(pasynUser, &connected); if (status != asynSuccess) { error("%s: pasynManager->isConnected() failed: %s\n", clientName(), pasynUser->errorMessage); return false; } status = pasynManager->queueRequest(pasynUser, connected ? priority() : asynQueuePriorityConnect, lockTimeout); if (status != asynSuccess) { error("%s lockRequest: pasynManager->queueRequest() failed: %s\n", clientName(), pasynUser->errorMessage); return false; } // continues with: // handleRequest() -> lockHandler() -> lockCallback() // or handleTimeout() -> lockCallback(StreamIoTimeout) return true; } This part of the error message: asynManager::queueRequest is already queued comes from asynManager. It says that a second call to pasynManager->queueRequest has been made with the same pasynUser structure as an existing queueRequest that has not yet completed. How are you arranging to poll the device every 4 seconds? This may be a case where your should write your own asyn driver rather than using StreamDevice. You could then handle the complex parsing of the combined responses in your C++ code. You could write your driver using asynPortDriver, and call pasynOctetSyncIO->writeRead for the command/response commands and pasynOctetSyncIO->read for the unsolicited messages. Mark From: [email protected] [mailto:[email protected]]
On Behalf Of Andrew Gomella 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 |