Open source PLC hardware

The AVR board looks like it would do the job for a Modbus/TCP interface, provided it works with the I/O rack (I'm assuming you've already looked into that). The web server would also be useful for configuring the rack and for troubleshooting and commissioning I/O. SSH/SCP and/or FTP could be used to upload new software ("firmware upgrades"). All of those "extra" features are actually quite important to make a system usable.
 
C
What i find really interesting is the low threshold to being in the embedded Linux game. Even though I don't have the $90 at the moment, that's cheaper than most of the "Low Cost" alternatives that I might otherwise use. I did download the AVR32studio software to take a look, since the price was right, but it's java on eclipse and wants Windows type resources to run and didn't like my Fedora 10 setup. They did say they wanted RHE or Fed 9 or .........

But, I wasn't that impressed by what I saw anyways. I think I'll grab the toolchain and c library to look over. VI and make are fine by me. They do mention that they pin out 1 SPI port but I haven't discovered any SPI driver work or threads to encourage a longer look. It does seem that there will be a "beagleboard class" of SBCs to choose from. From what I can tell, it might be cheaper to write to Linux than to compile to the machine language. Of course, I'm not interested in doing that for anything large anyway, but I was amazed that these powerful SBCs are $100 and many "deeply embedded" class boards cost many times more plus big bux for the emulators, etc. etc, to actually use them. But there is a growing trend to provide tools free to sell chips. I wonder where that came from:^) I even saw one piercing flash of brilliance, simply dazzling. Someone had a link to a live, boot CD with the whole hosting and cross compiling setup installed on Linux and ready to go. Unfortunately the link was broken, sigh....

Regards
cww
 
There are several different Creative Commons licenses. For all of them however, I don't think there would be any obligation for someone to distribute the documentation if they distributed the hardware. That makes it more like a BSD type license rather than a GPL type license. Whether that is what you want, is of course up to you.

If you are going to release the docs, then a CC type license is far from the worst. Just make sure that you include a warranty disclaimer (as with GPL).
 
With regards to compilers: gcc-avr is in the Ubuntu (and therefore I imagine Debian) repositories - I could install it with two mouse clicks right now. I would assume that it's in Fedora as well. I would be very surprised if what's in the repositories is any different from the packages on Atmel's web site (although they may have some library bug fixes).

According to Atmel's web site, it includes:
http://www.atmel.com/dyn/products/tools_card.asp?tool_id=4118

* Runs on Microsoft Windows and Linux platforms
* Cross compiler for AVR32 devices
* Assembler and linker for AVR32 devices
* Debugger for AVR32 devices
* Flash programming tools for AVR32 devices
* C-libraries for development of C/C++ programs

As for Fedora 10, that's kind of old, but they do have updated RPMs for it. They list packages for multiple versions of Fedora, Red Hat Enterprise, Suse, and Ubuntu (and MS Windows as well).

I wouldn't bother with Eclipse. If you are going to re-distribute source code then I imagine the recipients would much rather have a make file than some sort of Eclipse configuration that may or may not work with whatever version of Eclipse they have installed.

For this sort of project developing on and targeting anything other than Linux is not very practical. You really want to develop on your PC and debug it there and then port it to the target board once you have all the logic errors fixed so you only have to deal with the platform specific issues at that poin. I think that AVR recognizes this which is why they (and other embedded OEMs) are doing things this way.
 
C
> According to Atmel's web site, it includes:
> http://www.atmel.com/dyn/products/tools_card.asp?tool_id=4118
>
> * Runs on Microsoft Windows and Linux platforms
> * Cross compiler for AVR32 devices
> * Assembler and linker for AVR32 devices
> * Debugger for AVR32 devices
> * Flash programming tools for AVR32 devices
> * C-libraries for development of C/C++ programs <

I see now that ARM has a similar IDE for the Beagle et al.

> http://www.keil.com/pr/article/1201.htm <

Too bad the simulator will be available "real soon now".

I like these trends, before you almost had pledge and be initiated to be allowed to join the elite. Somehow they've grasped that making it approachable will attract developers.

> As for Fedora 10, that's kind of old, but they do have updated RPMs for it. They list packages for multiple versions of Fedora, Red Hat Enterprise, Suse, and Ubuntu (and MS Windows as well). <

