I set PRIO LOW on the reading records and PRIO HIGH on the Toggle
record, but it didnt seem to do anything at all.
I now have the following config, which works:
root@kannsein:~# cat /home/epics/FHI/IOCPS/IOCPSApp/Db/tc.*
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")
field(PRIO,"HIGH")
}
record(ai, "$(P):$(R):Temperature") {
field(DESC, "TC Temperature")
field (DTYP, "stream")
field (INP, "@tc.proto read_K $(BUS)")
field (SCAN, "I/O Intr")
field(EGU, "K")
field(PRIO, "LOW")
}
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")
field(PRIO, "LOW")
}
Terminator = CR;
ExtraInput = Ignore;
toggle {
out "%{ETM|STM}";
};
read_K {
in "tmp,%f,%*f";
ReadTimeout = 10;
PollPeriod = 10;
};
read_nV {
in "tmp,%*f,%f";
ReadTimeout = 10;
PollPeriod = 10;
};
root@kannsein:~#
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 11:04 schrieb Dirk Zimoch:
>> 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.
----------------------------------------------------------------------
Das FHI verarbeitet, speichert und loescht Daten im Rahmen seiner
Geschaeftstaetigkeit gemaess der Datenschutz-Grundverordnung (DSGVO)
[General Data Protection Regulation (GDPR)] der Europaeischen Union.
- References:
- Fwd: Re: streamdevice I/O Intr William Kirstaedter via Tech-talk
- Re: Fwd: Re: streamdevice I/O Intr Dirk Zimoch via Tech-talk
- Navigate by Date:
- Prev:
Re: Fwd: Re: streamdevice I/O Intr Dirk Zimoch via Tech-talk
- Next:
Re: Fwd: Re: streamdevice I/O Intr Ralph Lange via Tech-talk
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
<2018>
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
Re: Fwd: Re: streamdevice I/O Intr Dirk Zimoch via Tech-talk
- Next:
Re: Fwd: Re: streamdevice I/O Intr Ralph Lange via Tech-talk
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
<2018>
2019
2020
2021
2022
2023
2024
|
·
Home
·
News
·
About
·
Base
·
Modules
·
Extensions
·
Distributions
·
Download
·