Experimental Physics and
Industrial Control System

1. As far as I’ve been able to determine it only works in “Unconnected” communications form.
2. It does not implement most of the published CIP protocol, only those components required to communicate with the Control and Compact Logix families.
3. Because it uses “Unconnected” communications, it’s speed is somewhat lacking.  It will read or write to the PLC’s, but takes ~4-8 ms per transaction, due to the way the communications is performed.  Doesn’t matter how little, or how much data you want (within limits), there is a fixed amount of overhead in the communications, which is –not- related to actually transferring the data.
   

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

 

 

---

From: [email protected]  [mailto:[email protected]] On Behalf Of David  Dudley
Sent: 16 December 2009 14:14
To:  [email protected]
Subject: Re: Remote I/O

 
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
 

References:

RE: Remote I/O nick.rees

Navigate by Date:

Prev: Re: Remote I/O Matthias Clausen

Next: Re: Remote I/O Andreas Balzer

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 nick.rees

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