IO busses/bandwidth

C

Thread Starter

Curt Wuollet

Hi All

Attempting to resurrect my PC104 PLC project now that the dust has settled a bit. I've got a question for those folks who have dug a little bit and pried details from the manufacturers. As you may remember. I was proposing the ISA bus as exemplified on the PC104 connector as the module bus for my PLC backplane. The reasons are many, it is well understood, it is "hackable" by persons who aren't hardware professionals and it is inexpensive to interface to with garden variety TTL OTS components.

The question is: What widths and speeds are used in industry equipment? I've seen some, for example, Wago/Beckhoff stacks I/O with very few pins, most I/O modules seem to have narrow busses, I'm reconsidering the decision before I charge off in that direction again. And please recall that I'm talking about simple IO here. Complex functions, frame grabbers high speed analog, etc. would be handled by stacking cards on the PC104+ bus. I'm not prying for secrets here, I just want to have the best throughput available in a PLC form factor.

And yes, I know the move is on to obsolete ISA, but thirty years from now it will still be easy to learn and work with.

Regards

cww

P.S. It occurred to me that we may have readers who have no idea what I am talking about since it's been more than a year since the original thread. This past year has been rather too traumatic for me to deal with side projects, but I've finally stabilized things to the point where I can rise above survival.

Anyways, here's a link to the original discussion with some very good points raised by folks familiar to us all.

http://www.control.com/1012600615/index_html
 
M

Michael Griffin

On June 12, 2003 00:07, Curt Wuollet wrote: <clip>
> Attempting to resurrect my PC104 PLC project now that the dust has settled
<clip>
> The question is: What widths and speeds are used in industry equipment?
> I've seen some, for example, Wago/Beckhoff stacks I/O with very few pins,
> most I/O modules seem to have narrow busses, I'm reconsidering the decision
> before I charge off in that direction again. And please recall that I'm
> talking about simple IO here. Complex functions, frame grabbers high speed
> analog, etc. would be handled by stacking cards on the PC104+ bus.
<clip>

The Siemens S5-100 series (S5-90, 95, 100, 102, 103) used a serial bit-shift bus for the I/O backplane that I believe runs at 9600 bps. The real bottleneck for this PLC isn't the bus speed, but rather the limited number of bytes you can transfer to a card (slot) in a single scan. This isn't a problem with simple digital I/O, but it is a problem with communications cards and other modules where you would like to transfer larger blocks of data.

I won't bother describing how the S5-100 addressing works, however the lesson here is that the "simple" backplane bus became one of the most serious design defficiencies for the smaller S5 PLCs. I believe that newer PLC designs tend to have a dual backplane bus, with a low capacity bus for digital I/O, and a higher capacity bus for more demanding applications.

