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.
> 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...
Cheers
Ben
[1]
http://aps.anl.gov/epics/base/R3-14/12-docs/CAref.html#ca_current_context
[2] http://aps.anl.gov/epics/base/R3-14/12-docs/CAref.html#ca_detach_context
--
"Make it so they have to reboot after every typo." ― Scott Adams
Attachment:
signature.asc
Description: OpenPGP digital signature
- Replies:
- Re: SNL sequencer apparently losing connection to underlying network Matt Newville
- 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
- Navigate by Date:
- Prev:
Automatic flat db generation Luca Cavalli
- Next:
Re: SNL sequencer apparently losing connection to underlying network Matt Newville
- 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: SNL sequencer apparently losing connection to underlying network Kevin Meyer
- Next:
Re: SNL sequencer apparently losing connection to underlying network Matt Newville
- 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
|