Re: asyn reading to waveform records

[Eric Norum <eric@norum.ca>]

This might be possible, but asynOctet is not really intended to handle multi-byte values.
Trying to coerce it to do so is likely to open several wormy cans of things like endian issues and such.


On Feb 1, 2012, at 3:44 PM, Rod Nussbaumer wrote:

> Thanks, Mark & Eric. If need be, I will take that approach, although I'm really hoping I don't have to.
> 
> Is there something I've done wrong in trying to use the waveform record in the way I've done it? It feels like I'm so close, and everything I see in the documentation and in the dbd file suggests it should be possible.
> 
>   --  rod.
> 
> Mark Rivers wrote:
>> I believe that Zen Szalata from SLAC has also recently written Tektronix scope support based on asynPortDriver.
>> 
>> Mark
>> 
>> 
>> -----Original Message-----
>> From: tech-talk-bounces@aps.anl.gov [mailto:tech-talk-bounces@aps.anl.gov] On Behalf Of Rod Nussbaumer
>> Sent: Wednesday, February 01, 2012 1:18 PM
>> To: epics Techtalk
>> Subject: asyn reading to waveform records
>> 
>> Hi All.
>> 
>> As a fallback alternative to my earlier problem reading oscilloscope
>> waveforms with StreamDevice (and to potentially reveal something about
>> the original problem), I am trying to use asyn to read the waveform into
>> a waveform record directly (without the aid of StreamDevice).
>> 
>> If I use the waveform record with FTVL=UCHAR or FTVL=CHAR, and
>> DTYP=asynOctetRead, I am able to acquire the scope binary-formatted data
>> into the waveform record, and I seem to be able to get the performance
>> that I require. However, this method gives me byte oriented data, and
>> the 'scope is sending 16-bit signed data. So, I tried using the
>> FTVL=SHORT, or FTVL=USHORT and DTYP set to any of the
>> 'asynIntXXArrayWfIn' data types. This results in iocInit reporting :
>> 
>>> devAsynInt16Array::initCommon, TEST:SCOPE1:CURVE find asynInt16Array interface failed
>> 
>> Some combinations of FTVL&  DTYP fail with messages like:
>> 
>>> devAsynInt8Array::initCommon, TEST:SCOPE1:CURVE field type must be SIGNED_TYPE or UNSIGNED_TYPE
>> 
>> My application dbd file contains:
>> 
>>> device(waveform,INST_IO,asynWfOctetCmdResponse,"asynOctetCmdResponse")
>>> device(waveform,INST_IO,asynWfOctetWriteRead,"asynOctetWriteRead")
>>> device(waveform,INST_IO,asynWfOctetRead,"asynOctetRead")
>>> device(waveform,INST_IO,asynWfOctetWrite,"asynOctetWrite")
>>> device(waveform,INST_IO,asynInt8ArrayWfIn,"asynInt8ArrayIn")
>>> device(waveform,INST_IO,asynInt8ArrayWfOut,"asynInt8ArrayOut")
>>> device(waveform,INST_IO,asynInt16ArrayWfIn,"asynInt16ArrayIn")
>>> device(waveform,INST_IO,asynInt16ArrayWfOut,"asynInt16ArrayOut")
>>> device(waveform,INST_IO,asynInt32ArrayWfIn,"asynInt32ArrayIn")
>>> device(waveform,INST_IO,asynInt32ArrayWfOut,"asynInt32ArrayOut")
>>> device(waveform,INST_IO,asynFloat32ArrayWfIn,"asynFloat32ArrayIn")
>>> device(waveform,INST_IO,asynFloat32ArrayWfOut,"asynFloat32ArrayOut")
>>> device(waveform,INST_IO,asynFloat64ArrayWfIn,"asynFloat64ArrayIn")
>>> device(waveform,INST_IO,asynFloat64ArrayWfOut,"asynFloat64ArrayOut")
>> 
>> 
>> As yet another possible fallback, is there a way to coerce the
>> byte-oriented data that I acquire to be 16-bit word data, perhaps using
>> a subarray record in some obscure way? I probably do need to use a
>> subarray record anyway, as there is a 6-byte header on the waveform,
>> which I need to drop.
>> 
>> For the record, this is EPICS 3.14.11 and Asyn R4-13 on x86 Linux.
>> 
>> Thanks.
>> 
>> Rod Nussbaumer
>> ISAC Controls, TRIUMF
>> Vancouver, Canada.
>> 
>> 
>> 
> 

-- 
Eric Norum
eric@norum.ca