EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  <19951996  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  <19951996  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: Medm and XRT/Graph
From: [email protected] (Bill McDowell)
To: [email protected]
Cc: [email protected]
Date: Wed, 18 Oct 1995 15:25:27 -0500
> 
> From: Andy Foster <[email protected]>
> Date: Fri, 13 Oct 1995 21:38:34  
 
> I've been looking at "medm" recently. It seems to me that there is only 1
> widget which requires the XRTgraph widgetset. This is the X-Y graph widget.
> Was there any particular reason why this could not
> have been written in Motif?
> 
> XRTgraph is pretty expensive at $3000 - $6000
> (depending on educational discounts) for some projects (Gemini).
> 
> Andy



This has been asked and answered before (attached). All we need is
someone to volunteer the three months which will probably be required
to add the widget. I don't have the resources to assign someone to this
task.


Bill

==============================================================

From: Mark D. Anderson <[email protected]>
Date: Thu, 8 Sep 94 11:50:55 CDT
Subject: RE: EPICS dependency
Message-Id: <[email protected]>

RE: "I suggest that tools which are intended to be an intrisic part of EPICS
.. not be dependent on third party software" -

This is an issue that is not so easily handled or dismissed.  It is a valid
goal to have EPICS be portable, and attempts are being made to do that,
even in the selection of 3rd party software.  (I won't belabor the
tie to VxWorks here, but this discussion certainly could include that
topic as well!)

For most software development for projects with finite resources and
time constraints (and that covers every project these days), the fundamental
parameters being optimized in general are cost, and time to deployment,
with attention being paid to portability.

Deciding to spend $2K on a 3rd party software package or spending 6 man-months
to multiple man-years of development effort is usually not a hard decision
to make.  In the selection of the two packages in question (XRT/Graph
and QuestWindows), portability, platform availability, cost, run-time costs,
et cetera, were all considered prior to adoption.  Both packages scored
high on these metrics, were stable, and cost-effective solutions to
problems being addressed.

Noting especially that both packages have no run-time fees for binaries
generated (cost is on development, not deployment), I frequently wonder
why everyone insists on building all their own EPICS tools anyway.
Apart from Motif licensing (run-time licensing) which is currently included
gratis in all systems in use save for SUN, there would be no encumbrances
to a binary distribution model for EPICS...

When that mechanism fails, there is still recourse for those who don't
want to purchase a product for builds/development: offer equivalent
functionality (and possibly APIs) to the package in question, then either
link against the replacement package, or lobby for compile-time
modifications to the software to accomodate a new package where
possible.  For example, MEDM could simply have the Cartesian Plots turned
off, and XRT/Graph would not be necessary.  Or someone could write a
graph widget, possibly following the XRT/Graph APIs...  But I'd be willing
to bet money that no one raises their hand for that, unless they've got a
bundle of money and programmers that they are keeping a big secret.

Please understand that I am not belittling your comment in any way, I am
merely pointing out the economic and pragmatic factors which influence such
decisions.  As we move from a project-centric development model (with APS
being the dominant project which has offered its develoment efforts to the
collaboration) to a collaboration-centric development model, such development
decisions as 3rd party software packages will need to be discussed at the
collaboration level.

        - Mark Anderson

----------------------------------------------------------------------------

From: Mark D. Anderson <[email protected]>
Date: Thu, 8 Sep 94 11:50:55 CDT
Subject: RE: EPICS dependency
Message-Id: <[email protected]>

RE: "I suggest that tools which are intended to be an intrisic part of EPICS
.. not be dependent on third party software" -

This is an issue that is not so easily handled or dismissed.  It is a valid
goal to have EPICS be portable, and attempts are being made to do that,
even in the selection of 3rd party software.  (I won't belabor the
tie to VxWorks here, but this discussion certainly could include that
topic as well!)

For most software development for projects with finite resources and
time constraints (and that covers every project these days), the fundamental
parameters being optimized in general are cost, and time to deployment,
with attention being paid to portability.

Deciding to spend $2K on a 3rd party software package or spending 6 man-months
to multiple man-years of development effort is usually not a hard decision
to make.  In the selection of the two packages in question (XRT/Graph
and QuestWindows), portability, platform availability, cost, run-time costs,
et cetera, were all considered prior to adoption.  Both packages scored
high on these metrics, were stable, and cost-effective solutions to
problems being addressed.

Noting especially that both packages have no run-time fees for binaries
generated (cost is on development, not deployment), I frequently wonder
why everyone insists on building all their own EPICS tools anyway.
Apart from Motif licensing (run-time licensing) which is currently included
gratis in all systems in use save for SUN, there would be no encumbrances
to a binary distribution model for EPICS...

When that mechanism fails, there is still recourse for those who don't
want to purchase a product for builds/development: offer equivalent
functionality (and possibly APIs) to the package in question, then either
link against the replacement package, or lobby for compile-time
modifications to the software to accomodate a new package where
possible.  For example, MEDM could simply have the Cartesian Plots turned
off, and XRT/Graph would not be necessary.  Or someone could write a
graph widget, possibly following the XRT/Graph APIs...  But I'd be willing
to bet money that no one raises their hand for that, unless they've got a
bundle of money and programmers that they are keeping a big secret.

Please understand that I am not belittling your comment in any way, I am
merely pointing out the economic and pragmatic factors which influence such
decisions.  As we move from a project-centric development model (with APS
being the dominant project which has offered its develoment efforts to the
collaboration) to a collaboration-centric development model, such development
decisions as 3rd party software packages will need to be discussed at the
collaboration level.

        - Mark Anderson

----------------------------------------------------------------------------


----- End Included Message -----


Navigate by Date:
Prev: [no subject] Gary P. Carr
Next: Xlib Errors with tcl7.4/tk4.0 and blt_barchart. Gary P. Carr
Index: 1994  <19951996  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 
Navigate by Thread:
Prev: [no subject] Gary P. Carr
Next: Re: Medm and XRT/Graph Marty Kraimer
Index: 1994  <19951996  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 
ANJ, 10 Aug 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·