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]> |
| Date: | Wed, 16 Dec 2009 09:14:29 -0500 |
There are a number of items (OK, a massive number of items) where you don’t need PLC control, you simply need to read or write data directly into EPICS. We want to eliminate a PLC where we don’t have any remote processing required, and use the remote I/O modules directly for that function.
For instance, I have ~1500 Thermocouples that I need to acquire temperatures from. I don’t need to do any processing on those, just get them into EPICS. I want to use a Point I/O or ArmorPoint system to directly acquire data from the TC into EPICS.
If we need PLC processing, of course, the I/O would go to that, but why program a PLC to “...stay out of the way...” just to acquire some data?
A-B says if I produce a driver that will do CIP using “Connected” format, they’ll provide the info to be able to program and initialize the modules directly.
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 nick.rees
- References:
- Re: Remote I/O Elliott Wolin
- Navigate by Date:
- Prev: Re: Remote I/O Elliott Wolin
- Next: Re: Remote I/O Ralph Lange
- 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 Elliott Wolin
- Next: RE: Remote I/O nick.rees
- 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 ·