David,
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:
Re: Remote I/O
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.
<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
--
+-------------------------------------------------------+
| Rolf Keitel, Ph.D. Tel: (604) 222-7453 |
| Division Head, Engineering Fax: (604) 222-7307 |
| TRIUMF |
| Vancouver, B.C., Canada |
+-------------------------------------------------------+
|