I will probably dedicate a box to whatever distro is convenient, but I really like the idea of a bootable CD with all the right stuff on it. I could go the VM route, but embedded devel is quite complicated enough without adding more layers to debug. A CD and "standard" setup would make it much easier to support. This is all quite dynamic though, and people might well want to _use_ all the nifty features. This makes a large, diverse community very important as I wouldn't be vary good at supporting HDTV or DSP noise cancellation algorithms. But I can see where having a fast, floating point DSP would be extremely useful for some apps. And _I_ would like the composite video stuff for a PLC with built in machine vision which has required a Linux PC before. It would be _way_ cool to be able to deliver a "packaged" MV system.

> I wouldn't bother with Eclipse. If you are going to re-distribute source code then I imagine the recipients would much rather have a make file than some sort of Eclipse configuration that may or may not work with whatever version of Eclipse they have installed. <

Well, as I said, I'm fine with VI for development. I was thinking of our command line challenged brethren. At some point, though, if all you can deal with is Windows, point and click, embedded development is probably not for you. The fact that it was drain bamaged for me on an extremely common distribution does not bode well for adopting it. There should only be a limited amount of low level work though. My thought is to write a daemon? that would do the scanning and expose the IO as virtual registers in a shm structure with semaphores or just flags to synchronize the solve phase, thus providing an api to write "normal" programs to. That way folks would not have to deal with sending the right sequence of words to manipulate the IO. If you want to set a bit you just set it in the map and mark it changed and either wait on the flag or simply go on your way. A read could look for a "consistent" flag and set a "solving" flag, write the results and set the changed, flag, etc. The problem is making it friendly to folks that don't have a "normal" way of writing programs for *nix. The good part of being broke is that all this "window shopping" is good research to decide on the best board and tools. For me, the best OS is not an issue. I'm leaning towards the Hawkboard and the OpenEmbedded way of doing things. But, I'm still looking.

> For this sort of project developing on and targeting anything other than Linux is not very practical. You really want to develop on your PC and debug it there and then port it to the target board once you have all the logic errors fixed so you only have to deal with the platform specific issues at that poin. I think that AVR recognizes this which is why they (and other embedded OEMs) are doing things this way. <

I quite agree, but there are some.......

Regards
cww
 
C
Hi

Just a small progress report. I drew the schematic for the input card and sent Bill a copy. Still looking at boards, but I wanted to show how the community can be a huge factor in making things work. This kind of information would save many, many hours of frustration. Rooting it out from the docs, etc. would be a long and tedious task, and you might well not even succeed.

http://elinux.org/BeagleBoard/SPI

With that working, the project with a beagleboard would be feature complete. I'd like to see something like that for the other contenders. If I get a chance tonight, I'll start on the isolated input card.

Regards
cww
 
C
Hi All

I just finished laying out the isolated input card. It has 16 DC inputs that can be either source or sink. The inputs are in groups of 4 with a common so you can have 4, 8, 12, or 16, source and the rest sink or vice versa. 5000 V isolation. There is a full guard trace between ins and outs on the isolators to intercept leakage. Cost will be about $6 more for the isolators. I will add an option for back to back Zener diodes to set the logic threshold tomorrow. The isolators are the double LED type to accept either polarity.

I sent the .png to Bill to put up, but I haven't done rigorous checking yet.

Regards
cww
 
C
Progress, Isolated Input Card.

Well. the back to back Zener idea I had at 2 AM didn't survive the first cup of coffee, so I had to come up with another way to get a reasonable logic threshold with the dual LED isolators. What I ended up doing was using a 10 to 1 voltage divider ahead of the LEDs. Most 24V inputs switch at 10-14 V. With the Vf of the LEDs in the range of 1.0-1.4V they should begin to conduct at 10-14V applied. The LED will clamp the divider voltage so the increase in current as the input goes from the threshold to 24V will go through the LED. The current transfer ratio on these isolators is spec'd rather broadly, from 20-300%. Fortunately the expander has a max input current of 1uA. So, setting the output current of the isolator at 100uA to swamp out all the variables, we want a LED current of at least .5 mA. A total resistance for the divider of say 10k Ohms will supply 2.5ma without the LED and clamped with the LED will supply 2.51mA. 1.4 will go through the resistor and 1.11 through the LED. So preliminary values are 9k and 1k for the divider and 50k for the emitter output of the isolator. I sent Bill a .png of the new layout and will follow with a schematic, probably tomorrow.