Analogue actually tends to not actually require much bus bandwidth for PLCs, since the aquisition rate depends upon the PLC scan rate (you don't do digital signal processing in ladder logic). The main requirement is just to have enough addressing space to account for however many channels you want in a single slot. This isn't much different from high density digital I/O.

If you are looking for something low cost and simple, I would suggest using a serial protocol such as I2C. There is (or at least was) a lot of chip support for this, and "low cost" requires a minimal chip count.

Unless I have misunderstood your question, you appear to want to design your own I/O. Is there a reason why you don't want to use Wago or Beckhoff for now?

--

************************
Michael Griffin
London, Ont. Canada
************************
 
Curt, I am sure you know that PC104+ uses the PCI bus rather than the ISA bus. This is a great form-factor for small PC-based controllers.

Dick Caro
============================================
Richard H. Caro, CEO
CMC Associates
2 Beth Circle, Acton, MA 01720
Tel: +1.978.635.9449 Mobile: +1.978.764.4728
Fax: +1.978.246.1270
E-mail: [email protected]
Web: http://www.CMC.us
============================================
 
M

Michael Griffin

To clarify this further for anyone who may be interested, I believe that PC/104 uses the ISA bus, and PC/104+ uses the PCI bus. In both cases these are stackable pin and header connectors rather than edge card (as used in desktop PCs). The reason for supporting these buses electrically is to use existing chip set supplies. I believe that some systems will support both buses, with the unused bus being "passed through" on the opposite side of the card.

--

************************
Michael Griffin
London, Ont. Canada
************************
 
C

Curt Wuollet

Hi Andrew

Yes, I have used the computerboards stuff as well. In fact I designed a translator board for the DIO48 to 24 V levels with optoisolation and released it to the MAT project. That's fine where you can use a PC.

What I feel is needed is a PC compatible PLC. It fits in the same speces has no moving parts, is equally reliable, IO is added in increments. etc. In other words, a real PLC that happens to run Linux rather than whatever the other folks run. And it will be a totally non-proprietary PLC with schematics, artwork and source code and no secrets so you can add your own cards or integrate your own software or interface to most anything. And the cost should be more than competitive with comparable systems. The idea is to make all the things that are wrong with PLCs go away while enhancing what is right about them. There's very little rocket science in a PLC, so this should be an above average unit and very sophisticated in terms of communications and other areas where the market leaders can't compete because they won't agree on anything. This first version is only the beginning. I expect that, like Linux, the idea will appeal to some very smart people who can refine things in Internet time just for the thrill of making something great for the community. It shouldn't be very hard at all to assemble a design team that no PLC vendor can match. This is the stone for the stone soup.

Regards

cww
 
C

Curt Wuollet

Hi Michael

On June 14, 2003, Michael Griffin wrote:
> On June 12, 2003 00:07, Curt Wuollet wrote: <clip>
>
>> Attempting to resurrect my PC104 PLC project now that the dust has
>> settled
>
> <clip>
>
>> The question is: What widths and speeds are used in industry
>> equipment? I've seen some, for example, Wago/Beckhoff stacks I/O
>> with very few pins, most I/O modules seem to have narrow busses,
>> I'm reconsidering the decision before I charge off in that
>> direction again. And please recall that I'm talking about simple IO
>> here. Complex functions, frame grabbers high speed analog, etc.
>> would be handled by stacking cards on the PC104+ bus.
>
> <clip>
>
> The Siemens S5-100 series (S5-90, 95, 100, 102, 103) used a serial
> bit-shift bus for the I/O backplane that I believe runs at 9600 bps.
> The real bottleneck for this PLC isn't the bus speed, but rather the
> limited number of bytes you can transfer to a card (slot) in a single
> scan. This isn't a problem with simple digital I/O, but it is a
> problem with communications cards and other modules where you would
> like to transfer larger blocks of data. <

I would like my "slow" bus to be several mb/sec.so it can handle those things problematic on typical PLCs. There's really no reason not to since the processor will be powerful enough and slow chips aren't much cheaper than fast ones.

> I won't bother describing how the S5-100 addressing works, however
> the lesson here is that the "simple" backplane bus became one of the
> most serious design defficiencies for the smaller S5 PLCs. I believe
> that newer PLC designs tend to have a dual backplane bus, with a low
> capacity bus for digital I/O, and a higher capacity bus for more
> demanding applications. <

Yes, this IO bus design will be 8 (possibly 16) bits wide at >10 Mhz. And for my vision and high speed DAQ, there's the PC104+ version of the PCI bus. And I can buy those cards in a commodity market.

> Analogue actually tends to not actually require much bus bandwidth
> for PLCs, since the aquisition rate depends upon the PLC scan rate
> (you don't do digital signal processing in ladder logic). The main
> requirement is just to have enough addressing space to account for
> however many channels you want in a single slot. This isn't much
> different from high density digital I/O. <

I'm looking at 8 registers per slot with a bank option for more. There's a trade off when most slots will be far less than 64 points. The software can mitigate by skipping empty space if the existing points are kept packed and contiguous.

> If you are looking for something low cost and simple, I would suggest
> using a serial protocol such as I2C. There is (or at least was) a lot
> of chip support for this, and "low cost" requires a minimal chip
> count. <

I looked very hard at I2C, SPI, and other "onboard" buses. I couldn't find the types of functions I need for digital IO. There are some pretty slick A/D and D/A offerings though. The strange thing is that since parallel busses have been the rule, the chips are there and are cheap. And my backplane cost is square inches, whether I have 2 or 40 lines, the size is determined by the size needed to make practical connections to the real world on the modules and the PC104 footprint. A 6"x14" backplane is what it shakes out to. 6" for the PC104 footprint with space for side connectors. And 14" for 8 slots reasonably spaced.

> Unless I have misunderstood your question, you appear to want to
> design your own I/O. Is there a reason why you don't want to use Wago
> or Beckhoff for now? <

I've used both and liked them. And a PC and remote (Ethernet) IO suits me fine where I can use a PC. I want to remove the rest of the silly PC vs PLC argument by simply making a "real" PLC that runs PC software. And I can solve an unbelievable number of problems by making it Open and diametrically opposed to the industry norm in that it will be as easy as possible to interface to and integrate and will hold no secrets. A PLC without the problems and proprietary BS, that you can understand 100%.And fix, and add to. etc. etc. with parts from any
distributor. And besides, the I/O I've designed so far works very well at $3.50 or so a point. This will be even cheaper and better as I eliminate the $100.00 PC card and ribbon cables :^) It'll be cost effective even if I'm the only one who uses it. By sharing it, I multiply the impact. If others contribute, I get the value of my investment back in design work.

Thanks a lot for the info.

Regards

cww
 
C

Curt Wuollet

Hi Dick

Yes. I'm going to adapt PC104 ISA slightly as an IO bus and use PC104+ PCI for networking, Fast DAQ, vision and other demanding tasks. Did I confuse something?

Regards

cww
 
A

Alex Pavloff

The PC104 Consortium's specs for PC/104 and PC/104-Plus are available at PC104.org.

PC/104-Plus cards are required to pass-through the normal PC/104 connector.

That being said, I have seen very few systems that use PC/104+, and few PC/104+ cards. I think that the main reason for this is that there are few applications that really benefit from PCI. Video, 100MBit Ethernet, and sound are the main draws for normal PCI cards, and most all computers with a PC/104-Plus bus already have those on board, or don't need them!

Plus, from a cost standpoint, the PC104-Plus connectors are denser and quite a bit more expensive than the standard PC-104 connectors.

Alex Pavloff -- [email protected]
Eason Technology --- www.eason.com
--- Linux-based industrial HMI ---
-------- www.eason.com/5k --------
 
R

Rokicki, Andrew

Curt,

I think we are doing exactly what you are trying to do. Except executable is not MAT PLC project, but our C/C++ code. Operating system is Linux. We went it direction you are going. We made our own opto isolation boards(24 VDC) connected them to 8255 type chip and it worked.

Since than went OPTO 22 direction. We buy PC(ISA) I/O boards from computer boards. These boards have 50 pin connector compatible with OPTO 22 pinout.

Reasons for that: 1) We buy ribbon cable instead of making our own - eliminates mistakes making a cable 2) Our own opto board was 24 Vdc only. Now we have any voltage that OPTO 22 provides. or dry contact if needed. 3) We have limited experience making opto isolator boards. OPTO 22 has experience making then.

