EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  <20072008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  <20072008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: waveform problem with asyn 4-8
From: Dirk Zimoch <[email protected]>
To: "Pedersen, UK \(Ulrik\)" <[email protected]>
Cc: [email protected]
Date: Tue, 15 May 2007 13:30:45 +0200
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

Replies:
RE: waveform problem with asyn 4-8 Mark Rivers
RE: waveform problem with asyn 4-8 Mark Rivers
References:
waveform problem with asyn 4-8 Pedersen, UK (Ulrik)

Navigate by Date:
Prev: waveform problem with asyn 4-8 Pedersen, UK (Ulrik)
Next: RE: waveform problem with asyn 4-8 Mark Rivers
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  <20072008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: waveform problem with asyn 4-8 Pedersen, UK (Ulrik)
Next: RE: waveform problem with asyn 4-8 Mark Rivers
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  <20072008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 10 Nov 2011 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·