Free PLC Progress.

C

Thread Starter

curt wuollet

Hi all

I've breadboarded the Freeduino running the MCP 23S17 and that works. I also
modified the backplane to 4 slots and installed a header to allow an IDC
connection. I was pondering what to write on the FD to talk to the Linux host.
What I sketched out began to look like a lot of work and Yet Another Duplicative
Protocol (YADP tm.). So I searched and lo and behold, there is a Modbus RTU
slave program for the 'duinos. I may pull it down and see what it gives. The
advantage there is that there is also OSS Linux Modbus RTU master software, so I
wouldn't have to write that either.

> http://sites.google.com/site/jpmzometa/arduino-mbrt/arduino-modbus-slave

This would allow me to produce something useful while waiting on the PLC engine,
a 64 point DIY Modbus RTU slave. The cost should compare very favorablyHi all

I've breadboarded the Freeduino running the MCP 23S17 and that works. I also modified the backplane to 4 slots and installed a header to allow an IDC connection. I was pondering what to write on the FD to talk to the Linux host. What I sketched out began to look like a lot of work and Yet Another Duplicative Protocol (YADP tm.). So I searched and lo and behold, there is a Modbus RTU slave program for the 'duinos. I may pull it down and see what it gives. The advantage there is that there is also OSS Linux Modbus RTU master software, so I wouldn't have to write that either.

> http://sites.google.com/site/jpmzometa/arduino-mbrt/arduino-modbus-slave

This would allow me to produce something useful while waiting on the PLC engine, a 64 point DIY Modbus RTU slave. The cost should compare very favorably with the OTS products :^).

The shrink on the backplane brings the cost for 3 down to $26.50 plus postage. This is doable, so, I'm going to attempt to get it in the 4/19 run. IO cards are still problematic at about twice that for 3, so that may be a while. I think this may play well with the arduino crowd as well as automation types. That's good as it's a larger audience. And less hidebound :^)

Regards
cww
 
C

curt wuollet

Update:

The 4 slot backplane is submitted for fabrication, so I'll be cleaning up the IO card designs. One messy detail is the traditional led status lights. With the high IO density, locating, wiring, and driving these is a headache. And still, after all these years, there is really no good cheap method of mounting raw leds. And you need 65 wires, 64 resistors, and 64 leds. After looking at all the alternatives, assemblies, bargraph displays, etc., they are just not practical. This functionality will be provided by a serial LCD display as is used on some, newer, bricks. The cost is much the same, all factors considered. And it has some advantages. It will work with any processor, needing only 3 wires, and can be used to provide other gritty details. Since these are OTS, they are off my plate and are optional where not needed. I've found an inexpensive case that I think will work, eased greatly by the shorter backplane. After looking at the thing close up so many times, it looks tiny at 1:1 and is just 1.25" x 4.25". The IO cards are large by comparison at 2.5" x 3.5" but I can't really shrink them because the terminals need to be real world usable. So, the case needs to be about 6" long (to allow space for a processor) x 4" high (for slot guides) x 3" deep. This is a far more common aspect than 11 or 12" long. I might miss this weeks board run, but after all this time, a few more days is no big deal. One thing I missed mentioning is that the rack with the Freeduino will not only have 64 discrete points, configurable in groups of 16, it will also have 6 single ended analog inputs. I saw a ladder logic compiler for Atmel, but it only works on Windows, so it's a non-starter for me. It's OSS though, so it could probably be ported if I had a burning desire to have a full blown PLC on the Freeduino.

Regards
cww
 
I just did a minor bug fix (reporting the CPU type) for someone who was trying to run MBLogic on an ARM board ("/proc/cpuinfo" is apparently different on ARM than on x86). I've asked him what board he is using, and if he replies back on that I'll let you know how he's doing.
 
C

curt wuollet

Yes, that would be most interesting. The backplane made it into this weeks batch and I'm working on getting the isolated input card ready for fab. I also pitched the project to the PandaBoard folks again on their "Ask for a PandaBoard" channel and we'll see what develops. With 22 terminals on each input card and 18 on each output card, I can see why most PLCs come with old fashioned terminal strips rather than wireclamp connectors. Through normal channels they would be the most expensive part of the project. I'm working on a solution, it may require direct import from HongKong. Even buying surplus from EBay is pretty much impractical at this point. Something isn't adding up because I've bought boards for less than the cost of their connectors. There must be huge volume discounts. Pluggable connectors would be a boon, but would cost over $2 a point from the usual suspects. I have the boards set up for .150" (3.81mm) centers, any reasonable suggestions would be appreciated. The electronics are extremely cheap in comparison.

