Ø
Is there no way to query the IOC to find out if it's done initializing?
From what code do you want to query? The IOC shell? A CA client?
Sophisticated CA clients use connection callbacks. That way your client program gets a callback when Channel Access establishes a connection for that PV. Then you know the IOC is ready. You also know when the IOC goes down, and when
it comes back up.
Mark
From: Tech-talk <tech-talk-bounces at aps.anl.gov>
On Behalf Of Paul Nord via Tech-talk
Sent: Wednesday, June 17, 2020 11:48 AM
To: EPICS tech-talk <tech-talk at aps.anl.gov>
Subject: Re: IOC Startup - init value used sometimes instead of put
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)
> 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
|