This project hopes to be able to provide interchangeable PLC interface drivers to projects such as;
For general information, the following PLC types have drivers, but not on this site.
- Allen Bradly PLC's by ABEL (Allen Bradley Ethernet Library)
- Automation Direct, DirectLOGIC(tm) PLC's by
The Linux PLC and DirectNET Project
- Beckhoff BK9000/BC9000 Ethernet couplers, by Visual
- Cegelec ALSPA 80-35 , by Visual
- DMX is the industry standard for controling lighting devices DMX4Linux
- GE Fanuc series 90, appears to be the same as Cegelec ALSPA 80-35.
- K8000 I/O board interface by K8000mct
- K8000 I/O board interface by STANTOR
- Simatic S5 family via programming interface ( AS511 ), by Visual
- TSX17/20 driver by ADEFU
Computer Interface cards ( A/D )
- DAS 1401/12 by RTiC-Lab
Computer Interface cards ( D/A )
- CIO-DDA06 by RTiC-Lab
- PCI-DDA08/12 by RTiC-Lab
- Eye Express (eye)Tracker software
Eye Express(tm) Eye tracker hardware
- JRobot - Tool for Mitsubishi RVM1 robot
- Info on IEC 1131 , a standard for PLC
Links to other relevant sites
- Direct Automation Provide software for their PLC's at no cost, but it is not open source.
This project is still very much in the planing stages, with a final target of two interchangeable interfaces.
The first type of interface will be a "Thin client", which will connect to a serial port on the same machine as the user
program, run in it's own thread and have minimal overheads.
The second interface will be a "NET client", which will use a "PLC server" to connect to other PLC's and / or user
programs on any machine that have network access to each other.
All the PLC's in this diagram could be on the same "effective PLC network", along with PLC emulators
and data loggers or SCADA software.
The Client is a common object that can be added into any user code to provide network connectivity.
It would contain two or more sub objects containing the same functionality.
Using a connection-less message pipe and a stream-socket message pipe.
All that would be necessary to change pipe types is to make a pipe object of the right type.
All internal functions would have the same name regardless of the driver type.
The Server does not need to be on the same computer.
It would accept connections from the clients and echo any messages to all (default) other clients.
A samba style interface which presents a web page would allow the server to be configured from anywhere.
The configuration would consist of telling the server which clients to echo to which other clients.
It may also, ( needs discussion ) configure the serial ports of clients.
Needs discussion, to implement a different server for a different type, or to have different server types,
or an switch in the code to give the option at compile time.
The Serial interface, which is in the same program as a client, does not attempt to change any data, but only acts as a pipe.
The speed, parity etc can be configured by an attachment to another client.
Ie, A PLC programming or SCADA user program could change the serial port settings.
Any user program which used a client such as emulators or PERL modules would be able to use a library
to suit the PLC or other device at another node of the server.
The client and server could be built in both C++ and Java, and there could be
different versions for different operating systems, but able to work together.
In the case of ADEFU, a single program could sniff for a server, start a new
server if one does not exist, start a new client/serial port program for the interface and then run the user interface.
This may seem a bit complex at first, but hopefully people can see the advantages in a modular system.
I have no code to offer at this point, and it looks like this will end up an unfinished project.
If people could design their code so that it is able to be modified to suit this concept, it would be nice.
All trademarks are the property of their owners.
This Site is Hosted by SourceForge
Feel free to
e-mail Andrew Laughton
if you have any ideas on how to make this project better.