Regards
cww
 
C
OK, here's the last in the digital series cards.

I finished a 16 output 24VDC sinking card and sent Bill the .png. Continued hard times in the woods, on the Rum. I'm entertaining any and all thoughts on how to get this built and tested. I don't want to make a general release until it works:^), but if anyone's interested in finding out soon... I'll provide the labor.

Saw a first today, guy sent a job offer to go pull Cat5 locally for $20/hr. But, only if you have a $5000 Fluke DTX tester. If I had the tester, I'd rent it out and he could go pull wire. I'm thinking of an analog card, but, there's no hurry with little prospect of getting it built anytime soon. Still, it helps to keep busy. I was looking at some of the other OMAP series from TI. There's one with quadrature inputs, etc. specifically aimed at industrial control. Doesn't look like it will run Linux though:^( I suppose I could write a PLC executive, but that would be regressive.

Regards
cwww
 
C
I've been scoping out ADCs for an analog card.

First, the good news, the interface is dead simple and the layout should be easy to do.

The bad news is that appropriately priced ADCs top out at about 200k samples per second and 12 bits. What's that you say? That's more than fast enough and 12 bits is more real resolution than you will get in a noisy industrial environment? True, on both counts. But it's a side effect that rains on the parade. Since these are SPI parts, everything runs off the SPI clock. And for 200ksps that is about 3.6 MHz max. This limits the whole bus speed to less than half of the max capability. These would give 4 channels quasi-differential (common low side) or 8 channels single ended. I need to take a look at the commercial offerings to see if this would be adequate as far as accuracy is concerned. To keep the SPI speed high, we wander into more complex ADC with FIFOs and asynchronous conversion. They get spendy fast. Instead of $2.50 they go to $30 to $50 a chip. Time to do more digging. The more esoteric chips are also not commonly stocked so I lean towards the commodity items. I would like a little more speed though. We don't need it for most PLC tasks, but I want to achieve fast scans.

Regards
cww
 
W
What chips are you looking at? Do they have an option for a second clock input? If so, could we add an on-board oscillator? If not, do we really need or even want our SPI bus running at greater than 3.6 MHz? High frequencies can cause their own issues, as you are well aware.

Bill Sturm
 
C
I've looked at TI, Maxim, Microchip and National Semi. I'm concentrating on popular chips that most distributors carry. Best overall so far seems to be MCP3008. But, I need to look at Linear Technology, BB, Analog Devices, Motorola, etc. I'd like 400ksps, 12bits, 4 diff or 8 single ended option, DIP, internal reference would be nice. And of course SPI. At less than $10, if possible. Then it comes down to designing a front end with buffering, wide common mode voltage range, 250 Ohm resistor for 4-20 ma. input, etc. And industrial protection. Fortunately, good op amps are cheap. 0-10V is pretty standard, I'd like a 100mV range for current sensing etc. An active front end is pretty much a necessity to adequately charge a fast SAR convertor. And the need for speed isn't _just_ because I can:^) It enables many good things like averaging samples and software debounce for the digital side, fast PID loops, vibration analysis, fast servos, "real time" machine vision, etc. a lot of the reasons you might use this instead of a "regular" PLC. There are many jobs that want a _computer_ with industrial IO and if you can serve that need as well as the PLC and remote IO facets by design without raising costs too much, it's a win. Then you can have a PLC with PLC software or a platform for advanced automation with only a software change. Most PLCs kinda suck at analog, accurate but too slow for anything but "meter work" because they are content with one sample per scan, (at best, some don't always make it.) But with a multitasking OS, you could do a lot with analog between logic scans or? If you can have faster analog along with all the other things that regular PLCs don't have, it's worth a little effort. Michael asked, why I am doing this? To make a mediocre PLC is not on that list. You get a good idea what folks could use watching this list :^). There are many folks that are reading this that could do wonders with a capable platform.

Regards
cww
 
What is the worst and best case scan rates that you calculate for the current design? I have a hard time believing that 3.6 MHz is a problem considering that the old Siemens S5-100U series (including the 95U) had a serial shift register backplane that operated at 9.6 kHz (375 times slower) without having serious problems with digital and analogue I/O.

Here's some example estimates (assuming no overhead):

A) 8 analogue input cards with 8 channels per card. That is (8 cards) * (16 bytes per card) * (8 bits per byte) = 1024 bits. At 3.6 MHz that is 284 microseconds.

