Experimental Physics and
Industrial Control System

David Dudley <[email protected]> · Wed, 16 Dec 2009 12:25:38 -0500

In my previous jobs, I had used Koyo and AutomationDirect equipment
extensively, and like it quite a bit.

Unfortunately, here we were looking for a minimum of a SIL-1 rating on
almost all of the equipment, which I understood at the time, that the
AutomationDirect hardware had not received.

It was also desired that we only select/support 1 or 2 equipment vendors,
and there were requirements for SIL-2 and SIL-3 equipment, which was not
available from AutomationDirect.  That also knocked Yokagawa out of the
running, although I understand we could have worked on getting separate
approval for.

David

On 12/16/09 12:03 PM, "Pete R. Jemian" <[email protected]> wrote:

> 
> Nick:
> 
> Like Mark, my experience with the Koyo PLCs is that they are reliable and
> low-cost.
> They were exceptional for an entry-level system as there was very good
> documentation
> supplied before and after purchase and good support from the distributor.
> Also, the high uptime of this simple systems is much appreciated by beam line
> staff.
> (For example, their output bits don't have to toggle when an IOC is rebooted.)
> 
> Several of our APS beam lines use the Koyo PLCs, mostly for implementation of
> equipment protection systems.  Mark's EPICS support for Modbus/TCP
> communications
> with the Koyo PLCs has been valuable.
> 
> The Koyo PLCs will fail the NSLS2 requirement for
>> 4. Ability to produce and accept configurations and programs in a supported
>> text format
> 
> This is of minor concern if you are not interested in running user code on the
> PLC.
> But, for example, reading of ADC channels on the Koyo can be enhanced
> significantly
> by running user code on the PLC.
> 
> The field experience with the Koyo PLCs (and this is likely common to other
> vendors)
> is high reliability and easy field maintenance.
> 
> As APS has learned with our EPICS brick project, the Linux IOC may have
> a cost advantage over the VME-based IOC if one can reduce or eliminate
> any custom hardware that runs in the Linux IOC.  Otherwise, the cost
> savings is lost in field maintenance and the rapid obsolescence cycle of
> the Linux platform hardware.
> 
> Regards,
>     Pete
> 
> 
> 
> 
> Mark Rivers wrote:
>> Nick,
>>  
>> On a relatively small scale I've been pleased with the Modbus/TCP interface
>> to Koyo PLCs from Automation Direct. These PLCs allow direct communication
>> with the I/O points through Modbus.  Some other manufacturers only allow
>> Modbus access to memory registers, which the PLC program must read/write with
>> the I/O point value.  There is a scanner running, but the Koyo PLCs are very
>> inexpensive so cost is really not much of an issue.
>>  
>> Mark
>>  
>> 
>> ________________________________
>> 
>> From: [email protected] on behalf of [email protected]
>> Sent: Wed 12/16/2009 6:44 AM
>> To: [email protected]
>> Subject: Remote I/O
>> 
>> 
>> 
>> 
>> 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
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System