Yes this cost more up front, but it is cheaper in the long run.
 
B
Just out of curiosity - how many people are willing to accept the basically unlimited liability of producing non-UL listed I/O cards to save a few bucks a point?
 
M

Michael Griffin

On June 17, 2003, Curt Wuollet wrote:
<clip>
> > The main
> > requirement is just to have enough addressing space to account for
> > however many channels you want in a single slot. This isn't much
> > different from high density digital I/O. <
>
> I'm looking at 8 registers per slot with a bank option for more.
> There's a trade off when most slots will be far less than 64
> points. The software can mitigate by skipping empty space if the
> existing points are kept packed and contiguous.
<clip>

Eight bytes per slot was the amount that Siemens found wasn't enough for analogue addresses for the smaller S5 series. For the S7-300 they increased this to 16. You haven't mentioned the word size of your "registers".

8 bytes per slot would allow only 4 12-bit analogue channels per slot, while 16 bytes per slot allows 8 12-bit analogue channels. 8 analogue channels is a reasonable maximum to have on a single card. 4 bytes per slot should be fine for digital I/O, as it is difficult to fit more than 32 wires into a small I/O card.

The way Siemens dealt with digital I/O and analogue was to have two overlapping address spaces covering the same slots. For example, slot 0 begins with byte zero for digital I/O, but begins with byte 64 for analogue space (small S5 series). That is, each physical slot can have a digital or analogue address, and the address increments per slot differed according to the type.

