Experimental Physics and
Industrial Control System

Hinko Kocevar <[email protected]> · Mon, 17 Sep 2012 20:45:02 +0200

On 09/17/2012 08:19 PM, Andrew Johnson wrote:

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.

Ack.

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.

Right, I've just been looking at the aSub dbpr dump with INP set to:

@param(P1=123,P2=33)

that gets completely parsed (no spaces) into INPA, and INPA is CA_LINK.

Bad.

For bi and alike INP is correctly set to INST_IO, but we want to

generalize the code and put this information in one known field if possible.

Can bi, ai, bo, ao and similar live comfortably without their INP/OUT

links defined? We could also resort to a dummy INP/OUT value that would

select INST_IO.

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

Would be a good solution, but @param string could reach lengths beyond

41 chars what DESC can accommodate.

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.

I noticed that numeric values can be set for INP links.

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!

Great! And thanks for the blocking tip .. we'll need to measure that

somehow..

Thanks,
Hinko

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System