Experimental Physics and
Industrial Control System

"Zimoch Dirk \(PSI\) via Tech-talk" <[email protected]> · 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: [email protected] <[email protected]> On Behalf Of Christian Pauly via Tech-talk
> Sent: Tuesday, June 18, 2019 5:17 AM
> To: EPICS Tech Talk <[email protected]>
> 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
> 
> 

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System