Regards
cww
 
He said he's using an Atmel SAM9G20-EK. He said it's working (the demo runs with all the client connections turned off), but he hasn't networked it to external I/O yet however. I just looked up the price, and it's not cheap, so it wouldn't be my own first choice if I was on a budget.

As far as terminal strips go, I seem to recall those being surprisingly expensive (especially the pluggable ones). I think there are some pretty massive quantity discounts, but you have to be prepared to buy a lot. I worked on some projects which used custom electronics, but I wasn't the guy buying the parts so I don't know the details. My recollection though is that I think the packaging and connectors cost more than everything else put together. The actual electronic components were the cheap part.

What I recall though is that the hole centres for the pluggable blocks were slightly different from the non-pluggable ones. That meant we couldn't make the board prototypes using the non-pluggable ones (which were easier to get) and switch to pluggable ones (which we had to special order) later without having to do new boards.

People servicing industrial I/O *really* want the pluggable blocks though. If you can get ones with compatible hole centres in both styles, that might help. I don't know if they're available though.
 
K

Ken Emmons Jr.

I've been kind of laying back mostly because I'm not able to contribute.

I did want to mention that I've been looking into EtherCat for use in a work project and I have to say that the technology that is going into that bus is amazing. When you look at what you get with the Beckhoff ethercat terminal IO system for the money it is amazing. We're talking something on the order of 10us updates on hundreds of IO points. I have heard of a linux implementation and know if it being used in at least one commercial application. The one down side is that I think the linux port only works with certain Ethernet chips, probably because it would take porting drivers. Just mentioning this for what it is worth as this could signify yet another way to go for folks going about controls their own way.

KEJR
 
10 usec I/O update? I can point out top selling PLCs that can't add two numbers together that fast. Most valves and motor contactors couldn't do anything useful with 10 msec updates let alone 10 usec.

From what I understand about Ethercat, a lot of what it does requires special hardware including special chips. The field devices don't use standard Ethernet chips. The client either requires a low latency RTOS, or it needs a special interface board. It's "Ethernet", but not Ethernet as we know it.
 
> I've been kind of laying back mostly because I'm not able to contribute.

> I did want to mention that I've been looking into EtherCat for use in a work project and
> I have to say that the technology that is going into that bus is amazing. When you look
> at what you get with the Beckhoff ethercat terminal IO system for the money it is amazing.

That terminal IO system is also available for PROFIBUS, PROFINET, MODBUS a.s.o

> We're talking something on the order of 10us updates on hundreds of IO points.

That's only possible with a small Ethernet packet carrying a few IO bytes ... it is not typical for EtherCAT, is is typical for the transmission speed o0f 100Mbit/s.

Along with a test of a commercial implementation for QNX6 it was possible to run a minimal bus cycle of ~ 12us ... but only with a very small packet size.

The bus cycle is in general limited by the transmission speed of 100Mbit/s and depends on the size of the transmitted packet. With a full packet size is the minimal bus cycle ~120us and will increase if the transmitted IO data are not fitting in one packet.

These are nice numbers but they are more or less useless for the real control world :)

> I have heard of a linux implementation and know if it being used in at least one
> commercial application. The one down side is that I think the linux port only works
> with certain Ethernet chips, probably because it would take porting drivers.

This is correct for the implementation of the EtherCAT master ... for the slaves you need special FPGAs or ASICs providing the function of the patented FMMU device.

> Just mentioning this for what it is worth as this could signify yet another way to go for
> folks going about controls their own way.

The API of this system is LGPL ... but the core is based on GPL 2.0. The usage of the name "EtherCAT" must be licensed by Beckhoff...

An other opportunity is Ethernet Powerlink... it available in full sources and it's licensed by a BSD license! They are using the libpcap for the user space implementation ... so It is not bound to a specific Ethernet controller. So you can use it also with 1000Mbits/s. I did recently a port to QNX 6...

