Re: Stream device: Reading values from two almost identical input strings using I/O intr

["Zimoch Dirk \(PSI\) via Tech-talk" <tech-talk at aps.anl.gov>]

Your observation is correct. As the %f comes first, before the char that distinguishes between the formats, the value is already in the record when the protocol mismatches. The record will not process for the wrong value but the value will be in the record. Other records reading this value without synchronization to the record processing may see the wrong value. You may FLNK to another ai record that saves the value and only use that one from other records.

Dirk

Am 29.07.2021 um 11:42 schrieb Nicklas Bjärnhall Prytz via Tech-talk <tech-talk at aps.anl.gov>:



Dear all,

I am using stream device over tcp/ip to communicate with a radiation detector.

I have an issue with reading values from two almost identical input strings except for one character close to the end, which is the parameter code.

The two strings correspond to two parameters, background and threshold values. I can receive and distinguish these strings without difficulty using periodic scanning and the following protocol:

get_btv {

   out  0x01 "000\$114ctr2" $2 "%1<notsum>";

   in 0x01 "%#s";

}

The result is (from two separate stringin-records):

01002500003   CPS97a00m

0100252.000 uSv/hC7a00�

I have put the two parameter codes (characters) in bold, "9" corresponding to background and "C" to threshold. The last char is the checksum.

What I want to read is the 5-width float that comes after "010025" and its engineering units (CPS and uSv/h); the format is exactly the same for both.

Using I/O intr as the record scan type to receive these floats, it seems that although the records process correctly, they also receive each other's output, intermittently.

This might cause problems as other records depend on these values. It seems to me that my two ai records will read and accept any input without first checking for a matching string.

To test this I also read the checksum, which comes after the parameter code (any "faulty" string should thus be discarded before reading).

Here is my protocol:

read_bt2  {

   in 0x01 "0\$10025%5f%*6c" $2 "%*4c%(\$3)r";

}

And my two records:

record(ai, "$(P)$(DET1):sStringThr2_1") {

   field (DESC, "float before req")

   field (DTYP, "stream")

   field (INP, "@dpu.proto read_bt2(1,0x43,$(P)$(DET1):sStringThr2_2) $(PORT)")

   field (SCAN, "I/O Intr")

}

record(ai, "$(P)$(DET1):sStringThr2_2") {

   field (DESC, "checksum after req")

}

Here is output from camonitor, showing that when $(P)$(DET1):sStringThr2_1 (float) changes, $(P)$(DET1):sStringThr2_2 (checksum) stays the same:

[nicklas@oldpc-04 e3-radmon-freia]$ camonitor RadProtFr-Office:GD-01:sStringThr2_1 RadProtFr-Office:GD-01:sStringThr2_2

RadProtFr-Office:GD-01:sStringThr2_1 2021-07-28 13:06:38.246002 00003   CPS  

RadProtFr-Office:GD-01:sStringThr2_2 2021-07-28 13:06:38.245929 \xb7  

^C

[nicklas@oldpc-04 e3-radmon-freia]$ camonitor RadProtFr-Office:GD-01:sStringThr2_1 RadProtFr-Office:GD-01:sStringThr2_2

RadProtFr-Office:GD-01:sStringThr2_1 2021-07-28 13:06:40.245854 2.000 uSv/h  

RadProtFr-Office:GD-01:sStringThr2_2 2021-07-28 13:06:40.245796 \xb7

Best regards,

Nicklas Bjärnhall Prytz M. Sc. E.

Uppsala University, Sweden