How should the interface to the driver be ?
For readIt(), the driver returns the length of the payload,
and asyn adds 1 for the terminating NUL before going out to the rest of
EPICS.
(Please correct me, if this is wrong)
For writeIt(), I would prefer to use the same principle,
and use the length of the payload, 3 in our case.
This would be in line with what the unix read() and write() functions do,
and, what I understand, the asyn-record does.
And, would need changes for the waveform record.
How many things would this change break ?
On 07/22/2016 10:55 PM, Mark Rivers wrote:
Hi Eric and Andrew (and others),
I have just found an inconsistency in the devAsynOctet.c for handling
string output for stringout records versus waveform records.
I have a stringout record which I process as follows:
caput SIM1:SOHigh "abc"
This is the output of devAsynOctet.c with some debugging statements added:
devAsynOctet::callbackSoWrite, calling writeIt with message="abc",
nbytes=3
This is what happens when I write the same string with a waveform record:
caput -S SIM1:WFOutHigh "abc"
devAsynOctet::callbackWfWrite, calling writeIt with message="abc",
nbytes=4
So in the case of the stringout record the length being passed to the
driver is strlen() of the string, while for the waveform record it is
the NORD field of the waveform record. NORD includes the terminating
0 byte.
This difference in behavior is causing me problems when extending the
Modbus driver to handle strings.
Which do you feel is the “correct” behavior? Should the driver be
called with nbytes including the trailing 0 or not?
You may recall that in asyn R4-21 we made the following change (from
the release notes):
“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.”
So we do include the terminating nil in the length for readOctet. For
consistency it seems like the nil should be included in the length
passed to the driver from writeOctet. This means the stringout record
support is the one that needs to be changed.
Mark
- Replies:
- RE: Inconsistency in devAsynOctet for stringout and waveform records Mark Rivers
- References:
- Inconsistency in devAsynOctet for stringout and waveform records Mark Rivers
- Navigate by Date:
- Prev:
Re: How to configurate MCA for Octave Hulusi Öz
- Next:
Re: Inconsistency in devAsynOctet for stringout and waveform records Eric Norum
- 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:
Inconsistency in devAsynOctet for stringout and waveform records Mark Rivers
- Next:
RE: Inconsistency in devAsynOctet for stringout and waveform records Mark Rivers
- 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
|