EPICS Home

Experimental Physics and Industrial Control System


 
1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019 
<== Date ==> <== Thread ==>

Subject: Re: Porting EPICS to NetBSD
From: "David Dudley" <DavidDu@cctexas.com>
To: <tech-talk@aps.anl.gov>
Date: Wed, 16 Aug 2006 13:43:27 -0500
Yes, I did.  helped a great deal.  Gave me a lot of reinforcement for the new ideas and directions that I've been trying to push Corpus Water in for the past three years.  Problem is, most if not all of our design and development is done by outside consultants (legal liability issues and such.... I hate lawyers!).  Most consulting engineers around here couldn't design a state of the art control system around here if they were plugged into the wall!  Changing the mind set of the people in administration around here has been a long ongoing process.  Every little bit of information that I've been able to find, I've force fed them until they can recite it from memory.  I'll get them moving yet.

David Dudley

>>> Ned Arnold <nda@aps.anl.gov> 08/16/06 1:23 PM >>>
David,

I assume you found these ???

http://www.aps.anl.gov/epics/docs/GSWE.php 


Ned Arnold
Argonne National Lab


David Dudley wrote:
> I figure the EPICS system is going to have much faster response time in the final analysis.
> 
> I've already written a number of modules for my PLCs that give them special functions other than the original control they were doing.  Things like data loggers, radio network routers, network "sniffer's", and a number of special filtering and control functions that were not originally defined.  Making them IOC's I don't see as a problem.
> 
> I'm planning on clustering them directly with a more localized EPIC database unit in the area, and then linking that directly to the control center here.  That should give me the capability of local intelligent control, in the case of communications failure to the control room (happens frequently around here).
> We cover a geographic area here about 75 miles east to west, by 150 miles north to south.  That makes reliable remote communications problematic at times, even though the functions that need to be controlled may be localized, and the control strategy implemented may be such that it is all localized.
> Our other truly major problem is with "historical data".  Just the phrase can send shivers up the spine of the administration around here.  Texas Commission on Environmental Quality (TCEQ) is the regulating agency here, and their requirements for record keeping are pretty comprehensive.  I have historical data (ya me!) for each and every site in 1 minute increments going back 5 years (for us, that's around 45Gig of historical data).  However, getting it and keeping it from some of the remote sites is pretty brutal, and I want to start distributing the load to geographically more localized sites.
> 
> Also, PLC programming (ladder programming) is something very few programmers around here can do.  If I can move most of the operational stuff to more traditional languages (like C, C++, Java, Python, etc...), I should be able to get more staff in the City available to assist me in performing things.  I mean, if you tell someone "Look, when this variable becomes this value, wait this long and then do this), and they can do it using something they know how to do instead of Ladder Logic, it makes it a lot easier from a support standpoint.  Toward that end, I'm hoping to be able to incorporate the Sequencer software into the remote systems.
> 
> No matter what, I'm pretty sure I have job security......
> 
> David
> 
>>>> Emmanuel Mayssat <emmanuel_mayssat@lynceantech.com> 08/16/06 12:46 PM >>>
> 
> You can have 2 control systems.
> One with fast response time and PLC based.
> The other one with EPICS (and PLCs reporting their status to EPICS). 
> Ofentimes, skills to build both of those control systems are different.
> 
> Instead of converting your hardware in IOCs, you may want to just had an
> IOC (computer + EPICS) that can interface with it. This allow for smooth
> transition. There are several PCI MODBUS cards available on the market.
> 
> In any case, it seems you have a lot of programming to do but that is no
> different from what we are all am doing ;-)
> 
> --
> Emmanuel
> 
> EPICS can work and all the equipment you need to connect.
> 
> On Wed, 2006-08-16 at 10:11 -0500, David Dudley wrote:
>> into some of our PLC equipment in order to convert them into IOC's themselves.
> 
> 
> 
> 
> 
> ------------------------------------------------------------------------
> 
> BEGIN:VCARD
> VERSION:2.1
> X-GWTYPE:USER
> FN:David Dudley
> TEL;WORK:880-3740
> ORG:;MIS
> TEL;PREF;FAX:880-3741
> EMAIL;WORK;PREF;NGW:DavidDu@cctexas.com 
> N:Dudley;David
> END:VCARD
> 


BEGIN:VCARD
VERSION:2.1
X-GWTYPE:USER
FN:David Dudley
TEL;WORK:880-3740
ORG:;MIS
TEL;PREF;FAX:880-3741
EMAIL;WORK;PREF;NGW:DavidDu@cctexas.com
N:Dudley;David
END:VCARD


Navigate by Date:
Prev: Re: Porting EPICS to NetBSD Eric Norum
Next: looking for OSI version of epid record Dayle Kotturi
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019 
Navigate by Thread:
Prev: Re: Porting EPICS to NetBSD David Dudley
Next: looking for OSI version of epid record Dayle Kotturi
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019