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

Subject: RE: Remote I/O
From: "Mark Rivers" <[email protected]>
To: "Rolf Keitel" <[email protected]>, "David Dudley" <[email protected]>
Cc: [email protected]
Date: Wed, 16 Dec 2009 11:21:25 -0600
I am pretty sure the Australian Synchrotron uses the XML files with the Schneiders, so they can keep the source code in a conventional code management system.


From: [email protected] on behalf of Rolf Keitel
Sent: Wed 12/16/2009 11:07 AM
To: David Dudley
Cc: [email protected]
Subject: Re: Remote I/O


Any reason why you excluded Schneider from your evaluation? If I'm not mistaken, their Unity programming software (which we don't use for historical reasons) uses XML files.

- rolf -

David Dudley wrote: 

	One more time.
	Link didn't get converted to web link.
	So nice to be working for Bob Dalesio.. ;-)
	Bob suggested I post the PLC evaluation I developed.
	We evaluated 4 PLC families for use here.
	They were: Allen-Bradley, Siemens, General Electric FANUC, and Yokagawa FA-M3.
	Our requirements were pretty simple.

	1.	Good (...no, make that excellent) support, 
	2.	Wide assortment of stable and reliable hardware, 
	3.	Ability to easily interact with EPICS, 
	4.	Ability to produce and accept configurations and programs in a supported text format, 
	5.	General capability of the product and the required programming package.

	I spent 3 months with various hardware and vendors working on this evaluation.  The results were pretty apparent.
	One of our big requirements (and the one that drove most of the evaluation), was the ability to accept and produce files in a format that could be handled by outside software.
	Our system configuration is planned to be entirely contained with an advanced version of IRMIS.
	The plan is that IRMIS will contain all the information on I/O definition, configuration, hardware involved, locations, wiring, etc...  Everything we need to configure and program a PLC in the system will be driven by IRMIS.  We want to be able to export a file of some format directly from IRMIS, and using some simple technique (just a translator program is planned for right now), load that configuration directly into the PLC programming software.
	When we got to that requirement, currently only Allen-Bradley and Siemens can accept text format files.  However, even at that, the -implementation- of the feature was very different.  While A-B took the position of producing or accepting a XML format file as a standard option (and publishing the propagating the documentation on the layout of the XML file), Siemens produces and accepts a specialized text format that is tied to the Step7 programming software (and there is no guarantee that the format won't change with the next revision of the software).
	On that point, GE said (I could never get any "useful" support from GE) they could accept and produce an excel formatted spreadsheet for I/O definitions only.  No comprehensive text form existed.  Support from GE was so lacking (which I did not expect.  GE support in other areas of the country is outstanding) that it was basically minimalized in the evaluation.
	Yokagawa also stated that their ladder software could handle I/O definition spreadsheets as well, but the software was somewhat lacking in other areas (could have just been my lack of familiarity with the software).  It was very time consuming to get answers to items about the Yokagawa system, although from a design perspective, the hardware itself was outstanding.
	When the evaluation was complete, there was no immediate "clear" winner, as a relative tie between A-B and Yokagawa was the outcome.  Yokagawa was clearly a superior hardware platform, and had the edge on cost as well, but A-B had definite advantages in software support and product depth.
	We chose A-B on the basis of support and software capability.  The Lab gets such massive proce breaks on A-B equipment (I'm not allowed to say more than that... ;-) that price wasn't a big deciding factor, but the support and capability of the A-B equipment so far has been outstanding.
	Should also mention that recently, the Yokagawa equipment representative was here discussing the future of the FA-M3 product, and what developments needed to be done to make the product a more competitive product.  My understanding is that in the future, they intend on providing the capabilities we outlined were important, and will be working to provide some kind of text file format.
	Too late for this project, but maybe in the future....
	I tend to write really long emails  - ;-)
	On 12/16/09 9:00 AM, "Elliott Wolin" <[email protected]> wrote:

		For the Hall D experiment at JLab we too are planning to us Allen-Bradley PLC's and Point I/O systems connected via Ethernet/IP (and ControlNet for some applications).  We don't go online for a few years so we are just beginning to plan, and we have only purchased a small amount of PLC and Point I/O equipment for early hardware testing.  We likely will go with the Java IOC as well and have a Java-only control system.
		Our plan is that all control loops will reside in PLC's or other manufacturer-supplied hardware, and just use EPICS for  supervisory operations and display. 
		 Those raised in a morally relative or neutral environment will hold
		      no truths to be self-evident.
		Elliott Wolin
		Staff Physicist, Jefferson Lab
		12000 Jefferson Ave
		Suite 8 MS 12A1
		Newport News, VA 23606
		David Dudley wrote: 

			I am currently in the process of researching the exact same thing.  We're
			using Allen Bradley PLC's in the new NSLS-2 control architecture, and I'm
			currently working on extending the Ethernet/IP driver to connect directly to
			the various Point I/O, Flex I/O and ArmorPoint I/O modules.
			The ArmorPoint and ArmorBlock modules seem to be the most useful of the I/O
			blocks I'm researching, as they have integrated Ethernet/IP interfaces (some
			with an integrated 2 and 3 port switch), can provide various levels of I/O,
			and are ruggedized to the degree we can easily install them on the
			experimental floor.
			On 12/16/09 7:44 AM, "[email protected]" <mailto:[email protected]>  <[email protected]> <mailto:[email protected]> 

				At Diamond we are considering what to use for the next generation of
				discrete I/O. Currently we have a lot of VME based hardware, but we are
				considering a good architecture for a Linux world.
				The model that we are considering is a soft IOC on a Linux system
				communicating over Ethernet using an open, industry standard protocol to
				distributed DIN-Rail mounted I/O points. These I/O points take in
				Ethernet and are powered from a 24V bus that will run around the
				hardware area.
				This eliminates any dependence on a specialized bus architecture (apart
				from Ethernet) on the Linux system, so they can be commodity PC's, and
				hopefully allows us to use widely available, cheap, industrial modules
				for I/O. It will not completely replace all of the requirements
				currently serviced by VME, but would be able to satisfy most of them,
				with the remaining few being serviced by the occasional VME system (or
				FPGA, or some other bus, or something else entirely in the future...).
				This email is to poll the EPICS community as to the experience people
				have had, and recommendations for and against.
				The sort of thing we have identified are:
				 1. Modbus/TCP based modules, such as the Acromag Busworks series
				 2. EtherCAT base modules, such as those from Beckhoff:
				 3. Standard PLC systems where (as distinct from the other two), you
				take Ethernet to a PLC controller which then has a series of modules it
				talks to in a variety of possible ways.
				So, is anyone willing to share their experiences with these or similar
				Nick Rees
				Principal Software Engineer           Phone: +44 (0)1235-778430
				Diamond Light Source                  Fax:   +44 (0)1235-446713



| Rolf Keitel, Ph.D.                Tel: (604) 222-7453 |
| Division Head, Engineering        Fax: (604) 222-7307 |
| TRIUMF                                                |
| Vancouver, B.C., Canada                               |

RE: Remote I/O Richard Farnsworth
RE: Remote I/O Andrew C. Starritt
Re: Remote I/O David Dudley
Re: Remote I/O Rolf Keitel

Navigate by Date:
Prev: Re: Remote I/O Rolf Keitel
Next: Re: Remote I/O David Dudley
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  <20092010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022 
Navigate by Thread:
Prev: Re: Remote I/O Rolf Keitel
Next: RE: Remote I/O Richard Farnsworth
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  <20092010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022 
ANJ, 31 Jan 2014 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·