Experimental Physics and
Industrial Control System

Dirk Zimoch via Tech-talk <[email protected]> · Fri, 30 Nov 2018 10:07:33 +0100

On 30.11.2018 09:55, William Kirstaedter wrote:

Hi Dirk,

the in "txx"; was only my attempt to have everything correct. (make the

protocol depict reality) From a usability view the "txx" answer doesnt

matter.

Wouldnt it be possible to create an opt-in to skip the input Queue? This

way standard behaviour would remain as is but people like me get the

opportunity to just send data wether or not there is input....

That is a non-trivial change. It will take a while. I need to extend the

interface to the i/o layer. Give me some days...

Dirk

William Kirstaedter (PP&B)
Fritz-Haber-Institut der MPG
Faradayweg 4-6
14195 Berlin
Tel: 030 8413 5405
Mail: [email protected]

Am 30.11.2018 um 08:47 schrieb Dirk Zimoch via Tech-talk:

I just see that your toggle command *does* expect a reply.

toggle {
        out "%{ETM|STM}";
        in "txx";
};

Thus not flushing the input queue is no solution.

On 30.11.2018 08:45, Dirk Zimoch via Tech-talk wrote:

Hi William,

To check Mark's theory please do streamReportRecord on your toggle

record. If Mark is correct then it should show "active command=out".

I'm not sure what to do about it. I don't want to sacrifice handling

unsolicited input. Also not cleaning the input queue is bad for

protocols that have out-in protocols (that is most).

If input arrives so fast that the input queue never gets empty,

then you probably need a faster computer as the EPICS IOC cannot keep

up with the traffic. It also depends on how much processing you do

with the input.

Your java program probably does not care if there is input available

before sending the output. That is because it knows that the command

does not expect any reply. However StreamDevice cannot assume this in

general. I would need to check if the 'out' command is followed by an

'in' (not necessarily immediately) and skip flushing the input queue

if it isn't.

Dirk

On 29.11.2018 17:51, Mark Rivers wrote:

well I dont. I only see the start String "STM\r" but never the stop

String "ETM\r"

That's what I thought.

Here is the start of code for writeHandler.  You should definitely

enable debug, and see if you see these messages ("reading old

input", etc.).  One possibility is that it gets stuck in that loop

if the input is arriving so fast that "received" is never 0.

// now, we can write (called by asynManager)
void AsynDriverInterface::
writeHandler()
{
     debug("AsynDriverInterface::writeHandler(%s)\n",
         clientName());
     asynStatus status;
     size_t written = 0;

     pasynUser->timeout = 0;
     if (!pasynGpib)

     // discard any early input, but forward it to potential async

records

     // thus do not use pasynOctet->flush()

     // unfortunately we cannot do this with GPIB because addressing

a device as talker

     // when it has nothing to say is an error. Also timeout=0 does

not help here (would need

     // a change in asynGPIB), thus use flush() for GPIB.
     do {
         char buffer [256];
         size_t received = 0;
         int eomReason = 0;

         debug("AsynDriverInterface::writeHandler(%s): reading old

input\n",

             clientName());
         status = pasynOctet->read(pvtOctet, pasynUser,
             buffer, sizeof(buffer), &received, &eomReason);
         if (status == asynError || received == 0) break;
#ifndef NO_TEMPORARY

         if (received) debug("AsynDriverInterface::writeHandler(%s):

flushing %ld bytes: \"%s\"\n",

             clientName(), (long)received, StreamBuffer(buffer,

received).expand()());

#endif
     } while (status == asynSuccess);
     else
     {

         debug("AsynDriverInterface::writeHandler(%s): flushing old

input\n",

             clientName());
          pasynOctet->flush(pvtOctet, pasynUser);
     }
     // discard any early events
     receivedEvent = 0;
     pasynUser->timeout = writeTimeout;
     // has stream already added a terminator or should
     // asyn do so?
     size_t streameoslen;
     const char* streameos = getOutTerminator(streameoslen);
     int oldeoslen = -1;
     char oldeos[16];

     if (streameos) // stream has already added eos, don't do it

again in asyn

     {
         // clear terminator for asyn
         status = pasynOctet->getOutputEos(pvtOctet,
             pasynUser, oldeos, sizeof(oldeos)-1, &oldeoslen);
         if (status != asynSuccess)
         {
             oldeoslen = -1;
             // No EOS support?
         }
         pasynOctet->setOutputEos(pvtOctet, pasynUser,
             NULL, 0);
     }
     status = pasynOctet->write(pvtOctet, pasynUser,
         outputBuffer, outputSize, &written);
     debug("AsynDriverInterface::writeHandler(%s): "
         "write(..., outputSize=%ld, written=%ld) "
         "[timeout=%g sec] = %s\n",
         clientName(), (long)outputSize,  (long)written,
         pasynUser->timeout, asynStatusStr[status]);

-----Original Message-----

From: [email protected] <[email protected]>

On Behalf Of William Kirstaedter via Tech-talk

Sent: Thursday, November 29, 2018 10:48 AM
To: Dirk Zimoch <[email protected]>; [email protected]
Subject: Re: streamdevice I/O Intr

well I dont. I only see the start String "STM\r" but never the stop

String "ETM\r"

William Kirstaedter (PP&B)
Fritz-Haber-Institut der MPG
Faradayweg 4-6
14195 Berlin
Tel: 030 8413 5405
Mail: [email protected]

Am 29.11.2018 um 17:46 schrieb Dirk Zimoch via Tech-talk:

On 29.11.2018 17:44, Dirk Zimoch via Tech-talk wrote:

Are you seeing any error messages on the IOC console?  If the problem
is what I describe then I would expect to see queueRequest timeout
error messages.

If StreamDevice could not queue the request, he would not see the
output string in asynTrace.

----------------------------------------------------------------------

Das FHI verarbeitet, speichert und loescht Daten im Rahmen seiner

Geschaeftstaetigkeit gemaess der Datenschutz-Grundverordnung (DSGVO)

[General Data Protection Regulation (GDPR)] der Europaeischen Union.

----------------------------------------------------------------------
Das FHI verarbeitet, speichert und loescht Daten im Rahmen seiner
Geschaeftstaetigkeit gemaess der Datenschutz-Grundverordnung (DSGVO)
[General Data Protection Regulation (GDPR)] der Europaeischen Union.

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System