EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  <20162017  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  <20162017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: SNL sequencer apparently losing connection to underlying network
From: Matt Newville <[email protected]>
To: Benjamin Franksen <[email protected]>
Cc: Kevin Meyer <[email protected]>, Tech-talk <[email protected]>
Date: Thu, 1 Dec 2016 14:41:29 -0600
Hi Kevin, Ben,

On Thu, Dec 1, 2016 at 6:21 AM, Benjamin Franksen <[email protected]> wrote:
On 01.12.2016 10:15, Kevin Meyer wrote:
>>>> I assume that all the SNL code is executed within some 'main'
>>>> thread of the sequencer. Maybe the call out to python hangs, so
>>>> the core SNL thread is stuck and no longer updating anything.
>>
>> No this is not the case as you found out. A separate thread is
>> spawned for each state set.
>>
>> Does you Python program use CA? If yes, then I have a theory: the
>> problem comes from the Python program trying to create a CA client
>> context, but ending up re-using the one from the state thread. And
>> when the Python ends, the context is destroyed, effectively
>> disabling the state thread's CA capability.
>
> 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.


> 3. The susceptible sequencer still works fine if I stop one of the
> *other* sequencers (that updates two of the PVs) used, above.

I have no idea how to explain this.

>> To test this, replace the Python program with a very simple program
>> that does not import any CA stuff. If the problem persists this
>> means my guess was wrong.
>
> When testing I could get the sequencer to work by commenting out only
> *some* (and leaving in others) of the epics.caget(xxx) calls.

Very strange. Does it matter which caget calls you throw out?

It may be important to know that the sequencer uses
ca_enable_preemptive_callback when creating the context (which is, BTW,
shared by all state sets in all sequencer programs on the same IOC).
This means that the CA client library executes callbacks from a separate
(internal) thread, preempting the thread that makes the CA calls.
Perhaps the Python CA binding cannot cope with this? You could contact
the authors of the Python CA binding to find out more about that...

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.

--Matt Newville

Replies:
Re: SNL sequencer apparently losing connection to underlying network Kevin Meyer
References:
Re: SNL sequencer apparently losing connection to underlying network Kevin Meyer
Re: SNL sequencer apparently losing connection to underlying network Benjamin Franksen
Re: SNL sequencer apparently losing connection to underlying network Kevin Meyer
Re: SNL sequencer apparently losing connection to underlying network Benjamin Franksen

Navigate by Date:
Prev: Re: SNL sequencer apparently losing connection to underlying network Benjamin Franksen
Next: hrSeqCt_ALL pv question 梁雅翔
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  <20162017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: SNL sequencer apparently losing connection to underlying network Benjamin Franksen
Next: Re: SNL sequencer apparently losing connection to underlying network Kevin Meyer
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  <20162017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 02 Dec 2016 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·