Experimental Physics and
Industrial Control System

"Zhang, Dehong" <[email protected]> · Tue, 22 Nov 2011 17:43:49 -0800

Hi Dirk and Mark,

Thank you very much, you solved my problem -- the maxInput=1 did it.
I did not know parameters like these could also be set locally.

In my case (an OPAL 1000 camera), the replies to reads have varing lengthes,
but the replies to the sets are all like ACK or NAK, only one byte.

Thanks for all your generous Givings of great helps!
Dehong

________________________________________
From: Dirk Zimoch [[email protected]]
Sent: Tuesday, November 22, 2011 12:24 AM
To: Zhang, Dehong
Cc: [email protected]
Subject: Re: streamdevice problem with 1 byte reply

Zhang, Dehong wrote:
> Hi,
>
> For some commands, my device replies with only an "ACK" or "NAK",
> no EOS.  Streamdevice gets the byte ok, then gets stuck waiting for
> more input, but there is no more.
>
> We are "still" using base 3.14.9, asyn 4.10 and streamdevice 2.4.
> The replytimeout is set to 900, readtimeout is 100, maxinput is 0.
>
> The problem seems to be asyn not timing out.  Could you guys advise
> on what I may have missed?  Is there a quick fix, instead of upgrading
> the whole complex to new versions?
>
> Thanks much and best regards,
> Dehong
>
>

If a protocol has only ACK as a reply, you can work with maxinput=1 and
no interminator. Interminator and maxinput can both be set on a per
protocol base.

If I understand correctly, none of the replies has a terminator, all
start with ACK (if successful) and probably those which return a value
have a fixed number of characters. Is that correct?

inTerminator="";

simpleCommand {
   maxInput=1;
   out "command";
   in ACK;
}

readValue {
   maxInput=5; # assume 5 char reply: ACK + 4 char int
   out "value?";
   in ACK "%d";
}

Dirk

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System