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  <20132014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  <20132014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: EPICS fsmRecord question
From: Jiro Fujita <[email protected]>
To: Michael Davidsaver <[email protected]>
Cc: Michael Cherney <[email protected]>, [email protected], EPICS tech-talk <[email protected]>
Date: Wed, 17 Jul 2013 19:43:52 +0900
Michael & Wesley,

Thanks for the replies and information.  As Wesley suggests, my contingency plan was to use FLNK and run fsmRecord on a soft IOC somewhere.  This should be fairly easy to do, as we won't have to recompile anything. 

I agree that we should be upgrading EPICS 3.14.  This, however, will open up all the sorts of other issues that we will have to face that we can't deal with at a moment, as we don't have enough man power nor the budget (although I will be working on that this fall on).  Likely scenario for us is to move to MVME3100 and RTEMS as oppose to MVME167/VxWorks combination. 


On Mon, Jul 15, 2013 at 11:28 PM, Michael Davidsaver <[email protected]> wrote:
On 07/13/2013 01:06 AM, Jiro Fujita wrote:
...what is the minimum version of EPICS Base should we be using? 

I developed fsmRecord against 3.14.10 and it should build against newer versions.  Also, it isn't doing anything special, the only part of OSI it uses is epicsMutex, so it will likely build against earlier 3.14 releases.


This is something we probably should have thought about before we started, but for a number of reasons, we didn't. 

And I didn't think to ask...



The subdetector system in question is mostly running EPICS base 3.13 or 3.12 (yes, we still have them around).  For a number of technical reasons it is not all that easy for us to recompile EPICS base 3.12 IOCs (although not impossible, I suppose). 

I wouldn't dream of discourage you from upgrading :)  However, I suspect it would be less work to port fsmRecord back.  If you were considering this you might have a look at StreamDevice which supports 3.13 (specifically the file StreamEpics.cc).  It might be as simple as replacing use of epicsMutex with a vxWorks semaphore.


My thought is we can always edit the database of those IOCs to add flnk to send the PV values to another PVs running on soft IOC somewhere to get the job done (not very elegant, but should work). 

This is possible, but some care is needed.  fsmRecord uses the normal db linking calls, so puts to output CA links queue a request and return immediately.  So the FSM might have to include extra states to check (and wait) until this has happened.


Michael



References:
EPICS fsmRecord question Jiro Fujita
Re: EPICS fsmRecord question Michael Davidsaver

Navigate by Date:
Prev: Re: mbbxDirect SHFT field Florian Feldbauer
Next: RE: mbbxDirect SHFT field Mark Rivers
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  <20132014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: EPICS fsmRecord question Michael Davidsaver
Next: single IOC on Linux with two ports Hovanes Egiyan
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  <20132014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 20 Apr 2015 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·