Experimental Physics and Industrial Control System
|
Mark,
That makes a tiny bit of sense, but not much. Basically you're saying that iocInit returns before it's completed initializing. Is there no way to query the IOC to find out if it's done initializing?
Here's my workaround for this bug: if self.pv_list.has_key(pvname): while (1 != self.pv_list[pvname].put(value)): #print("Failed to set PV ",pvname, value) time.sleep(1)
Paul
> Calling 'put' inside the device's constructor function is horribly slow (like 5 seconds per PV).
That is to be expected. The PVs don't exist yet, so Channel Access does a search and times out.
Your original outline was quite different, because you had the put() before iocInit. If it is actually after iocInit then I think it is the same problem that Lewis pointed to.
> The workaround of adding a random delay to the startup process does suggest a synchronization failure in EPICS.
If you look at the thread that Lewis pointed to you will see arguments why these are not "failures", particularly this from Ralph Lange:
As for the IOC startup: consider a typical IOC with 1000s of CA connections, and a few typing errors in link target names.
Such an IOC would almost never start.
Or, how hard it would be to start up the control system after a power outage, if every IOC waits for all other IOCs to be up first.
When EPICS is initializing Channel Access links as part of iocInit it does not, and should not, wait for all of the links to connect. Some may never connect because the PV is on another IOC that is not currently running, etc. One does not want iocInit to wait for all of those potential timeouts to occur.
Did you check the status return of your put operations?
Mark
________________________________
From: Tech-talk <tech-talk-bounces at aps.anl.gov> on behalf of Paul Nord via Tech-talk <tech-talk at aps.anl.gov>
Sent: Tuesday, June 16, 2020 4:43 PM
To: EPICS tech-talk
Subject: Re: IOC Startup - init value used sometimes instead of put
Here are some code snipits. Now that I look at it, I did swap steps B and C. Calling 'put' inside the device's constructor function is horribly slow (like 5 seconds per PV).
So, to be more explicit:
A. I create a bunch of PV's with initial values.
B. Load the builder database.
C. Call softioc.iocInit()
D. Call do_startthread() with will call put() for each of the PV's that still need correct values from the configuration files.
RESULT: Some of the PV's get the correct values. Some still show init value.
I do not know exactly what is going on with these python wrappers. I presume that they're just calling EPICS functions of similar names.
The other report on this thread did sound similar. The workaround of adding a random delay to the startup process does suggest a synchronization failure in EPICS.
Paul
main.py
========
....
dev1 = MY_DEVICE(devicename,0, config_file1, map_file, sc_map, readout_map)
dev2 = MY_DEVICE(devicename,1, config_file2, map_file, sc_map, readout_map)
#run the ioc
builder.LoadDatabase()
softioc.iocInit()
dev1.do_startthread()
dev2.do_startthread()
my_device.py
....
self.some_pv.put(value)
On Tue, Jun 16, 2020 at 1:20 PM Mark Rivers <rivers at cars.uchicago.edu<mailto:rivers at cars.uchicago.edu>> wrote:
Paul,
> A little later in the code another configuration file is read for values and put is called.
What do you mean by "put is called"? Is the effectively a Channel Access put? If so, and if you were not using the Python soft IOC the answer to this would be easy. Channel Access puts can only be done after iocInit is complete.
I am not familiar with the Python soft IOC, and I am not sure what you mean by "put", so I am not sure about the timing in that case.
Mark
________________________________
From: Tech-talk <tech-talk-bounces at aps.anl.gov<mailto:tech-talk-bounces at aps.anl.gov>> on behalf of Paul Nord via Tech-talk <tech-talk at aps.anl.gov<mailto:tech-talk at aps.anl.gov>>
Sent: Tuesday, June 16, 2020 12:52 PM
To: EPICS tech-talk
Subject: IOC Startup - init value used sometimes instead of put
Strange problem.
A. I create a bunch of PV's with initial values.
B. A little later in the code another configuration file is read for values and put is called.
C. IOC is started.
D. Some of the PV's get the correct values. Some still show init value.
If I call the configure routine to set the PV's "some time" later, the load reliability.
I can add a 30 second delay, but I've lost confidence that I can guarantee initialization under circumstances where processor load might change. It looks like the "init" value is being set some random time after the PV is created. Possibly even overwriting later calls to put.
I'm using Python Soft IOC.
Thoughts?
Paul
- Replies:
- RE: IOC Startup - init value used sometimes instead of put Mark Rivers via Tech-talk
- References:
- IOC Startup - init value used sometimes instead of put Paul Nord via Tech-talk
- Re: IOC Startup - init value used sometimes instead of put Mark Rivers via Tech-talk
- Re: IOC Startup - init value used sometimes instead of put Paul Nord via Tech-talk
- Re: IOC Startup - init value used sometimes instead of put Mark Rivers via Tech-talk
- Navigate by Date:
- Prev:
Re: EPICS Records at Runtime Jemian, Pete R. via Tech-talk
- Next:
RE: IOC Startup - init value used sometimes instead of put Mark Rivers via Tech-talk
- 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: IOC Startup - init value used sometimes instead of put Mark Rivers via Tech-talk
- Next:
RE: IOC Startup - init value used sometimes instead of put Mark Rivers via Tech-talk
- 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
|
ANJ, 17 Jun 2020 |
·
Home
·
News
·
About
·
Base
·
Modules
·
Extensions
·
Distributions
·
Download
·
·
Search
·
EPICS V4
·
IRMIS
·
Talk
·
Bugs
·
Documents
·
Links
·
Licensing
·
|