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
>>
>>
>>
>>
>>
>>
>>
>>
- References:
- Re: Remote I/O Pete R. Jemian
- Navigate by Date:
- Prev:
RE: Remote I/O Mark Rivers
- Next:
Re: Remote I/O Stephen Lewis
- 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 Pete R. Jemian
- 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
|