Hi Hinko,
On 2012-09-17 Hinko Kocevar wrote:
> No problem, at least I know how is aSub supposed to be used.
It's not so much how it's supposed to be used, as what the IOC code does that
I'm explaining. If you want to you can do your I/O from within your aSub
subroutine, but the IOC doesn't parse link addresses the way that you
originally thought they did.
> > 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?
Your subroutine doesn't have access to the original link address string, by
the time your code sees the link field it will have already been parsed and
converted into a struct pv_link (see link.h) which is accessed using the name
inpa.value.pv_link. Note that inpa.value is a union, so inpa.value.instio
sits in exactly the same memory as inpa.value.pv_link. The first member of
both structures is a char* so when you use the name inpa.value.instio.string
you get a valid pointer, but it has already been parsed as a channel name
(which finishes at the first space) and converted into a CA link.
> 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?
Yes, because the dbCa code still thinks it's a CA link and will be doing
Channel Access searches for PV names with that string. Not a good idea.
> 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.
If you're not already using it the DESC field can be useful for this kind of
thing. Unfortunately you can't initialize any of the aSub's input fields with
string values, but if your parameters are numbers you can configure a field to
be any of the numeric types with one element, then put the number into the
INPD field say and it will magically appear in the .D input field. That
conversion from INPD to D only gets run once at initialization time though, to
modify it at run-time just change the .D field directly.
> 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?
Yes, you can put any code you like into sub or aSub records, although you
should avoid them blocking for too long (microseconds is likely to be OK,
milliseconds might not be) as that could delay other records processing in the
same scan task.
> 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 ..
That should work fine. There was one EPICS site that only used records as
communication nodes, they did all of their I/O in subroutine records or
sequence programs and had no hardware device support at all. I don't
particularly recommend that approach for a more complex control system, but if
it does the job you need that's fine!
- Andrew
--
Never interrupt your enemy when he is making a mistake.
-- Napoleon Bonaparte
- Replies:
- Re: waveform changes using subArray Hinko Kocevar
- References:
- Re: waveform changes using subArray Tim Mooney
- Re: waveform changes using subArray Andrew Johnson
- Re: waveform changes using subArray Hinko Kocevar
- Navigate by Date:
- Prev:
Re: waveform changes using subArray Hinko Kocevar
- 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 Hinko Kocevar
- 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
|