I've noticed several people mentioning real time linux. Are proprietary
real time builds widely used, or is standard free linux with real time
patches generally used?
Are there hardware platforms that are more suitable for RT linux?
(specific CPUs or chipsets?)
[mailto:email@example.com] On Behalf Of Richard Farnsworth
Sent: 17 December 2009 00:34
To: Rees, Nick (DLSLtd,RAL,DIA)
Subject: RE: Remote I/O
At the Australian synchrotron, we use Ethernet as a field bus also.
Ethernet is not deterministic in theory , but with clever networking you
can get around most of the issues in practice. We separate the
accelerator networks from the beamlines (and other places). We use
gateways if we need data transfer.
Our primary PLC's use Modicon premium PLCs (Schneider) and a Modbus/IP
driver (Not Mark Rivers one though, although it may have a common
ancestor). Also our PILZ safety system PLC's, and a number of other
systems use Modbus. We do have some other Ethernet drivers for a few
variant PLC's (Siemens and Rockwell and our building systems).
One problem we are getting into is that the keep alive chatter
(Broadcast) on the PLC's is starting to impact network performance and
we may look at separate networks (And second network cards) on certain
PLC's in the future.
Our IOC's talk via Moxa's terminal servers to serial devices, RS232
primarily, but also RS422 and RS485. We also have a number of Cosylab
supplied PC/104 soft IOC's with RS485 daughter cards.
Almost no VME, most analog and digital I/O is performed using PCI I/O
cards on a mixture of Soft IOC's and some running Redhawk real time
Linux. We will be removing them in the near future and just using
Temperature measurements are done in part using a tiny (cheap) Modbus
device called an "ITM". More details if you need that. We recently
replaced most of them as they (ironically) got too hot wher we mounted
them and they failed.
VME (as a power supply/crate) is only in use on the timing system and
one or two special devices. We use Linux IOC's and a Struck VME to PCI
bridge for the odd VME only case.
I'd like to say no VxWorks, but I've discovered recently that the
Modicon premiums actually use VxWorks internally.
A strong emphasis on Linux throughout, the major exceptions being our
PLC development tools and the Dipole power supply uses (Ahhchoo, Spit,
Ting) Windows CE. Even our GUI's use wine on Linux to run the windows
executables we develop with Borland Delphi (We will change to QT over
Richard Farnsworth | Head of Computing | Australian Synchrotron
p: (03) 8540 4118 | f: (03) 8540 4200 | m: 0421 082 147
firstname.lastname@example.org | www.synchrotron.org.au 800
Blackburn Road, Clayton, Victoria 3168
<br>This message and any attachments may contain proprietary or
confidential information. If you are not the intended recipient or you
received the message in error, you must not use, copy or distribute the
message. Please notify the sender immediately and destroy the original
message. Thank you.
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
- Re: Remote I/O & RT linux David Kline
- Remote I/O nick.rees
- Re: Remote I/O Dave Reid
- RE: Remote I/O Richard Farnsworth
- Navigate by Date:
Re: Remote I/O Paul Hamadyk
RE: Remote I/O Dalesio, Leo
- Navigate by Thread:
RE: Remote I/O Richard Farnsworth
Re: Remote I/O & RT linux David Kline