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  2015  2016  2017  2018  <20192020  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  <20192020 
<== Date ==> <== Thread ==>

Subject: Re: StreamDevice: termination in binary communication
From: "Zimoch Dirk \(PSI\) via Tech-talk" <tech-talk@aps.anl.gov>
To: "pauly@physik.uni-wuppertal.de" <pauly@physik.uni-wuppertal.de>, "rivers@cars.uchicago.edu" <rivers@cars.uchicago.edu>
Cc: "Tech-talk@aps.anl.gov" <Tech-talk@aps.anl.gov>
Date: Wed, 3 Jul 2019 13:22:44 +0000
Hi Christian,

I just returned from vacation, so please excuse my late reply.

On Tue, 2019-06-18 at 15:08 +0000, Mark Rivers via Tech-talk wrote:
> Hi Christian,
> 
> StreamDevice is using asynOctet to do the actual I/O.  It will not receive anything from the lower asyn layer until one or more conditions are met.
> 
> Assuming you created your asyn port using drvAsynSerialPortConfigure or drvAsynIPPortConfigure with noProcessEos=0 then the port with use the asynInterposeEos layer.
> 
> That layer will return when any of 4 conditions is true.
> 
> 1) The requested input terminator, if any, has been received.
> 2) The requested number of characters to read has been received.
> 3) The specified timeout has occurred.
> 4) An EOI has been received.  This mostly only applies to GPIP.
> 
> It seems like you cannot use the CAN input terminator because it can occur in the data.
> 
> Do you know the exact number of bytes to be received from the device for each command?  If so then you can get it to terminate on condition 2.
> 
> I am not sure how you tell StreamDevice to specify the number of characters to read, but hopefully it can be done.  If not you may need to write your own little driver.
> 
> Mark

In the protocol you can set the (maximum) number of bytes to read:
MaxInput=<number>;
Most binary protocols work with constant length inputs.
(However, that is for all 'in' commands in the protocol if there are more than
one.)

You can have different MaxInput settings in different protocols and/or use
inTerminator in some protocols and MaxInput in others. But whenever you use %r,
a terminator byte is probably not a good idea because it can apprear in the
value.

Also a readTimeout of 10 seconds it much too long for any practical
application. I would only use it as a last resort if no other way of termination
works. And then make it as short as possible.

As Mark already mentioned, StreamDevice can only start parsing the line after
the end of that line had been found. Either by terminator, by number of bytes
or by timeout (or other signals like EOI on GPIB). So there is nothing you can
put in the format string that can make StreamDevice detect the end of the line.

Dirk

> 
> -----Original Message-----
> From: tech-talk-bounces@aps.anl.gov <tech-talk-bounces@aps.anl.gov> On Behalf Of Christian Pauly via Tech-talk
> Sent: Tuesday, June 18, 2019 5:17 AM
> To: EPICS Tech Talk <tech-talk@aps.anl.gov>
> Subject: StreamDevice: termination in binary communication
> 
> Hi folks
> 
> I am struggling with a problem using StreamDevice to control a Monochromator, which has a binary byte-based communication. Each
> (multibyte) message from the device is terminated by a CANCEL byte.
> 
> 
> My first try was to specify the CANCEL byte as Termninator or InTerminator in the protocol file:
> Terminator = 24
> 
> However: Sometimes the Monochromator transmits the wavelength, and it does it as High+Lowbyte raw LONG.
> For certain wavelengths one of the two bytes is a 24, and this is interpreted then as termination character, and i get a protocol error.
> 
> So i tried without Termination character (either Terminator = "", or skipping the line completely), using eg the following IN-statement in the protocol:
> 
> goto {
>        out 16,"%0.2r";
>        in "%(Monochromator:LastStatus)1r",CAN;
> }
> 
> This works fine, as long as the monochromator does not have to turn far:
> The device first sends the status byte, then it turns, and only then sends the CAN byte to signal end of operation.
> This can take up to few seconds, and then i get a timeout error.
> 
> So i tried to set the ReadTimeout in the protocol to 10 seconds.
> Now it works, but now EVERY IN-command waits for 10 seconds, even if the transmission was already complete (and terminated with CAN).
> 
> Is there no way to define the input such, that StreamDevice only waits the whole Timeout period if the transmission was not yet complete ???
> 
> 
> I also tried to use the ! flag:
> in "%!(Monochromator:LastStatus)1r",CAN;
> 
> to tell to expect EXACTLY one byte. But despite updating to the newest 
> StreamDevice2 version, i always get a protocol error
>  > 2019/06/18 12:04:58.809859 _main_ No converter registered for format 
> '%!' when using the ! flag.
> 
> 
> 
> Any helpful ideas ????
> 
> 
> Thanks a lot,
> Cheers,
> Christian
> 
> 

References:
StreamDevice: termination in binary communication Christian Pauly via Tech-talk
RE: StreamDevice: termination in binary communication Mark Rivers via Tech-talk

Navigate by Date:
Prev: RE: [EXTERNAL] Beckhoff BK9000 support survey GAGET Alexis via Tech-talk
Next: pvDatabase Tutorial Marty Kraimer via Tech-talk
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  <20192020 
Navigate by Thread:
Prev: RE: StreamDevice: termination in binary communication Mark Rivers via Tech-talk
Next: Animatics SmartMotor setup Davis, Mark via Tech-talk
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  <20192020 
ANJ, 03 Jul 2019 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·