I think the slot addresses should start at a predictable intervals for each slot. If you insert a card into an empty slot, you don't want the addresses of the other cards to be affected by it.

--

************************
Michael Griffin
London, Ont. Canada
************************
 
M

Michael Griffin

On June 19, 2003, Bob Peterson wrote:
<clip>
> Just out of curiosity - how many people are willing to accept the basically
> unlimited liability of producing non-UL listed I/O cards to save a few
> bucks a point?
<clip>

Probably a more worth while project would be to figure out how to make it easy to use someone else's I/O. I don't think producing yet another rack "standard" is going to advance the state of the industry. Very few people will want to make their own if they can buy third party commodity I/O. Most people who work in our business aren't electronics experts, they're machinery experts.

--

************************
Michael Griffin
London, Ont. Canada
************************
 
C
I've been assuming that both busses were usable simultaniously. It's not a tragedy if this isn't true but, it would add serious capability for servo, machine vision, etc. Things that can benefit from speed. I'll have to do some checking, I hadn't got real particular on PC104+ just yet, seeing as how I still figuring out how to fund any proc to put on my board. Someone has donated a SBC with a PC104 interface to the cause, that will let me run my proto, but eventually I'll need the real thing when I want the proc on the board rather than the board plugging into the SBC.

Regards
 
C
Hi Andy

It's interesting that you found it cheaper to buy this stuff, even in the long run. Of course, I can also do triacs, MWR, power FETs relays and analog as well as AC inputs, IA inputs, etc. Thermocouple inputs are a little problematic as connectors are expensive, but none of this stuff requires any substantial research or development, at least on my part. The board layout is the only real time consumer and I've grown to enjoy that. The cost equation is one of many reasons I'm doing this. For the cost of a $100.00 DIO card, I can build a backplane and perhaps a couple I/O modules. I'm donating the time simply to be designing stuff again, something else I enjoy. When I'm done, I get the kind of automation platform I'd like to use, and anyone else who wants to can use it at cost, which is a bargain. If I can round up a couple of paying jobs, it'll pay for my whole development effort. It's a great platform for test equipment and vision systems, two areas where other PLCs are kinda sucking wind and the world class comms capability should suggest a lot of other applications not addressed by the market leaders. My entire cost for the project, including time, still shouldn't cost anywhere near what getting well set up for AB, GE, or Modicon would cost. And I don't have to work in Windows. I'd much rather spend the price of admission this way than supporting the monopoly and it's partners. The way I figure it is $5000.00 to use a commercial product with tools I don't like, or much less to create something I like a lot better and can share with others as well. It's a no brainer. And there's no reason I can see that it shouldn't be a better machine because it will use more and better electronics without a penny pinching accountant to answer to. Crack open a SLC sometime and tell me what the actual hardware cost. Then compare it to what I propose. ;^)

Regards

cww
 
