Experimental Physics and
Industrial Control System

On Thu, Dec 1, 2016 at 6:21 AM, Benjamin Franksen <[email protected]> wrote:

On 01.12.2016 10:15, Kevin Meyer wrote:
>
> Yes, the Python program uses pyEpics's epics.caget, but there are
> some complications here:
> 1. The Python context is created in the
> sequencer's global entry block and shut down in the global exit block
> (the PyObject's are initialised there and re-used in subsequent State
> entry calls).

Which method are you using to call Python functions from C?

What happens if you do _not_ shut down the client context? (It may be
necessary to call ca_detach_context to avoid that being done
automatically by some finalizer on the Python side.)

> 2. How would the Python process EPICS get ahold of the
> calling-sequencer's C EPICS context?

I don't know how the Python binding works, but from C you would call
ca_current_context[1] to get the client context and ca_detach_context[2]
when you are done -- the last is so that the context is NOT destroyed
when the Python program exits.

Pyepics does provide 'ca.current_context()', 'ca.attach_context()', 'ca.detach_context()' and so on.   These are very thin wrappings of those provided from the C CA library.

By default, the initial context (that is, the one automatically created on the first access to the CA library) is used for all CA connections.  You have to explicitly tell pyepics to not do this.

By default, pyepics uses preemptive callbacks for nearly all connections.  To disable this, do

    import epics

    epics.ca.PREEMPTIVE_CALLBACK = False

prior to creating any connections.  Or, if you're creating contexts yourself, you can also use
    import epics

    epics.ca.context_create(0)

to create a context that does not use preemptive callbacks.

For Kevin's observation that some 'epics.caget(xxx)' calls work:  Are these channels connecting *only* from Python, or are they also connected by CA in the sequence program?

I don't know of anyone using pyepics from an embedded C program, including an SNL program.  If that process is also doing CA calls, I can believe there could be trouble.  I don't think it *has* to fail, but I think you might be the first person to try this.

As an alternative way of looking at the problem: Is more work being done in the SNL code or in the Python code?  If most of the work is in Python, would it be plausible to move all the logic from the SNL code to a python process?  Pyepics doesn't provide a built-in finite-state-machine, but these are not too hard to write in python.  There are some advantages to having  PVs defined loaded and defined in an IOC and all the logic that interacts with those PVs in a separate process.   That's not saying you shouldn't use the amazing sequencer, but sometimes what you really want is a small program that operates on a set of PVs.