Best Regards
Armin Steinhoff
http://www.steinhoff-automation.com
 
M. Griffin:

I respect your work and your contributions here but you have to consider that there are applications where these things do matter, which is why these vendors have these options developed. High speed assembly, packaging, and semiconductor applications care about speed. If you are making high speed machines you cut corners everywhere you can to get your speed, including the IO system, fast valves, short plumbing lines, selective use of servo actuators, etc.

Although the EtherCat bus is capable of the 10us types of speeds, in practice you are looking at something like a 125-500us update polling loop if you are on a realtime system, but that is up to whoever is programming it. The practical limit to Beckhoff IO, by the way, is the input card filter which is 3ms on the standard card, and some number of microseconds on their high speed cards. So depending on your application and how noise immune you want your system to be you can have a choice either way (Both cards have the 24V signaling, so they are fairly immune to a handful of volts of noise anyhow).

Saying that most valves can't operate at 10ms speeds isn't helpful. SMC and Festo have valve lines that can respond faster than this, and I've tested them with oscilloscopes and high speed analog pressure sensors. Its one of those things where most of the time it may not matter, but when it does it is sure nice to have the capability and not have to put your logic into some strange "pulse card" or "BASIC Coprocessor" or something like that.

KEJR
 
Armin,

Those are good numbers. I admit Powerlink seems more interesting in some ways ... Who can argue with a BSD license? The B&R IO is nice, but I'm not sure who makes a small servo drive similar to the offerings of Yaskawa. Certainly the B&R drives are huge if you need a 50W or 100W motor. Something to consider though.

KEJR
 

> Those are good numbers. I admit Powerlink seems more interesting in some ways ...
> Who can argue with a BSD license? The B&R IO is nice, but I'm not sure who
> makes a small servo drive similar to the offerings of Yaskawa. Certainly the B&R
> drives are huge if you need a 50W or 100W motor. Something to consider though.

Baldor is also offering sophisticated drives operating with Ethernet Powerlink. Hope they are not so "huge" .

Best Regards
Armin Steinhoff
 
C
I would expect so, even with the FreeDuino. After a few setup bytes that don't need to be repeated, each slot takes 4 bytes, two address and two data, plus however long it takes to set the /cs low before and high after the R/W. Lets say 24 cycles to be conservative. I was running on the breadboard at 4MHz. That's 250 nSec/cycle or 6 uSec per slot. 24 uSec. updates? That would be split between the input card read and output card write. With termination resistors on the PCB, I should be able to run at 8 MHz (breadboards are pretty terrible for signal integrity). And there is a mode that auto increments the addresses, saving one address byte. I don't see bus speed as ever being an issue. Even with 8 slots. Of course, there will probably be something that won't allow these speeds, but it looks fast enough out of the gate to handle a few impediments. So, the speed will be limited by whatever solving or comms write the I/O map. The Arduino language is a thin layer on top of C, and if that's not fast enough there is the AVR-gcc C compiler. I haven't looked at the Modbus slave software, but I think the whole works should run at Modbus speeds with the Freeduino. With any of the ARM SBCs, the hardware shouldn't be a problem. I've got the isolated input card and the sourcing output card pretty much ready for fab and the backplanes should be arriving in a week or so. The I/O will have to wait for funding. It's kind of a drag having to string things out, but at least something is happening.

Regards
cww
 
C
Let's just say that it's not very hard to achieve higher speeds than the norm for PLCs. But it isn't necessary for the great majority of PLC apps and there is some wisdom in limiting speeds and using the filtering commonly used. It allows the non-critical wiring and covers many other sins. It is entirely possible to run IO at MHz speeds, but not through open wires and wiring troughs and 200 ft of conduit with a bunch of other stuff. That is, it's a whole different ball game than typical PLC practice. For more than a couple feet, you would need some type of transmission line and line drivers and receivers for reliable signals. I have not done any deliberate filtering in my I/O and it should run up to this practical limit, at the same time, I haven't made any effort to handle light speed either. The optoisolators aren't particularly fast at low current levels, and open collector outputs with this current capability are not a good choice for driving wire at high speeds. I thought about dropping in some chip cap pads for input filtering, but decided to see if they are really needed. The industry practice is to use some sort of network to talk to high speed stuff and that's probably wise for the automation market and probably easier than using discrete I/O above the easy region. But I would doubt that these cards would be limiting for your high speed packaging, etc. I do motion too, so they will be as fast as practicable within reason. Then slowed down if too many problems ensue. The great part is that making a totem pole or even H bridge output card wouldn't be difficult and the non-isolated inputs should be as fast as the chip, being entirely passive in the signal path. And if needed there is still the possibility of interrupt on change which I brought as far as the card connectors. I didn't spend the extra paths on the backplane, but it's trivial to turn a new backplane with interrupts. In short, acting like a PLC has advantages and disadvantages. At some point you simply leave the PLC envelope to custom electronics. Oh, it looks like I'm still in the automation hunt, I'm not qualified to be a Radio Technician:^). Meantime I'm still heavily into firewood. And designing a PLC.

