EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

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  <20202021  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  <20202021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: NORD on a char waveform record
From: Mark Rivers via Tech-talk <tech-talk at aps.anl.gov>
To: Thomas Willemsen - UKRI STFC <thomas.willemsen at stfc.ac.uk>
Cc: tech-talk <tech-talk at aps.anl.gov>
Date: Tue, 3 Mar 2020 15:56:37 +0000
I just remembered that there was a tech-talk discussion of this issue in November 2012:


https://epics.anl.gov/tech-talk/2012/msg02251.php


Andrew Johnson said this:


***********************

I recommend (but we don't require) that anything generating a long string
should add a Nil ('\0') terminator byte after the last character and count
that in the number of elements reported for the array (e.g. when setting the
waveform record's NORD field).

***********************

You said you noticed the change in StreamDevice between release 2-5-10 (May 2012) and 2-8-10 (August 2019).  I think Dirk probably followed Andrew's recommendations above, and changed the behavior sometime after November 2012.

Based on Andrew's recommendation I also changed asynPortDriver.  From the release notes for asyn R4-21 (February 2013):

***********************
Changed the code so that the length of string parameters returned in readOctet and octetCallback is now strlen(string)+1, rather than strlen(string). The length thus now includes the terminating nil. This fixes problems with clients that request long strings or subscribe to monitors with a length of 0, but don't check for a nil terminator.
***********************


readOctet is explicitly intended for strings, not binary waveforms.  There are readInt8Array and readUIntArray methods for binary data.


Mark



________________________________
From: Mark Rivers
Sent: Tuesday, March 3, 2020 8:24 AM
To: Thomas Willemsen - UKRI STFC
Cc: tech-talk
Subject: Re: NORD on a char waveform record


> What is the expected behaviour here - in general should NORD on a char waveform be including the NULL terminator or not?


In the asyn device support for the input waveform record NORD does not include the NULL terminator.  That is because that device support does not know if it is reading ASCII or binary data.  It does always NULL terminate the buffer in case it is ASCII data.  If the number of bytes read is exactly equal to NELM then it decrements NORD so that the NULL is not included in NORD.


I believe this has always been the behavior on input waveform records.


On output waveform records the behavior of NORD has changed a couple of times.  You can see this by searching for "nord" in the release notes:


https://epics-modules.github.io/master/asyn/R4-39/RELEASE_NOTES.html


Mark




________________________________
From: Tech-talk <tech-talk-bounces at aps.anl.gov> on behalf of Thomas Willemsen - UKRI STFC via Tech-talk <tech-talk at aps.anl.gov>
Sent: Tuesday, March 3, 2020 7:05 AM
To: tech-talk at aps.anl.gov
Subject: NORD on a char waveform record


Hi,



We have recently updated several support modules, including streamdevice, and have noticed the following change in behaviour:



We have a device whose stream device protocol file looks like:



    InTerminator = CR;

    OutTerminator = CR;



    get_MEASUREMENTS {

        out "MM,1111111111111111";

        in "MM,1111111111111111%s";

    }



Linked to a record that looks like:



    record(waveform, "$(P)STATUS:RAW")

    {

        field(DTYP, "stream")

        field(FTVL, "CHAR")

        field(NELM, "512")

        field(INP, "@kynctm3k.proto get_MEASUREMENTS $(PORT)")

        field(SCAN, "1 second")

    }



The messages to and from the device look as follows:



    2020/03/03 11:55:09.948 localhost:52209 write 20

    MM,1111111111111111\r

    2020/03/03 11:55:09.951 localhost:52209 read 164

    MM,1111111111111111,+FFFFFFF,+004.000,-FFFFFFF,+008.000,-FFFFFFF,+012.000,+FFFFFFF,+016.000,+FFFFFFF,+020.000,-FFFFFFF,+024.000,+FFFFFFF,+028.000,-FFFFFFF,+032.000\r



Under streamdevice 2.5.10, this sets the NORD field of the waveform to 144. Under streamdevice 2.8.10, the NORD field is set to 145 - but

the actual string is unchanged, suggesting that the NULL terminator may now be being included in the NORD count. Unfortunately this broke

one of our drivers, which checked the length of the response before doing some processing.



What is the expected behaviour here - in general should NORD on a char waveform be including the NULL terminator or not?



Thanks,

Tom

References:
NORD on a char waveform record Thomas Willemsen - UKRI STFC via Tech-talk
Re: NORD on a char waveform record Mark Rivers via Tech-talk

Navigate by Date:
Prev: RE: EPICS on windows10 Debian Shell Freddie Akeroyd - UKRI STFC via Tech-talk
Next: defining a path of PVA for EPICS base 3.x Jong Woo Kim 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  <20202021  2022  2023  2024 
Navigate by Thread:
Prev: Re: NORD on a char waveform record Mark Rivers via Tech-talk
Next: defining a path of PVA for EPICS base 3.x Jong Woo Kim 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  <20202021  2022  2023  2024 
ANJ, 03 Mar 2020 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·