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  <20162017  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  <20162017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: RE: Inconsistency in devAsynOctet for stringout and waveform records
From: Mark Rivers <[email protected]>
To: Eric Norum <[email protected]>
Cc: "[email protected] list" <[email protected]>
Date: Sat, 23 Jul 2016 23:11:18 +0000
> I think that the question is, “Why does caput -S include the trailing NUL?”.

No, I don't think so.  I just did a test of a waveform record with FTVL=CHAR and using medm to write the string "abc" into that record.  This is what I get in devAsynOctet::writeIt with a debugging printf added:

devAsynOctet:writeIt message=abc, nbytes=4

writeIt is being called with the NORD field for nbytes.

I then did the same test with "dbpf" from the iocsh:

epics> dbpf SIM1:WFOutHigh "abc"
DBR_CHAR[4]:         "abc"
epics> devAsynOctet:writeIt message=abc, nbytes=4

epics> dbpr SIM1:WFOutHigh
ASG:                BUSY: 0             DESC:               DISA: 0
DISP: 0             DISV: 1             NAME: SIM1:WFOutHigh
NORD: 4             SEVR: NO_ALARM      STAT: NO_ALARM      TPRO: 0
VAL: (nil)

epics> dbpf SIM1:WFOutHigh "ab"
DBR_CHAR[3]:         "ab"
epics> devAsynOctet:writeIt message=ab, nbytes=3

epics> dbpr SIM1:WFOutHigh
ASG:                BUSY: 0             DESC:               DISA: 0
DISP: 0             DISV: 1             NAME: SIM1:WFOutHigh
NORD: 3             SEVR: NO_ALARM      STAT: NO_ALARM      TPRO: 0
VAL: (nil)

So writing a string to a waveform record with Channel Access or dbpf also sets NORD to include the nil byte.

So my conclusion is that the stringout behavior in devAsynOctet is incorrect, it is not including the nil byte in the call to writeIt, but it should be.

Mark


________________________________
From: Eric Norum [[email protected]]
Sent: Saturday, July 23, 2016 5:51 PM
To: Mark Rivers
Cc: Andrew Johnson; [email protected] list
Subject: Re: Inconsistency in devAsynOctet for stringout and waveform records

I think that the question is, “Why does caput -S include the trailing NUL?”.
The existing stringout and waveform record behaviour seems right.  A CHAR waveform record can’t till if it is being called on to send ‘long’ strings or arbitrary single-byte data so if told to send N bytes it should do so — it certainly should not try to outguess the caller by looking at the final byte and not sending it if it happens to be ‘\0’.

On Jul 22, 2016, at 1:55 PM, Mark Rivers <[email protected]<redir.aspx?REF=0srAm3Q-cq_wxIEQkRtNEy6_oqC6ZtVLZtqIQkwrjT7cL07cTbPTCAFtYWlsdG86cml2ZXJzQGNhcnMudWNoaWNhZ28uZWR1>> 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?



Replies:
Re: Inconsistency in devAsynOctet for stringout and waveform records Eric Norum
References:
Inconsistency in devAsynOctet for stringout and waveform records Mark Rivers
Re: Inconsistency in devAsynOctet for stringout and waveform records Eric Norum

Navigate by Date:
Prev: Re: Inconsistency in devAsynOctet for stringout and waveform records Eric Norum
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  <20162017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: Inconsistency in devAsynOctet for stringout and waveform records Eric Norum
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  <20162017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 23 Jul 2016 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·