Updates on the “Arduino PLC”
Several people have contacted me regarding the “Teensy++ PLC”, either with the idea of extending it, or porting it to other microcontroller architectures, or developing it further as a true “Arduino” solution. Especially the true Arduino PLC solution is very tempting for me. Indeed, that was the idea that followed me from the very start. So, let me put together some thoughts on this topic.
First, how should the PLC be implemented in hardware? How should the I/O, extensions and communications with the outer world be implemented? I believe the PLC would be best realized as a special shield with all the basic PLC and communications logic on it. And then, all the extension circuits could be optionally connected to it.
To connect the I/O modules, some quick ideas come to my mind: The first would be to use the I2C. From what I’ve heard, this works o.k. even to distances of few ten meters, or even more. However, I2C is not noise-resistant (Do we need noise resistance?). Another option would be to use a simplified ethernet to controll the I/O, as described in the following link:
It could be used either as a dedicated link to I/O modules or (not at the same time / the same circuitry) as a way to connect to the outer world (PC, other controllers). Regarding the first case, I’m not sure how noice resistant it would be. And as an outer world connection, perhaps, better, more capable and easier to use ethernet solutions and modules are available.
Of course, to connect to I/O modues, the USB bus could be used. It’s a differential bus, so I guess, it is noice resistant. This would mean that something like what the following link
describes, could be used on the PLC side (i.e., the USB host). And something like, say, a Teensy board (i.e., the USB device) could be used on the extension modules side (I/O boards). I like this idea, since I like the versatility of the USB and possibilities it offers (as I, also, like the idea of reusing the knowledge gained this way in other projects). And the need for extensions lays everywhere. As do various USB devices, nowadays.
But, maybe, the most simple (and probably the right one) solution would be to use some kind of a circuitry to convert the usual I2C signal of the MCU to differential signal on the wire, and back again. If this would be possible and if it would make sense. Perhaps the I2C should indeed be used for this purpose, simply because it’s already there. Almost every chip supports it. This leaves much less to reinvent and much less time, effort and energy to waste.
So, I would propose the idea of an Arduino “PLC shield” with the basic circutry required to support the PLC functionality (i.e., at least a memory latch to read and store the PLC shutdown state before the system turn-off, and, perhaps, a real-time clock), the I/O expandability (either way it is realized) and the communication logic (something like USB, RS232 or ethernet…). This would then be “on the site” combined with different I/O circuits (modules, to connect with the shield) and an Arduino board to form a functional controller.
As far as the programming and standards go… of course, there is the IEC 61131-3. And it specifies five languages to program a PLC. However, the whole standard is designed for present and future devices (more processors and execution loops, event-based execution, etc.) and, taking the Arduino or AVR into consideration, much of it is a clear overhead. But, of course, it would make sense to pick some subset of the language/standard and implement it just enough closely that anyone knowing PLCs would feel at home. The IDE I’ve made for my “PLC” just “mimics” the FBD language of the standard. It was just to show what could be / should be done in the user (programmer) interfacing part. There is much to rewrite, add and improve.
There is the Beremiz project. And it has a full IEC programing environment done. But adapting it for my PLC turned out to be a task too big for me. I don’t feel capable of doing it without investing a lot of energy and effort into learning the stuff of yacc, lexers, parsers… And it simply doesn’t interest me *that* much (anyone else with that ambitions?).
There are, of course, two ways of putting the control code into the PLC. What I did in my PLC is that all the code is first generated at the C++/Arduino source code level, combined with the PLC monitor source, and then together compiled to a .hex file, using the usual way. So all the code in the PLC runs native. It prooved convenient enough, but also other ways are possible. An interpreter could have been written to execute IL language or ST language tokens stored in an external SRAM. I believe the following site describes something similar:
But, as always, the scope of the whole project should have been defined first. How far to go to make it look and behave like a real PLC, but still being able to call it “Arduino”? Perhaps there isn’t much sense to stress the “arduino” word (and stick to the concept) if there, at the end, isn’t much arduinish left in it. And, perhaps, even more important: the final price is also the factor. There is no gain in makingc “a PLC” that costs almost the same as a cheap, say, Siemens LOGO, but performs worse or less reliably, is less expandable and isn’t backed by any certificates, guarantees and support, that commercial PLCs usually are.
That’s it. What I have written above are pretty much my thoughts that I have been discussing with the guy that contacted me. I believe there will soon be a way for everyone interested in to participate. And I will let you know, here on my blog. And will tell you more, of course. But for now, I’m just chewing out my thoughts.