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 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: Remote I/O |
| From: | David Dudley <[email protected]> |
| To: | "[email protected]" <[email protected]> |
| Date: | Wed, 16 Dec 2009 11:11:14 -0500 |
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.
<http://pubweb.bnl.gov/~ddudley/PLC_Selection.ppt>
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.
- Good (...no, make that excellent) support,
- Wide assortment of stable and reliable hardware,
- Ability to easily interact with EPICS,
- Ability to produce and accept configurations and programs in a supported text format,
- 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 - ;-)
David
On 12/16/09 9:00 AM, "Elliott Wolin" <[email protected]> wrote:
Hi,
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.
Sincerely,
Elliott
================================================================================
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
757-269-7365
================================================================================
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.
David
On 12/16/09 7:44 AM, "[email protected]" <mailto:[email protected]> <[email protected]> <mailto:[email protected]>
wrote:
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
http://www.acromag.com/models.cfm?Product_Function_ID=28&Category_ID=22&
Group_ID=2
2. EtherCAT base modules, such as those from Beckhoff:
http://www.beckhoff.com/
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
systems,
Cheers,
Nick Rees
Principal Software Engineer Phone: +44 (0)1235-778430
Diamond Light Source Fax: +44 (0)1235-446713
- Replies:
- Re: Remote I/O Rolf Keitel
- References:
- Re: Remote I/O Elliott Wolin
- Navigate by Date:
- Prev: Re: Remote I/O David Dudley
- Next: RE: Remote I/O Mark Rivers
- 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
- Navigate by Thread:
- Prev: Re: Remote I/O David Dudley
- Next: Re: Remote I/O Rolf Keitel
- 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
·
Home
·
News
·
About
·
Base
·
Modules
·
Extensions
·
Distributions
·
Download
·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·