Experimental Physics and Industrial Control System
I'm having trouble getting the pcre converter to show up in my application. The running dbior for the streamApp test IOC shows the regex converter, but with my IOC it doesn't. ldd does show the libpcre and libpcre2 as being loaded in both cases. I'm not sure what's missing.
-----Original Message-----
From: Zimoch Dirk <dirk.zimoch at psi.ch>
Sent: Monday, February 17, 2025 1:37 AM
To: Baily, Scott A <sbaily at lanl.gov>; tech-talk at aps.anl.gov
Subject: [EXTERNAL] Re: StreamDevice Checksum formatting bug
On Mon, 2025-02-17 at 08:31 +0000, Zimoch Dirk via Tech-talk wrote:
> On Sun, 2025-02-16 at 23:11 +0000, Baily, Scott A via Tech-talk wrote:
> > I realize that to represent all possible 16-bit checksums as a decimal number one would need 5 characters, but my device only uses 4. None of the strings are longer than 78 characters so it won’t overflow, but there doesn’t seem to be a way to specify the field width for a checksum (the width and precision specifiers are used for other purposes).
>
> Hi Scott
>
> I checked the source code and found this:
> // get number of decimal digits from number of bytes: ceil(bytes*2.5)
> So for 16 bits it is 5 digits as you found out.
>
> What you can do is to post-process the output using a regular expression:
> "%+<sum16>#-5/.(.*)/\1/"
I lost a % here. Should be:
"%+<sum16>%#-5/.(.*)/\1/"
> This replaces (after inserting the 5 digit checksum) the last 5
> characters with whatever follows the first of those 5 chars (i.e. the
> last 4 digits of the checksum).
>
> Reading such a checksum needs some pre-processing:
> "%#-4/.*/0&/%+<sum16>"
> This replaces (before parsing the 5 digit checksum) the last 4
> characters with itself prefixed by a 0.
>
> Both cases will of course produce nonsense if the sum exceeds 4 chars.
>
> Dirk
>
> > From: Tech-talk <tech-talk-bounces at aps.anl.gov> on behalf of Baily,
> > Scott A via Tech-talk <tech-talk at aps.anl.gov>
> > Sent: Friday, February 14, 2025 11:10:08 AM
> > To: tech-talk at aps.anl.gov <tech-talk at aps.anl.gov>
> > Subject: [EXTERNAL] StreamDevice Checksum formatting bug
> >
> > I seem to be having a problem with the formatting of 16-bit checksums from StreamDevice 2.8.25. When I use a string that ends with “%+<sum16>” in the protocol file, I get the correct checksum in ascii characters as expected, but I have an extra leading 0 (5 characters instead of 4). A checksum that should be “0389” is written as “00389” A similar problem seems to be happening when reading (seems to be expecting an extra leading zero). I can work around this because I know what will be sent and can ignore the checksum on reads,. Has anyone else had this problem? If this is working correctly for you, what version of StreamDevice are you using?
- Replies:
- Re: StreamDevice Checksum formatting bug Zimoch Dirk via Tech-talk
- References:
- StreamDevice Checksum formatting bug Baily, Scott A via Tech-talk
- Re: StreamDevice Checksum formatting bug Baily, Scott A via Tech-talk
- Re: StreamDevice Checksum formatting bug Zimoch Dirk via Tech-talk
- Re: StreamDevice Checksum formatting bug Zimoch Dirk via Tech-talk
- Navigate by Date:
- Prev:
RE: IOC, QServ, and AMSG / alarm.message Ivan Finch - STFC UKRI via Tech-talk
- Next:
Re: IOC, QServ, and AMSG / alarm.message Michael Davidsaver 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
<2025>
- Navigate by Thread:
- Prev:
Re: StreamDevice Checksum formatting bug Zimoch Dirk via Tech-talk
- Next:
Re: StreamDevice Checksum formatting bug Zimoch Dirk 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
<2025>