B) 8 digital cards with 16 bits per card. That totals 36 microseconds per rack.

C) 1 analogue input card, 1 analogue output card, and 6 digital I/O cards. That is 98 microseconds per rack. That would be a 10 kHz scan rate.

Let's put some perspective on this. To actually make use of data at this speed in a PC application you would need to provide buffered I/O with triggers. The only things that I can think of that operate at comparable speeds are low end data acquisition systems. A factor of 2 faster won't make much difference.

I don't know enough about the hardware to say what other overhead factors might come into effect, but raw backplane speed doesn't seem to be a problem. Perhaps you could provide some estimates that take into account whatever factors that I've overlooked.
 
C
Hi Michael

> What is the worst and best case scan rates that you calculate for the current design? I have a hard time believing that 3.6 MHz is a problem considering that the old Siemens S5-100U series (including the 95U) had a serial shift register backplane that operated at 9.6 kHz (375 times slower) without having serious problems with digital and analogue I/O. <

Digital is no problem, perhaps 40 clock cycles even refreshing the control registers. That would be worst case. And it will run at up to 10 MHz. About 4 uSec a card. + switching TBD. Twice that if the linear stuff slows the clock to 5MHz. > Here's some example estimates (assuming no overhead):

> A) 8 analogue input cards with 8 channels per card. That is (8 cards) * (16 bytes per card) * (8 bits per byte) = 1024 bits. At 3.6 MHz that is 284 microseconds. <

Here's where it gets more sticky. 10 bits or 12 bits are read as two reads with most hardware. Some ADCs want a setup write to change channels. Minimum 24 bits X 4 or 8 channels. I lean towards 8 channels to provide best bang/buck. Lets say 200 clock cycles with start bits and channel switching. IFF I can run at 5 MHz that's 40uSec for the rack, worst case could be higher if I have to run the clock slower and I'm sure there's some setup with the GPIO and the SPI hardware. Then there's the elephant in the room, one sample on a signal doesn't mean much. For 10 _effective_ bits, I'd like to average at least 5. I know others may well use a single sample, but…..

> B) 8 digital cards with 16 bits per card. That totals 36 microseconds per rack. <
> ----- snip ----

> I don't know enough about the hardware to say what other overhead factors might come into effect, but raw backplane speed doesn't seem to be a problem. Perhaps you could provide some estimates that take into account whatever factors that I've overlooked. <

Now, a PLC cycle involves a read, solving, and a write. Logic solving with optimized C won't take long, but there are scheduling uncertainties etc. It will be faster than most PLCs but you can see how you want to aim high. A mostly digital rack should be great, but if you want to debounce in software you would probably want to look for 3 consecutive states. etc. Of course, every other PLC has many of the same issues, but they get to hide theirs under a big black shrinkwrap tarp. It's not a detailed analysis, but you can see why I want everything I can get before we account for Murphy and Nyquist. I can always slow it down if it's too fast:^) I'm taking state of the art as a 1mSec scan. That doesn't mean much if you have 15mSec filters, but it is a goal I'd like to beat comfortably. And if you aren't using the cyclic model, I'd like to be able to handle those low end DAQ and motion solutions. This PLC will have the compute resources to do so. I'd like to fill the backplane pipe at 10MHz or whatever the OMAP will do. If it doesn't raise the cost much, it's better to have it and not need it than to need it and not have it. I would like to have it unconditionally software limited. Then the hardware guy has done his job. It gets back to your question of: Why do it? Just to have a PLC that runs Linux is OK for me, but if I can build a better PLC that runs Linux, that's a better reason. So far, it hasn't been very hard to move into PAC territory and I can't see any downside. I would be very disappointed if it doesn't outdo a S5. I'd like to be sure that even with tradeoffs down the line, it'll be more than competitive.