C
How many factories don't already have an ample collection of unlisted assemblies and stuff they've put together. In the places I've been, the last thing I'd be worried about is the control stuff. It's a good and valid point, but computer equipment operated from low voltage listed supplies shouldn't be a liability problem as long as you wire it per code. That's not to say that it couldn't be an issue, but any real world factory has a lot of issues.

Regards

cww
 
C
Hi Michael

I'll answer from what's in front of me right now. I'm doing scehmatics in Xcircuit even as we speak. I could use some feedback on the tradeoffs. Not cast in concrete yet, but getting firmer.
 
C
That is a worthwhile goal, but it doesn't require any talent. Most folks that support multiple IO types simply use their checkbook as that is the whole point of the excersise. I'm sure for enough money AB would let me use DH+ with the mat project. Or they might simply refuse. That's the whole problem. As long as the guys who control the hardware and software simply refuse to cooperate and as long as there are only closed systems, there isn't much we can do about it. Indeed that is the whole reason for the closed software and hardware.

So, I still have to use proprietary equipment and tools where I can't use a PC. And they still all come in only one flavor, closed with Windows tools. And they still can't be made to work together because we as users have no control over the software on either end. Since I see absolutely no likelyhood that these guys are going to cooperate in our lifetime, the only way that openness and interoperability can be achieved is with a platform where _we_ control what it runs on and what runs on it. It doesn't matter that much to me how _practical_ it is using the prevailing frame of reference, that frame of reference recognizes only closed systems. There needs to be a truly Open PLC and I can do that.. Instead of only one type of PLC, there will now be a choice, Closed or Open. I think that's a much more worthwhile goal than simply another closed offering. It's a choice I want, and one that I simply don't have until someone creates it. So, I'll create one, it's actually less hassle and expense than dealing with what's out there. I'm not creating another standard, merely providing a choice. If enough other people like to be in control of their hardware and software, then it will become a standard.

Regards
 
On June 19, 2003, Andrew Rokicki wrote:
> I think we are doing exactly what you are trying to do.
> Except executable is not MAT PLC project, but our C/C++ code.

"Why not?"

Obviously, you have your reasons; but it'd be nice to know if there was/is anything in particular that would stop you from using it, so we can improve the MatPLC...

(If you don't think it's interesting for the list, you can e-mail me at [email protected])

Jiri
--
Jiri Baum <[email protected]> http://www.csse.monash.edu.au/~jirib
MAT LinuxPLC project --- http://mat.sf.net --- Machine Automation Tools
 
R

Rokicki, Andrew

On June 21, 2003, Curt Wuollet wrote:
> It's interesting that you found it cheaper to buy this stuff, even in the
long
> run. Of course, I can also do triacs, MWR, power FETs relays and analog as
> well as AC inputs, IA inputs, etc.

It is cheaper for us to buy we are in automotive business and we know how to make auto parts. As it is it costs us bout $12 per desecrate I/O. We are not experts in making I/O modules. We do have in house expertise but it is not cost/time efficient. I/O cost is already a very small cost of out equipment.

> problematic as connectors are expensive, but none of this stuff requires
any
> substantial research or development, at least on my part. The board layout
is
> the only real time consumer and I've grown to enjoy that. The cost
equation
> is one of many reasons I'm doing this. For the cost of a $100.00 DIO card,
I
> can build a backplane and perhaps a couple I/O modules. I'm donating the
time
> simply to be designing stuff again, something else I enjoy.

If it is something you enjoy go for it. Who know you might have something.

My entire cost
> for the project, including time, still shouldn't cost anywhere near what
> getting well set up for AB, GE, or Modicon would cost. And I don't have to
> work in Windows.

I totally agree with you. I haven't worked with Windows/PLC in past 3 years and I like to keep it this way.

Crack open a SLC sometime and tell me what
> the actual hardware cost. Then compare it to what I propose. ;^)

I refuse to touch SLC in any way. I don't think my license is up to date :p Don't care what they do. I can do the same with PC and Linux better-faster-cheaper so why bother.

So that said. Good luck with your project.
 
Top