I'd like to use a Pi as a PLC. I find a lot of developer boards, but didn't find a lot of industrial I/O besides the well known expensive solutions from the big names. The modules should be mounted to DIN rail und wired through RS485 (preferably MODBUS, because it is an open protocol). I'm looking for something like 16 inputs and 16 outputs (relays, 2A inductive load). About 8 to 10 of the inputs should be analog for measuring temperatures with NTC thermistors. Any other bus is acceptable, the distance from the Pi is
I did something like this using Atmega 328 for the remotes (programmed in an Arduino then popped out and boarded with just a resonator and stuff.
By using some basic matrix, latch and opto chips I had 32 robust isolated digital inputs, and 16 isolated 500mA outputs (I used them to drive independent relays - essential if you've got mains stuff to control). I also used 3 of the analog inputs directly via R/C filters with diode limiters.
I bunged an RS 485 chip on this and used my own very simple (but error checked) protocol and ran at 38400 baud with 10 remote modules with a netwo rk length of about 80 metres. That was going into an ordinary 'pooter.
From experience you nearly always want twice as many inputs as outputs.
I also want to control mains stuff, optical isolation is a must. The best I could find are JeeNodes (4 analog in, 4 digital out), but still a lot to tinker. I hoped for something ready made in a case. Did you open source this project btw?
If you are serious about this I would be very interested in working with you. I am an engineer and can provide the hardware you are looking for. I would need support with the software to make it all usable. Can you send me an email? gnuarm dot 2007 at arius dot com
The original idea was a home project to try out ways of getting more IO on the Arduino, and after I'd proved it worked, the people who give me money every month took an interest in it, and a final version was/is in use in a factory, so I probably can't give away any information about that.
However...
I later came up with a different idea that (although I do say so myself) is dramatically better. The method makes heavy use of shift registers and the overall response time is approximately 2mS - quite good enough for most purposes. If the debounce algorithm was abandoned (never was sure that was working correctly) I would expect less that 1mS to be achievable. You would of course have to add on network time.
You can have up to 128 isolated digital inputs (in groups of 8), and 64 isolated digital outputs (also in groups of 8), as well as the 5 analog inputs and 2 isolated PWM analog outputs on each of the remotes.
I know all the individual bits work, but the whole thing has never been built/tested. However, I went as far as using RS Design Spark to produce PCB images. Quite small cards are to be stacked for what is wanted, and the processor card can be populated for RS232 or RS485 comms.
I don't know if anyone is interested in this, I suppose I could GPL the software. Dunno how to open the hardware side. CC maybe?
I think you've answered your own question - maybe unaware though :)
You want a DIN rail mounting relay controllable via rs485... Put that into Google and up pops:
formatting link
and I'm sure I can find sensors, inputs, etc. in the same way.
As for expense - that one is ?64, but when it comes to this kit, yes, it is expensive - mostly due to the testing and certification it goes through. You don't want (e.g.) a large buildings heating & ventilcation systems which are expected to run for 20 years running on a $5 component, so people expect the expense in return for the reliability (hopefully!)
So the hardware is there - the trickier part is "industrialising" the Pi - and providing it with the rs485 interface - neither of which are insurmoutnable!
Looking at that board again - it has far too much on it - control via Ethernet, USB or rs485! (And only ?64!)
If you want cheaper and can DIY - You can get DIN mount "blanks" and put your own circuit on it - an ATmega with rs485 control, controling e.g. 8 relays is not hard to make, and you could arrange it so that the ATmega & rs485 side of it was common to all boards you make then you just have a work area for relays, inputs, sensors and so on. Make another module with the Pi Compute Module and sell it and make your million ;-)
then what I suggest is to use the limited GPIO of the Raspberry Pi to emulate an I/O bus of the old style, perhaps similar to that of the PDP-8.
8 R/Wdata lines
1 "interrupt" line ... and the rest for I/O addressing and control ...
Address select R/W Action pulse (to initiate the read or write)
This would give the capability of 256 programmed addresses and would lead to a plug-in rack for different I/O cards
Although interesting, this has a very low I/O count and very poor I/O ratio for the network overhead.
Also the relays are soldered to the board. I *always* use plug-in relays for any significant power control. The contacts will eventually burn, and havin g to rip an entire module out (and probably unwire) then have to remove and replace a soldered relay - especially on site - is time consuming and error-prone.
Been there, done that... so many times I could sell the damn T shirts!
Using a Pi as a PLC does not seem like too sound an idea if you are planning to control equipment that could cause harm. Controlling such equipment over a serial communications bus requires a great deal more thought applied.
If this is for a commercial application why would you not consider some of the PLC vendors options. In overall project terms this can be a least cost solution when you factor in the time to consider how you ensure your system will remain safe.
The other issue then is how suitable is the Linux version to control applications. It may be good at the HMI end where nothing of real consequence may occur (in a well designed system). Being the main decider in control would not seem like a suitable role.
--
********************************************************************
Paul E. Bennett IEng MIET.....
Forth based HIDECS Consultancy.............
Mob: +44 (0)7811-639972
Tel: +44 (0)1235-510979
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************
I wouldn't. It doesn't operate like a PLC for a start. There's no check of clock failure. There's no independent watchdog timer. Outputs aren't status checked. You can't just write all this stuff in software. It might work, but what if the processor freezes? What happens to the I/O?
You might manage a PLC simulator, but it won't be a PLC. It wouldn't be accepted as a PLC for industrial use. Still, it's a fun project. :)
None of these are actually insurmountable problems, and also make an interesting learning exercise into fault tolerance. Besides, I've known 'proper' PLCs have invalid outputs *and* freeze!
I wouldn't advise anyone to design for safety systems - you'd never get certification and the insurance would be impossible! For everything else, you should design for the 'no power' situation to be the least damaging/expensive.
The most reliable watchdog you can have is in fact incredibly simple. You set an output toggling at around 200Hz, feed it into a 1:1 audio transformer via a DC blocking cap, and take the transformer output to the coil of a safety relay that powers everything except the main controller (whatever that happens to be). No toggle = no AC = no coil power = everything off
Industrial guillotines have used this in their safety circuits for decades. In this case no power means motor off, clutch disengaged, brake held on by a seriously strong spring, and clamps held off by similar springs.
... and if you've got this far :) Many moons ago, when we'd finished our final exams at school, there was a handful of lesson 'spaces' before we left for good. Our physics teacher gave as a brilliant 2hr brainstorming session - design a fault tolerant doorbell, which would also give some form of warning if it was unable to operate.
No, you can't do this in software without some sort of hardware support, but that can be added to the I/O board. The I/O board can provide a watchdog timer and verify the clock is running.
You have to be careful how this is done. I was in a discussion on using a similar design once and the software guy wanted to have the toggling bit controlled by a timer based interrupt. Unfortunately that would mean the rest of the software could be off in the weeds and the interrupt could still be toggling away so that the watchdog never triggered a reset. :(
We suggested the toggling be done in the main control loop. Even then there could be a problem where some flag got messed up preventing the control loop from handling any of the work it was supposed to do while still handling the watchdog strobe. It can be very, very hard to make sure the software is doing what it is supposed to do.
Such a fail-safe scheme was proposed several years ago, and involved the use of extra I/O pins to induce an excessive current to blow fuses ...
Each CPU compares its outputs to the other two, and if two disagree with the third, then each of the two can induce half the excess current needed to blow the fuse in the third.
However, if a CPU finds itself to be in disagreement with the other two, then it has a suicide mode to blow its own fuse.
The proposal did not indicate what would happen if all three came up with different answers :-)
What was crucial to the success of the scheme was that there would be 3 different software teams working on the code for the three CPUS, with no communication between the teams, but what seemed wrong from the point of view of a safety-critical system was that if the specifications were sufficiently tight, then they'd all produce substantially the same code!
I'd have thought it might be better to reset the errant processor rather than remove it from the group - only disable it if it produces another error condition within a certain time. Of course that's assuming that it can pick up where it left off, and doesn't need a huge amount of initialising before it can continue with useful work.
Make them use different development environments, including OS?
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.