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.
From: firstname.lastname@example.org <email@example.com> On Behalf Of Christian Pauly via Tech-talk
Sent: Tuesday, June 18, 2019 5:17 AM
To: EPICS Tech Talk <firstname.lastname@example.org>
Subject: StreamDevice: termination in binary communication
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:
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:
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,
- Re: StreamDevice: termination in binary communication Zimoch Dirk (PSI) via Tech-talk
- StreamDevice: termination in binary communication Christian Pauly via Tech-talk
- Navigate by Date:
RE: Animatics SmartMotor setup Mark Rivers via Tech-talk
Re: Animatics SmartMotor setup Davis, Mark via Tech-talk
- Navigate by Thread:
StreamDevice: termination in binary communication Christian Pauly via Tech-talk
Re: StreamDevice: termination in binary communication Zimoch Dirk (PSI) via Tech-talk