Experimental Physics and
Industrial Control System

Mark Rivers <[email protected]> · Tue, 26 Jul 2016 02:32:18 +0000

Yes, a waveform record can send binary data to a device.  With my proposal today it is done by using the new device support called asynOctetWriteBinary.

When waveform records are being used for strings the null is removed in drivers because the length they are passed with asynOctetWrite does not include the null.  The length passed is NORD-1 if VAL[NORD-1] is 0. 

With asynOctetWriteBinary is used the length passed is always NORD.

Mark

________________________________________
From: Torsten Bögershausen [[email protected]]
Sent: Monday, July 25, 2016 9:09 PM
To: Mark Rivers; Eric Norum
Cc: [email protected] list
Subject: Re: Inconsistency in devAsynOctet for stringout and waveform records

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

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System