Experimental Physics and
Industrial Control System

Mark,
thanks a lot for the explanation.
Consistency make sense.

There is a question, still:
Typically the trailing NUL needs to be removed somewhere.
should this be done inside asyn or in each and every driver
(or somewhere else) ?
If in asyn, should it be made configurable in some way ?
What I'm asking for, is if we can allow a waveform record
to send binary data to a device ?




On 07/24/2016 04:00 PM, Mark Rivers wrote:

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]<redir.aspx?REF=sgL1HUsk2c1t9fit3HTDz-OqkdsSufvar8claCYJuz9KL5dPybPTCAFtYWlsdG86cml2ZXJzQGNhcnMudWNoaWNhZ28uZWR1>> 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><redir.aspx?REF=VH6T2IHAhD8fedY_s4uh5FCaBHTMZJ6rY0CJLep-Z1hKL5dPybPTCAFodHRwOi8vd3d3LmFwcy5hbmwuZ292L2VwaWNzL3RlY2gtdGFsay8yMDEyL21zZzAyMjUxLnBocCUzQ2h0dHA6Ly93d3cuYXBzLmFubC5nb3YvZXBpY3MvdGVjaC10YWxrLzIwMTIvbXNnMDIyNTEucGhwJTNF>

asynPortDriver is now doing it that way on read operations.

Mark

Replies:

RE: Inconsistency in devAsynOctet for stringout and waveform records Mark Rivers

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: EPICS-Arduino Serial Communication via Asyn-Stream Drivers 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 

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 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