Regards
cww
 
In reply to Ken E: I'm not saying that there is no market for Ethercat. I'm saying:

1) The special hardware requirements for Ethercat mean it probably isn't practical for Curt Wuollet to implement in his I/O project.

2) Point #1 probably won't matter to most people.

Therefore, my conclusion would be that Curt should focus on low cost and ease of manufacture and integration. Packaging and terminal blocks or connectors are probably going to be the the most difficult parts of this project, not I/O update speeds.

There is of course no need for anyone stay on topic in this thread, and I have found your and Armin Steinhoff's comments very interesting and informative. However, I did want to put that information in context with what Curt Wuollet was trying to accomplish.

While I'm at this, I'll add my own benchmark numbers to this. A while ago I benchmarked an Advantech ADAM 6000 digital I/O module at an average polling update speed of 700 usec. That's about the cheapest small Ethernet digital I/O module that I can think of. That is an *average* rate however, and I have no idea what latency or jitter there may have been.
 
C
The fact that I would have to license silicon for EtherCat means that it probably won't go in a Free Hardware project in any case. But, one of the advantages of unbundling the bus/cards and the processor is that _my_ license won't cover the processor. So people can use a hyperproprietary board running a shrinkwrap OS and any nasty secret protocols they so desire. Of course, any support ends at the connector in that case. The fact that the processors I'm considering are Open Hardware from entities that want to share IP, is not a coincidence. As the whole TI ARM Android thing has shown, it simply much better for business and support. Secret simply doesn't make sense if you're trying to integrate hardware. And a platform that's popular because it's Open means there are vastly more people who can help than just someones customer service dept. Nearly the whole project comes from the community. Anyways, getting back to progress, I found pluggable connectors from a company called Satistronics. 50 two way sockets and 50 two way plug connectors came to $26 and change including shipping. I feel a little guilty, but this is a one-shot to get the boards usable. People can use whatever type of .150" 3.81mm connectors they want. I ordered now, because shipping may well be a slow boat from China. The interesting part is that the well known items probably come from the same factory.

Regards
cww
 
In reply to M. Griffin:

> 1) The special hardware requirements for Ethercat mean it
> probably isn't practical for Curt Wuollet to implement in his
> I/O project.

Agreed. I wasn't trying to side track Curt, although it may have seemed that way. One of my original views on the backplane design was to have a cheap, simple, open, and [potentially] fast IO system (depending on the host communication adapter). My views on this have changed and I was expressing that. With EtherCat/Powerlink it looks like the doors are open to fast IO in the open source arena, and this changes my viewpoint on how to build a relatively open medium to large system. At this point we are using a third party controller and will be upgrading to EtherCat IO and drives at some point in the future because it is supported on that system.

For smaller Machines the packaged PLCs are hard to beat still. I still dream of designing a Brick PLC that runs C/C++ and RTOS, but I think that would be more acedemic since the majorty of machines I do requiring a small amount of IO are simple enough to run ladder without too many headaches, especially if you have function blocks, etc.

KEJR
 
