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  <20192020  2021  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  <20192020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: StreamDevice problem
From: "Davis, Mark via Tech-talk" <[email protected]>
To: "[email protected]" <[email protected]>
Date: Tue, 8 Oct 2019 15:20:15 +0000
Quick update on this problem:

Turns out that, with my modification to check for duplicate calls for an existing interface, that my local build DOES work.

Apparently our firewall rules where changed again, restricting things even more within our controls network, not allowing the connections I had defined.

But the question still remains: How/why are these redundant calls occurring?  Makes me wonder what other surprises there might be waiting...

Mark


Mark Davis NSCL/FRIB Control Systems Software Engineer [email protected]
On 10/8/2019 10:30 AM, Davis, Mark via Tech-talk wrote:

Having a bit of a problem with the StreamDevice interface that I am hoping someone can help with.

I am trying to get a working build working on a machine running debian stretch (9.9).

The version I am using is a copy of the latest on github, and I can get it to build, but when I run an IOC using the result something very odd is happening during the initialization of the objects for this library.

By adding a printf() call to the loop in the StreamBusInterfaceRegistrarBase(const char* name) constructor in StreamBusInterface.cc, I can see that it is normally called once for 3 derived interfaces:
    • DebugInterface
    • DummyInterface
    • AsynDriverInterface
But for the build on my debian stretch machine, after these 3 calls occur, it is called again for the DebugInterface, which appears to cause an infinite loop (either stuck in the constructor, or calling it endlessly for the same interface.

If I move the "next = NULL;" statement to the end of the constructor, and add a check in the loop for a redundant call ("if *pr == this) return;", then I see that it is being called for the 1st 2 interfaces again, and it avoids the infinite loop, and the IOC processes the startup script, but the asyn connections for the StreamDevice interfaces never connect.

Anyone have any ideas what I should be looking at to determine how/why this is happening?

Mark Davis
NSCL/FRIB





References:
StreamDevice problem Davis, Mark via Tech-talk

Navigate by Date:
Prev: Re: areaDetector compile problem with ffmpegServer step J. Lewis Muir via Tech-talk
Next: comparison of different CA clients: caproto and pyepics Valentyn Stadnytskyi 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  <20192020  2021  2022  2023  2024 
Navigate by Thread:
Prev: StreamDevice problem Davis, Mark via Tech-talk
Next: areaDetector compile problem with ffmpegServer step Michael Westfall 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  <20192020  2021  2022  2023  2024 
ANJ, 08 Oct 2019 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·