Experimental Physics and
Industrial Control System

"Mark Rivers" <[email protected]> · Tue, 15 May 2007 08:44:27 -0500

Hi Ulrik,

For 12-bit data I think the only solution is to blow it up to 32 bits and use asynInt32Array, with a new version of asynInt32Array device support that does the conversion to FTVL.  So it will get blown up on the driver side, and recompressed to 16 bits on device support side.

> This would cause some more processing
> which is not currently critical but may be later on - but at least it
> wouldn't flood the network with 4 times the necessary data.

I'm assuming this is a local (VME?) device and not a network device?

Mark

________________________________

From: Pedersen, UK (Ulrik) [mailto:[email protected]]
Sent: Tue 5/15/2007 8:18 AM
To: Mark Rivers; Dirk Zimoch
Cc: [email protected]
Subject: RE: waveform problem with asyn 4-8

Hi Mark,

Yes, I am currently packing 4 bytes into an epicsInt32 which I think is
slightly horrible but does seems to work fine for the moment... Dirks
suggestion would not work immediately: I would have to modify my module
slightly to (as Dirk also mention) "blow up" my data from 8bit size to
int32-sized (padding with zeros). This would cause some more processing
which is not currently critical but may be later on - but at least it
wouldn't flood the network with 4 times the necessary data.

I will try to use the asynOctet interface now. I was just familiar with
asynInt32Array and didn't realise asynOctet works with WF.

However, my device also does a 12-bit mode (in 16bit words) so I would
like to be able to do 16-bit wide arrays in WF records somehow... - Any
suggestion what I can do in that case?

Cheers,
Ulrik

-----Original Message-----
From: Mark Rivers [mailto:[email protected]]
Sent: 15 May 2007 14:03
To: Dirk Zimoch; Pedersen, UK (Ulrik)
Cc: [email protected]
Subject: RE: waveform problem with asyn 4-8

Hi Ulrik,

You wrote:

> My driver support retrieves a byte-wide array from the device and uses

> asyn Int32Array interface to  send this to a waveform record with the
FTVL field set to "CHAR".

But the old device support did not convert from epicsInt32 to CHAR.  So
the only way this could have worked is if you were packing 4 "chars"
into an epicsInt32 in your driver.  Is that the case?  If so then Dirk's
suggestion will not work, because devAsynIn32Array.c will have to assume
that the epicsInt32 array really contains 1 data point per array
element, not packed data.  It can do the conversion from epicsInt32 to
FTVL, but not in your particular case.

In your case I think the logical thing to do is to change your driver
from using asynInt32 to asynOctet, which already supports waveform
records.

Mark

________________________________

From: Dirk Zimoch [mailto:[email protected]]
Sent: Tue 5/15/2007 6:30 AM
To: Pedersen, UK (Ulrik)
Cc: [email protected]
Subject: Re: waveform problem with asyn 4-8

Hi Ulrik,

in my opinion it should be the responsibility of the devAsynInt32Array
device support to convert the data depending on the FTVL field. The idea
with Int32 was that registers up to 32 bits should be supported.

The documentation says:
"Note that hardware may have registers with smaller sizes, e.g. 16 bit
registers. The standard interfaces can still be used by setting the
unused bits to 0."

Thus, there is no need for 8 and 16 bit interfaces.

But that means your driver has to "blow up" the data by a factor of 4 to
satisfy the asynInt32Array interface and the device support must shrink
the data to the correct size depending on FTVL. Just to skip the check
on FTVL and map longints to 4 bytes does not do the job.

Dirk

Pedersen, UK (Ulrik) wrote:
> Hello,
>
> I've just upgraded from using asyn 4-6 to 4-8 and discovered that a
> small part of my driver support has broken. My driver support
> retrieves a byte-wide array from the device and uses asyn Int32Array
> interface to send this to a waveform record with the FTVL field set to

> "CHAR". The new version of asyn has introduced a check of this field
> in devAsynInt32Array.c initCommon and fails if the field is not set to

> "LONG" or "ULONG".
>
> As my data is only byte-wide, I don't want to fill it into a 32bit
> wide array and set FTVL to "LONG" as that would send out 4 times as
> much data. I guess the "proper" fix would be to implement int8Array
> and int16Array interfaces in devAsyn... Is anyone up for that?
>
> For now, I have just rebuild my own version of asyn with this
> particular check commented out. This way seems to work ok for now as
> the client is requesting the data type from the WF record and it seems

> to just "do the right thing" and retrieves a byte-sized array. I must
> admit that I don't fully understand if commenting out this type
> checking has any complicated implications that may break other
stuff...
>
> Cheers,
> Ulrik
>
> --------------------------------------------------------------------
>
>   Ulrik Pedersen               phone: +44(0)1235-778580
>   Software Engineer            email: [email protected]
>
>       Diamond Light Source Ltd.
>       Rutherford Appleton Laboratory,
>       Chilton, Didcot
>       OxfordShire OX11 0DE
>
> --------------------------------------------------------------------
>

--
Dr. Dirk Zimoch
Computing and Controls
Paul Scherrer Institut
phone +41 56 310 5182
fax   +41 56 310 4413

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System