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: Mon, 25 Jul 2016 15:57:34 +0000

Hi Eric,

 

I have a new proposal that I think can make us both happy.  Andrew agrees that this is the best solution.

 

-          Keep the existing stringout behavior, numchars passed to driver does not include trailing nil

-          Modify waveform output behavior so that if val[nord-1]==0 then it passes numchars=nord-1 else it passes numchars=nord.  This is the device support called asynOctetWrite.  Update the documentation to say that this device support is intended for use only with strings.

-          Add a new device support called asynOctetWriteBinary.  It always passes numchars=nord.

 

This makes the behavior of stringout and waveform records the same for asynOctetWrite.

 

It has 2 potential backwards compatibility issues.  These will be clearly flagged in the release notes.

 

-          Drivers that are expecting to receive numchars that includes the trailing nil for strings from waveform records.  I would be surprised if this is a problem, because such drivers would currently be getting a different behavior with stringout records.

-          Applications that are using devAsynOctet to send binary data to drivers.  Such applications will need their databases changed to use the new asynOctetWriteBinary device support.

 

Mark

 

 

From: Mark Rivers
Sent: Sunday, July 24, 2016 9:00 AM
To: Eric Norum
Cc: [email protected] list
Subject: RE: Inconsistency in devAsynOctet for stringout and waveform records

 

Hi Eric,

 

> O.K., but given the proposal to change stringout support to include the trailing null I don’t see how drivers are going to avoid

> sending null terminators when handling a request from a stringout record.  

 

As I said in my response to Torsten I think it is very rare that devAsynOctet.c is being used to send strings directly to the drvAsynIPPort or drvAsynSerialPort drivers, for example.  Almost everyone uses StreamDevice or other device support for stringout or waveform out records that send strings to hardware.  devAsynOctet is almost always used to send string to "intermediate" drivers like motor, modbus, areaDetector, etc. which may in turn do I/O to the drvAsynIPPort or drvAsynSerial port drivers.

 

In the existing version of asyn if a waveform record is being used in the application you envision then a waveform record WOULD send the null terminator, while a stringout record would not.  But this difference is exactly what I want to avoid.  Since I am not aware of anyone reporting problems with the waveform record, I assume that it is not really a problem.  Making the stringout record be consistent with the waveform record carries a slight risk of breaking existing applications, but I think the benefit to simplifying writing asyn port drivers is worth the risk.

 

Mark

 

 


From: Eric Norum [[email protected]]
Sent: Saturday, July 23, 2016 7:48 PM
To: Mark Rivers
Cc: [email protected] list
Subject: Re: Inconsistency in devAsynOctet for stringout and waveform records

O.K., but given the proposal to change stringout support to include the trailing null I don’t see how drivers are going to avoid sending null terminators when handling a request from a stringout record.  Well I suppose drivers could always sent one byte fewer than every request but that seems even worse.

 

On Jul 23, 2016, at 5:42 PM, Mark Rivers <[email protected]> wrote:

 

This is where I think that caput -S is now doing things incorrectly.


But it is not just caput -S.  It is medm, and dbpf in the IOC shell, etc.  I think that ship has sailed: strings in waveform records include the nil in NORD.  In fact that is what Andrew recommended in this thread for the inverse problem, i.e. reads from a driver:

http://www.aps.anl.gov/epics/tech-talk/2012/msg02251.php<http://www.aps.anl.gov/epics/tech-talk/2012/msg02251.php>

asynPortDriver is now doing it that way on read operations.

Mark

 


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

Navigate by Date:
Prev: Re: MEDM installation error on Linux Mint (libXp.a error) Michael Davidsaver
Next: EPICS-Arduino Serial Communication via Asyn-Stream Drivers Hulusi Öz
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 Mark Rivers
Next: Re: Inconsistency in devAsynOctet for stringout and waveform records Torsten Bögershausen
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, 25 Jul 2016 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·