Re: CryoTel GT Cooler: different startup and shutdown StreamDevice protocols

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

Hello Bo

You can wait for and ignore one line of arbitrary input like this:
in "%*#s";
(The * marks the input as to be ignored, the # tells the %s not to stop reading
at whitepace but only at a null byte, i.e. end of string.)
At least this makes the protocol wait until the device sends any reply, thus
avoiding the situation that another record sends its own request before the
device has finished handling this one. But with this method any error response
will go unnoticed.
Further lines of input will be ignored by the next protocol because 'out'
flushes all remaining input before starting to send anything.
If both your possible replies end with the same string, you may also use that
string as the InTerminator for this protocol. In that case both reply
alternatives will be read as one "line" because then a "line" will no longer be
defined by newline or similar.
I could really be more specific if you would tell me what the possible replies
actually are.

Dirk


On Mon, 2024-05-27 at 07:34 +0200, boj via Tech-talk wrote:
> Dear Ralph
> Thanks for the input. 
> I do indeed not need the response (I can just check later if all went well). 
> However, how do I write an IN protocol statement that will just accept any input from the device (or stated alternatively, empty the serial buffer), my device sends multiple lines (different number of likes for the different responses). 
> With such a strategy, I can just do something like :
> out "command to turn on" 
> wait 
> in "empty buffer"
> 
> Best
>     Bo
> 
> On 24-05-2024 09:09, Ralph Lange via Tech-talk wrote:
> > On Fri, 24 May 2024 at 07:38, boj <lister at f77.dk> wrote:
> > > Thanks for the suggestion.
> > > I read up om the BO record (I am running 3.15) using the HIGH field for the "Push bottom" behavior. 
> > > As I understand that documentation, the record is processed again when going low after the specified time. 
> > > I guess that will mean that the protocol is executed twice?  Any way to avoid that?
> > > 
> > 
> > Yes, correct. No decent way to avoid that.
> > Then, just don't set the HIGH field. Whatever value is being written to the record, the protocol will be executed.
> > 
> > > This brings back the problem that the response from the device depends on its current state 
> > > (it is different when going from On -> Off, and from Off -> Off).
> > > 
> > 
> > As Dirk was asking: Do you need the response? Can't you just ignore it?
> > 
> > > A Simple push button that executes an protocol entry once will be very useful for me.
> > > 
> > 
> > Switch or buttons is a design choice.
> > Buttons always need a status, else you never know the current device state.
> > A switch position needs to be readable from the device or persisted (autoSaveRestore), else it might end up in the wrong position after an IOC reboot.
> > 
> > Discussing with colleagues, I found some very strong, almost religious, opinions in the underlying "trigger by state or by pulse" question.
> > 
> > The EPICS database allows to implement one using the other. Flexibility is nice!
> > 
> > Cheers,
> > ~Ralph
> > 
> > ps. Having a record named after you is pretty cool.