Re: streamdevice I/O Intr

[Dirk Zimoch via Tech-talk <tech-talk@aps.anl.gov>]

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: kirstaedter@fhi-berlin.mpg.de
>
> 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: tech-talk-bounces@aps.anl.gov <tech-talk-bounces@aps.anl.gov> 
> > > > On Behalf Of William Kirstaedter via Tech-talk
> > > > Sent: Thursday, November 29, 2018 10:48 AM
> > > > To: Dirk Zimoch <dirk.zimoch@psi.ch>; tech-talk@aps.anl.gov
> > > > 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: kirstaedter@fhi-berlin.mpg.de
> > > >
> > > > 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.