Experimental Physics and
Industrial Control System

Christoph Schroeder via Tech-talk <[email protected]> · Fri, 30 Nov 2018 16:14:03 +0100

Hi Dirk,

On 11/30/18 11:04 AM, Dirk Zimoch via Tech-talk wrote:

The default ReadTimeout and thus PollPeriod is 100 ms.

are you sure about that? In StreamCore.cc I see pollPeriod = 1000 and
the comment "// use replyTimeout as default for pollPeriod" which is
1000 too.

Best regards,
Christoph

On 11/30/18 11:04 AM, Dirk Zimoch via Tech-talk wrote:

>> I [...] somehow got around it by setting ReadTimeOut and
>> PollPeriod to half of the input rate:
>> rdInputCont{
>>     ReadTimeout = 10;
>>     PollPeriod = 10;
>>     in "%#s";
>> }

Interesting. PollPeriod defines how often "I/O intr" records poll for
input if no other records read input. It defaults to ReadTimeout btw.

So if poll period is too long, some input may pile up and only gets
consumed when the next record reads input or flushes input before
writing. The default ReadTimeout and thus PollPeriod is 100 ms. Thus
in your case up to 6 input messages may be pending in this time. More
if processing the messages takes considerable time. That does not look
too much to me. So I still wonder why the input queue never gets empty.

Having a PollPeriod about half the expected input rate is definitely a
good idea, because it reduces latency (at the cost of CPU usage of
course). Otherwise you will see input in bursts.

Unfortunately despite its name asynOctet does not provide a method to
receive input asynchronously when it arrives. One can only listen
parasitically to the input that someone else reads actively. Thus I
have no choice but to poll. But I also have no idea how to change
asynOctet in a way that an I/O Intr record (i.e. InterruptUser)
neither blocks other records from the port nor steals their input.

So if changing PollPeriod helps please do so. That saves me from
spending a lot of work on a substantial change.

I think I will change the PollPeriod documentation to recommend half
the expected input period.

For completeness: What does PRIO="HIGH" do for you? If the port is
currently locked and several other records queue up for access, then
PRIO="HIGH" records can skip the queue of lower priority records.
(However the currently active record is not interrupted, whatever its
priority is.) I typically use this to give user triggered set records
priority over periodically scanned input records, in particular when
they use up all the available bandwidth of the port or device. In this
case it did not help because the output record was active already but
busy flushing its input queue. So there was no queue of records
waiting for access but a queue of input waiting for records to process
it.

Dirk

On 30.11.2018 10:12, William Kirstaedter wrote:

since this didnt go public...

It worked. I can start and stop now.

so a change shouldnt be necessary anymore ?

William Kirstaedter (PP&B)
Fritz-Haber-Institut der MPG
Faradayweg 4-6
14195 Berlin
Tel: 030 8413 5405
Mail:[email protected]

-------- Weitergeleitete Nachricht --------
Betreff:     Re: streamdevice I/O Intr
Datum:     Fri, 30 Nov 2018 09:57:33 +0100
Von:     William Kirstaedter <[email protected]>
An:     Christoph Schroeder <[email protected]>

Hi Christoph,

thats exactly what Heinz Junkes suggested me a moment ago. :D

I'll try that then...

William Kirstaedter (PP&B)
Fritz-Haber-Institut der MPG
Faradayweg 4-6
14195 Berlin
Tel: 030 8413 5405
Mail: [email protected]

Am 30.11.2018 um 09:46 schrieb Christoph Schroeder:

Hi William,

I remeber, that I had a similar problem with a device which send data
with a 50Hz rate (20ms). I tried setting PRIO of the output record to
high too and it didn't help. I played around with the StreamDevice
variables and somehow got around it by setting ReadTimeOut and
PollPeriod to half of the input rate:
rdInputCont{
    ReadTimeout = 10;
    PollPeriod = 10;
    in "%#s";
}

I didn't had the time to go into detail of the problem and therefore I
don't really understand why that helped. The device seemed worked fine
without any error messages and I somehow forgot about that later since
this was only a temporary setup. Can you try it and tell me if it
helped? Maybe this will help to find the real cause of the problem.

Best regards,
Christoph

On 11/29/18 11:34 AM, William Kirstaedter via Tech-talk wrote:

Hi,

I have a small problem with a fast Device, maybe somebody already had
this problem and can help out? :)

It runs via I/O Intr.
I am able to start the reporting, but I cant stop it. It seems that
the stop command doesnt get through....
could it be that somehow the communication is blocked by the fast
input? how could I fix that?

Its really simple to control:
You send "STM\r", it starts reporting every 18ms
"tmp,<float>,<float>\r"
You send "ETM\r", it stops doing that, terminating communication with
"txx\r".

all ASCII formatted.

my records:

tc.db file:

record(bo, "$(P):$(R):Toggle"){
   field(DESC, "Toggle Reading")
   field(DTYP, "stream")
   field(OUT, "@tc.proto toggle $(BUS)")
   field(ZNAM, "ETM")
   field(ONAM, "STM")
   field(VAL, "0")
}

record(ai, "$(P):$(R):Temperature") {
  field(DESC, "Temperature")
  field (DTYP, "stream")
  field (INP, "@tc.proto read_K $(BUS)")
  field (SCAN, "I/O Intr")
  field(EGU, "K")
}

record(ai, "$(P):$(R):ThermoVoltage"){
  field(DESC, "TC Thermovoltage")
  field(DTYP, "stream")
  field(INP, "@tc.proto read_nV $(BUS)")
  field(SCAN, "I/O Intr")
  field(EGU, "nV")
}

tc.proto file:

Terminator = CR;
ExtraInput = Ignore;

toggle {
        out "%{ETM|STM}";
        in "txx";
};

read_K {
        in "tmp,%f,%*f";
};

read_nV {
        in "tmp,%*f,%f";
};

-- (bb|[^b]{2})

________________________________

Helmholtz-Zentrum Berlin für Materialien und Energie GmbH

Mitglied der Hermann von Helmholtz-Gemeinschaft Deutscher
Forschungszentren e.V.

Aufsichtsrat: Vorsitzender Dr. Karl Eugen Huthmacher, stv.
Vorsitzende Dr. Jutta Koch-Unterseher
Geschäftsführung: Prof. Dr. Bernd Rech (kommissarisch), Thomas
Frederking

Sitz Berlin, AG Charlottenburg, 89 HRB 5583

Postadresse:
Hahn-Meitner-Platz 1
D-14109 Berlin

----------------------------------------------------------------------
Das FHI verarbeitet, speichert und loescht Daten im Rahmen seiner
Geschaeftstaetigkeit gemaess der Datenschutz-Grundverordnung (DSGVO)
[General Data Protection Regulation (GDPR)] der Europaeischen Union.

--
(bb|[^b]{2})

________________________________

Helmholtz-Zentrum Berlin für Materialien und Energie GmbH

Mitglied der Hermann von Helmholtz-Gemeinschaft Deutscher Forschungszentren e.V.

Aufsichtsrat: Vorsitzender Dr. Karl Eugen Huthmacher, stv. Vorsitzende Dr. Jutta Koch-Unterseher
Geschäftsführung: Prof. Dr. Bernd Rech (kommissarisch), Thomas Frederking

Sitz Berlin, AG Charlottenburg, 89 HRB 5583

Postadresse:
Hahn-Meitner-Platz 1
D-14109 Berlin

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System