| 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 | 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 |
| <== Date ==> | <== Thread ==> |
|---|
| Subject: | Re: EPICS Application Package |
| From: | Jeong Han Lee <[email protected]> |
| To: | [email protected] |
| Date: | Wed, 17 Oct 2018 23:54:17 +0200 |
Hi,Since many years, ESS tried to find a better way to handle its EPICS environment. I don't know the entire history, but CODAC was the first place. After Timo joined ESS, he initiated his vision to make "an upgraded PSI environment". The bad reputation we had so far, because of many technical and specific issues.
One year ago, accidentally and intentionally, I engaged this activity because Timo had no time to implement his vision into the reality and I also would like to see somethings which I didn't know and I didn't understand if I could follow his vision. Now, I understood why Tim would like to implement this environment and I understood his vision a little.
From PSI, Dick's invisible support given me so far is great, I've learned many things from his "struggled" and "struggling" codes. I hope, in near future, these environment could be one of EPICS standard environment.
I completely *rebooted* ESS EPICS environment since one year, and changed its name as e3 which the bespoke version for ESS, based on the PSI version. However, the way ESS handles each base/module is the same as PSI one. We only use the PSI require module as the shoulders of giants.
It is the still early stage (There are many features I would like to change and add), but I think, there are some good things you may find it. We, actually, didn't release it within ESS officially. but we've deployed many systems as "standalone" environment already. Most IOCs which we've checked have no strange memory issues, and no abnormal CPU loads in "normal" OS (Debian/CentOS). We are evaluating e3 with RT PREEMPT Linux now. The system which we've controlled seriously, we didn't see any issues on that IOCs also.
It doesn't use the standard EPICS building system, but "rebooted" e3 uses the standard makefile in order to compile it within our environment. I copied many ideas from the EPICS building system into the e3 building system, because my final goal to create "rules" and "config" for e3 within EPICS base. I actually tested the "future" e3 with the standard EPICS building system, it worked. And that is the future plan.
By the way, e3 covers more than "compile", and "install". I tried to embed many scenarios into e3 in order to handle them almost all within the ESS life cycle. For example, I hate to spend my time to figure out which one I have to use within infinite-branches, don't have time to keep up-to-date my master branch with epics community one. To save local resources, to focus many problems we have to resolve, and to give developers to select which way they want to use within reasonable limitations, and to keep everything consistent are the main goal. And we would like to duplicate a specific e3 version at any time domain within the entire ESS life time in anywhere (many stakeholders we have) whenever we would like to do.
In addition, due to resources which we have, the main strategy e3 has is "Discrete Integration, and Deployment". We are testing almost all bases/modules (Continuous), but we select few versions (discrete) of bases/modules which we would like to deploy. It actually saves a lot of our resources, which we can spend more to make "running machines", instead of machine learning. :)
I am preparing to write a formal paper to describe what I've done so far. I hope I can share it with this valuable collaboration all together. And we are also developing several additional plans for "shared" directories, consistent accessible environment to each IOC, and so on slowly.
I think, in next Spring meeting, I could present them with some delightful use cases and valuable results without a romantic plan. :)
Thanks, Han On 10/16/18 2:14 PM, Jeong Han Lee wrote:
Hi, Quite interesting discussion, because ESS mentioned several times here.I am busy these days, so I cannot reply in detail what we are doing here. But if one would like to see what ESS is doing as follows:* https://github.com/icshwi/e3 ; (development) * https://github.com/icshwi/e3-builder ; (production)Someday later, if I can, I will present e3 (ESS EPICS environmet) in EPICS collaboration meeting. I hope I could do this in next spring meeting.If one would like to copy the entire standard epics, I would like to look at the following repo:https://github.com/jeonghanlee/epics_builder However, it is not for the "production", but for the "personal usage". HTH, Han On 10/12/18 8:55 PM, Johnson, Andrew N. wrote:On 10/12/2018 01:06 PM, Hinko Kocevar wrote:To avoid hand editing the RELEASE files each time I have an IOC to build, I've coded a python script that takes a 'recipe' for base/module/IOC containing some meta data, including top package dependencies, and delivers a set of built packages - found while resolving deps at compile time.There is a tool called Sumo (or EPICS-sumo) that was developed for BESSY and published by HZB which automates the process of generating RELEASE files and building dependent modules automatically. It takes a bit of work to get started with it, but it seems to work very well and I am proposing this as the basis for the APS Upgrade's IOC builds. http://epics-sumo.sourceforge.net/index.html There are a number of enhancements that could be added by the community including adding a GUI for easy module configuration changes. - Andrew