Hi Andrew,
On 09/17/2012 05:12 PM, Andrew Johnson wrote:
Hi Hinko,
On 2012-09-17 Hinko Kocevar wrote:
If I understand the use of aSub correctly, it does not need allow DTYP
being set. Since I can't bind any device to it, I was hoping that INPx
field(s) might be set to point to INST_IO based link type, something like :
Sorry, I didn't realize you were using the waveform for I/O as well; in that
case you probably still need the waveform record.
No problem, at least I know how is aSub supposed to be used.
@param(PARAM1=abc PARAM2=123)
but that does not seem to work as expected. The problem I see when
trying to get link value (this is from init() at IOC startup):
rec->inpa.value.instio.string ==>> '@param(PARAM1=abc'
ONLY half of string.. where is the other half?
You can't do that. The code must look at the inpa.type field before examining
I can do inpa.type field check too.. but I guess that EPICS code does
its part in determining what the input link should be, before I can get
to its value first.
Does this mean that my INP link value was modified or its just that I'm
not looking at the right place?
Another thing I could bo is change the format of @param() not to include
spaces :)
Will I still in the "you can't do that" zone?
OTOH, since these parameters are meant for the device, I'll probably
resort to an extra "info" field added to the records, that will hold my
@param. With other standard records like ai, bi, ao, bo I could store
this info into INP/OUT field and got away with it, so I was hoping this
holds true for aSub too.
You'll have to read in the array from the waveform using an INP link, process
it, then output it again using an OUT link.
Since we are on the subject of aSub, I was planning on using it for some
other types of data, that would not require INPx links at all - is this
doable?
For that case, all I need is for data to be seen on the OUTx links. What
I was planning to do is, update the outx members of aSub with the data
read from the the device - this would be done in process(). This way I
actually do not need INPx and corresponding waveform records that would
serve INPx. Why I want to avoid waveforms? To avoid copying data from
one buffer to another, since the instrument is quite complex and capable
of providing large amounts of data at high rates (> 100 Hz). Every CPU
cycle wasted, is sought for ..
I'll test the stuff above myself, but I also want to know how my
solution complies with the EPICS way of doing things.
Thanks,
Hinko
- Replies:
- Re: waveform changes using subArray Andrew Johnson
- References:
- Re: waveform changes using subArray Tim Mooney
- Re: waveform changes using subArray Andrew Johnson
- Re: waveform changes using subArray Hinko Kocevar
- Re: waveform changes using subArray Andrew Johnson
- Navigate by Date:
- Prev:
Re: waveform changes using subArray Rod Nussbaumer
- Next:
Re: waveform changes using subArray Hinko Kocevar
- 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: waveform changes using subArray Andrew Johnson
- Next:
Re: waveform changes using subArray Andrew Johnson
- 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
|