Experimental Physics and
Industrial Control System

Andrew Johnson <[email protected]> · Mon, 17 Sep 2012 13:19:29 -0500

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

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System