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 | 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 |
<== Date ==> | <== Thread ==> |
---|
Subject: | Stream device: Reading values from two almost identical input strings using I/O intr |
From: | Nicklas Bjärnhall Prytz via Tech-talk <tech-talk at aps.anl.gov> |
To: | "tech-talk at aps.anl.gov" <tech-talk at aps.anl.gov> |
Date: | Thu, 29 Jul 2021 09:17:22 +0000 |
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 {
The result is (from two separate stringin-records):
01002500003 CPS97a00m 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 { And my two records:
record(ai, "$(P)$(DET1):sStringThr2_1") { 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 Best regards,
Nicklas Bjärnhall Prytz M. Sc. E.
Uppsala University, Sweden
|