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
<2020>
2021
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
<2020>
2021
2022
2023
2024
|