Re: Stream device error when processing unsolicited commands

[Andrew Gomella <andrewgomella@gmail.com>]

Hi Mark and Eric,

Thank you for the advice. I agree it seems that programming my own code for this is the way to go. 

It turns out if I add a wait command between the in (and corresponding acknowledging out command) I no longer receive the timerQueue error. However, the timing seems to be inconsistent and not always quick enough to allow proper behavior of the device. I removed this wait command as well as polling and it turns out to my surprise that even with the error message the device works well.  It seems the polling (when it conflicts with the unsolicited messages) is causing the erratic behavior which apparently is not related to the timerQueue error messages. 

This is not ideal, but I programmed it such that when I expect the unsolicited commands it no longer polls the device. (The user initiates the device and then it begins sending the unsolicited commands so we kind of know when to not poll the device).

Thanks again for the help.

-Andrew 

 

On Mon, Jan 5, 2015 at 1:22 PM, Mark Rivers <rivers@cars.uchicago.edu> wrote:

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: tech-talk-bounces@aps.anl.gov [mailto:tech-talk-bounces@aps.anl.gov] On Behalf Of Andrew Gomella
Sent: Friday, January 02, 2015 5:31 PM
To: tech-talk@aps.anl.gov Talk
Subject: Stream device error when processing unsolicited commands

 

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