# Free PLC Progress.

C

#### 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.

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.

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 :^).

Regards
cww

M

#### M Griffin

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

M

#### M Griffin

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.

S

#### Steinhoff

> 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

K

#### Ken E

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

K

#### Ken E

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

S

#### Steinhoff

> 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

#### curt wuollet

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

#### curt wuollet

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

M

#### M Griffin

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

Regards
cww