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

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

Dear Dirk and all

Thank you for the help.

I did not know that any "out" command in the protocol flushes the buffer.
Now it works nicely with a appropriate wait command ensuring the 
equipment has ended its output.
Maybe info on clearing the input buffer could be added to the 
documentation of StremDevice (if I did not just overlook it).
Best regards

    Bo



On 27-05-2024 09:30, Zimoch Dirk wrote:
> 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.