On 02.12.2016 15:30, Matt Newville wrote:
> But, to summarize the earlier suggestions: if you are embedding pyepics in
> SNL, you might need to create a new CA context in the python script with
> import epics
> epics.ca.context_create(0)
Hi Matt
I may be wrong but I think this is what already happens (implicitly).
The problem is that the newly created context replaces (overwrites) the
old one and then (afterwards) channels created against the old context
fail to work.
My suggestion (to repeat) is to use ca_current_context to get the
existing CA client context on startup (so that you don't overwrite the
existing context with a new one) and to somehow convince the Python
binding to NOT call ca_context_destroy when it exits. For this you could
perhaps use ca_detach_context before Python shuts down (to avoid killing
the existing context) but then you would have to save and restore the
context inside the SNL code. However, perhaps the shutdown is not really
a problem because the Python runtime system is kept alive all the time?
(I.e. as long as the SNL is running) In that case, simply ignore shutdown.
It is important to understand that the CA client library CANNOT have two
CA client contexts active inside the same user thread. If you try that,
strange things start to happen. The reason for this is that the client
context is stored in a fixed location in thread local memory. What you
can do is pull out an existing context, create a new one, work with it,
destroy it, and then restore the old context afterwards (using
ca_attach_context or some such).
You CAN open two channels to the same PV (inside the same client
context) without problems.
Apart from that, I completely agree with your (Matt's) suggestion to do
everything on the Python side. In this (Kevin's) case this would indeed
mean to generate Python code, which I guess isn't that much harder than
generating SNL...
Cheers
Ben
--
"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
- Re: SNL sequencer apparently losing connection to underlying network Benjamin Franksen
- Re: SNL sequencer apparently losing connection to underlying network Matt Newville
- Re: SNL sequencer apparently losing connection to underlying network Kevin Meyer
- Re: SNL sequencer apparently losing connection to underlying network Matt Newville
- Navigate by Date:
- Prev:
Re: Simultaneous Channel access Marty Kraimer
- Next:
RE: Simultaneous Channel access matthew.taylor
- 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 Pearson, Matthew R.
- 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
|