Regards
cww
 
24 bits per channel at 5MHz doesn't change the numbers much from my previous post on this which used 16 bits per channel at 3.6 MHz. With a rack full of I/O, that is 64 channels at a rate of 3.2 ksamples/sec per channel. Or, to put that into DAQ board terms, that's like buying a 200 ksps DAQ board (3.2k * 64 = 208k).

64 channels is a lot of channels. A realistic typical application might have 4 analogue inputs, 2 analogue outputs, 48 digital inputs, and 24 digital outputs. Let's estimate the following:

1) AI = 4 * 24 = 96 bits.
2) AO = 2 * 24 = 48 bits.
3) DI = 48.
4) DO = 24.

Total is 216 bits. At 5 MHz that is 43 usec (that is close to the number in your example). That can be sampled at 23 ksamples/sec.

For "PLC" type applications, your problem is going to be how to make use of this data. A you said, you could have the "firmware" (libraries) in the "PLC" board do averaging or other filtering. There is a limit to how useful that is however.

For PC applications connected over Ethernet, you would probably want to buffer the analogue channels and let the end user do his own filtering, since he may want to do something other than simple time domain averaging. This is going to need something more than a simple Modbus/TCP interface however. The user would need to be able to start and stop sampling, configure buffer sizes, etc.

My opinion is that this is fast enough. I suspect your bottleneck is going to be finding some effective way to make use of this I/O bandwidth on the CPU board.
 
C
Hi Michael
Yes, on paper, it should be fast enough. I'm thinking there will be some slippage as there is in almost every engineering project with this many variables. As far as what to do with the data to use it, I am thinking of breaking the ties to the application. That is, putting all the reading, writing, debounce, averaging, etc. in a subsystem that writes to a map and runs at I/O cycle speed. That way applications don't have to deal with all that detail. They just read the map.

This seems to be one way to get less than + or - 1 scan uncertainty, provided the map is updated faster than the application scan. I do need to think it through more, but it should also make more programming models usable than just cyclic execution.

I also have to see just how much CPU that would consume. I hope I can justify the choice of serial rather than parallel, but it seems practical so far.

In related news, I did check with SourceForge and they said it would be OK to host the files there. And I also checked into a website if people want to obtain boards, etc.

Regards
cww
 
C
In my continuing examination of the SBC field, it has come to my attention that there is a fly in the ointment. I was going to leave level shifting for the SPI bus and extra chip selects up to the selector of the SBC. This simplifies the backplane, and the level shifter should really be close to the driving pins. Perhaps on the plug where it connects to the SBC. I was thinking some may not need level shifting at all. Actually they would be best on board on the SBC.

Unfortunately, it seems no one does this. And there are 3.3V, 1.8V, 5V and all manner of drive capabilities. I see an application headache there.

So, I guess the thing to do is put them on the backplane. Obviously, this is an industry wide headache in mixed systems, so there are chips available for the purpose. The problem, is that since this is an ugly necessity, they put the function in as small a package as possible. The largest I've seen so far has .65mm (about .025") pin centers. This is maybe OK from the board fab side (I have to check) but would be a PITA to ever replace in the field.

The chips I'm considering are fairly universal and would connect anything to anything, at speed, but I'd like to find some that are reasonable to handle, solder and replace, if need be. They also want power for reference from the levels to and from. At least they don't take up much space. Reference the MAXIM MAX3378 and MAX3390 and you'll see what I mean. It may be that there aren't any good alternatives.

Regards
cww
 
C
Yes, you can, but getting nanosecond switching times out of them is non trivial and uses more board space. And you would have to use FETs
because with 1.8V logic VCE(sat) of most BJTs isn't a guaranteed low. So, I took a look at what you would have to do to add level shifters to the backplane.

About the time I got it figured out, it was done. I'll send the .png. Power is an issue, not because they use any real power, but because the backplane has only 24V. So, I hooked the high side to the CPU regulator so that will have to be populated. The rather problematic low side voltage will come from the SBC, or worst case, I added yet another spot for a regulator. I haven't seen a 1.8V fixed regulator at the usual vendors, but I'm sure someone makes one.

Regards
cww
 
Top