C
Wait a little while and you can have a 64 point DIY brick PLC that runs C/C++ an RTOS or even BASIC and it will be fast if you want it fast. While waiting for the backplane and funds for the I/O cards. I have been investigating the most inexpensive Linux SBC that can be had that will run Python, etc. It's amazing the variety of ARM based SBCs that are available. I'm thinking ARM 9 is about the lowest for PC class apps. The cheapest I've found for a built out board is the MINI2440 that uses a Samsung ARM CPU. It's about $80 without a display and a few bucks more with a touch enabled color LCD. This is a little below the Beagle Board in HP, I think, but it's hard to compare. If you don't need a whole OS and want to run on UCOS or the bare metal, it gets cheaper in the ARM7 range. You can get an ARMITE Pro for $29 which is an arduino compatible board with an ARM7 processor on it with built in compiled BASIC or you can use C/C++. Of course you could also use a Rabbit or almost any other SBC. The reason I mention these when I'm focused on a Linux PLC is that we often see questions on a PLC that you can program in a HLL. The ARM9 will even run WINCE, although I can't myself think of a good reason to regress with all the buzz around Android. It should be a versatile solution. And the amazing thing is all the gizmos on the ARM boards. Low cost cameras that would be a natural for some machine vision, high quality audio for kiosks, etc., DSP for video processing, etc., ethernet, analog ins and outs, they are really a good deal, even if a bit overkill for a PLC. But, if you need any of those for a PLC app, it would be far easier and cheaper than adding it to a regular PLC. Add to that use as remote IO or an RTU and it's a pretty handy gadget. You will have to be a programmer though.

Regards
cww
 
There is a big variety of ARM processors available, but some of them (especially the older models) have some features removed. While these ones will run special stripped down versions of Linux supplied by the board OEM they won't run a standard distro like Debian. I think that where things really get interesting is where you can integrate control functions with data handling and reporting systems, and for that you want to be able to pick software components from the standard repositories rather than just use whatever the board OEM ships with it. I think it would be worth while checking to see if a board is supported by Debian before choosing it. I think that the most popular ones are, but there are still some that aren't (and never will be).

Given what is appearing on the market, I suspect that most future "PLCs" will be just soft logic systems pre-loaded onto branded commodity hardware of this nature, with I/O connected via Ethernet. The general market production volumes for this sort of hardware will make custom designed CPU modules simply too uncompetitive. The case will still say "Siemens" or "AB" on it, but the hardware inside will be "designed" by sending a couple of people to a trade show to see what's on offer in the various booths.

As for WinCE, I'm not sure for how much longer embedded system OEMs are going to put any money into porting it to their hardware. If Microsoft's currently announced development plans work out then they won't have much reason to continue to sell it beyond whatever their existing contractual obligations require. It's a dead end as a product platform.
 
C
I agree regarding the desirability of mainstream Linux distros. I have been paying particular attention to those platforms which not only support same but also have a considerable following with fora, lists, fan pages, etc. I haven't seen much support for Debian, but curiously, support for Ubuntu keeps popping up. I haven't been following the Ubuntu crowd much, but I would guess that they are trying to be an option for mobile devices, so much of the work is done. And Ubuntu is a child of Debian after all. There is also considerable support for Android, although that really seems aimed at the phone market and a bit heavy for other uses. Even though my personal preference for desktop use is Fedora, I can live with Ubuntu. Support is crucial, even if you've got 20 years with the penguin. And although I have developed a few drivers, that would defeat one of the goals of the project, by using Open technologies, I can do this much more easily than reinventing the wheel. The MINI2440 seems to have a large following as does the BeagleBoard. The PandaBoard less so. In the end, the mass gathered by a platform can be worth a lot more than a few dollars saved. This in large part doesn't apply to the low end boards, but even there it's nice to have a body of code examples. With more time than money, I can do the research.

Regards
cww
 
C

curt wuollet

Just an update. I hold in my hand the first prototype 4 slot backplane. It's really quite a nice job from the fab. In place of the usual rough tinned copper on FR4, it's a full production quality board with dark blue solder mask, white silk screen and full gold plating on all exposed copper. It's almost too pretty to solder and all that at $8.50 each qty 3. Even after all these years, I get excited when the boards come in. I've been ordering parts little by little and I have the 16 point isolated input card and the 16 point sourcing DC output card ready for fab. I'm anxious to get them off, but, I really shouldn't spend the money right now. I'll have to finagle something or drum up some chargeable hours or stare at the boards until I do it anyway. It's just something that needs to be done. The way the Dorkbot proto project works I'll get 3 of each, so the BP can be tested with a range of configurations. But $87.50 is a couple weeks worth of groceries. And there are still parts to acquire. So much for instant gratification:^)

Regards
cww
 
Top