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  2016  2017  2018  2019  <20202021  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  2016  2017  2018  2019  <20202021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: IOC Startup - init value used sometimes instead of put
From: Paul Nord via Tech-talk <tech-talk at aps.anl.gov>
To: EPICS tech-talk <tech-talk at aps.anl.gov>
Date: Wed, 17 Jun 2020 11:47:46 -0500
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


On Tue, Jun 16, 2020 at 5:14 PM Mark Rivers <rivers at cars.uchicago.edu> wrote:

> 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  <20202021  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  <20202021  2022  2023  2024 
ANJ, 17 Jun 2020 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·