Title: Re: Remote I/O
David,
Are you saying you have an open source implementation of Ethernet/IP
running on Linux? If so, I missed it and it clearly adds the Allen
Bradley modules to our list of possibilities. How robust is it? If it isn't
open source, who is supplying it?
Talking directly from the IOC to the I/O is our simplistic preferred
solution.
The reason for this is
-
cost
(you don't need a PLC scanner if a specific system has only a few I/O
points)
-
reduced
latency (you don't have a PLC scanner in the way).
-
flexibility (you don't have to configure a PLC, you can just plug
straight in to the network).
However, none of these are particularly strong reasons, hence the third
choice of a PLC scanning system. I would have thought if you have 1500 temperature sensors it
might be sensible to have a PLC scanner anyway, and so you can just read all
1500 temperatures into the IOC in one hit, not
individually.
Cheers,
Nick Rees Principal Software
Engineer Phone: +44
(0)1235-778430 Diamond Light
Source
Fax: +44 (0)1235-446713
At NSLS-2 we want to take that one step
further.
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
--
This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail. Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd. Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message. Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom
- Replies:
- Re: Remote I/O David Dudley
- References:
- Re: Remote I/O Elliott Wolin
- Re: Remote I/O David Dudley
- Navigate by Date:
- Prev:
Re: Remote I/O Ralph Lange
- 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
- Navigate by Thread:
- Prev:
Re: Remote I/O David Dudley
- Next:
Re: Remote I/O David Dudley
- 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
|