advertisement
from the LinuxPLC department...
"Open" Hardware.
Open-source control projects, related links.  topic
Posted by Curt Wuollet on 1 February, 2002 - 4:59 pm
Request For Comments:

I had hinted before that a new hardware project was in the works to provide a standard open PLC style platform for PC automation projects that need a home with a PLC form factor and modularity. I, of course, am primarily concerned with the LinuxPLC/MAT stuff, but Open means just that, and the platform should work with other OS's providing someone writes drivers.
This idea hasn't been cooking for long, indeed it's a variation of the first platform which addresses some issues and is much easier to do. I shelved the first project because, while it would work, the number of people who could construct one if desired was quite limited. This is partof my definition of Open. That a standard platform should be able to be constructed by as many sources as possible.
This eliminates lock-in and most of the other evils of proprietary hardware.
I have searched for ways to standardize on a list of requirements, for example, should be as compatible with a PC as possible, should be practical for users to add different modules, should have the widest possible range of options for automation, etc. It should use no parts that are single sourced or not widely available. It should be understandable by anyone who has a hope of contributing or expanding on the idea.
The original concept was to build a backplane with a SOC PC on it and a simple bus for plugin modules. The backplane and the modules are cool and can be done by almost anyone, the SOC part is not. It requires a large investment to be able to handle surface mount components and the processors are single source. The other factor in the death of this idea is that it's not possible for me to actually build one out of pocket. The fieldbus modules are simply not doable by individuals or our OSS project, in most cases requiring big bucks licensing or at best
encumbering our work with patent issues, etc.
So I had that on the back burner till last weekend when Greg from Chiron Consulting mailed me an article about Open IP for integrated
circuits. I'd already seen the article but as we chatted a bit about Open Hardware, a bunch of things clicked together about a way to make a decent system for PC automation with the least amount of reinventing the wheel. I've checked out a few things and it looks pretty good.

System description:

System will consist of a backplane board with a PC104 connector for a CPU of your choice. These are available in many flavors from many
vendors. That way I won't simply design another one for vanity. This has many advantages as PC104 modules stack and are available for various industrial protocols. The cpu can be anything from a 486 to pentium or beyond and can have as many bells and whistles as desired. There are
fairly inexpensive ones for basic functionality.
The PC104 bus is in essence the good old standard ISA bus in 8 and 16 bit versions. Use of the PC104 bus is free and Open and the specs are available for free without any legal BS.
Addresing and accessing IO modules on the PC104 bus would require that each have decoding and address setting jumpers and that would take space and require setup. Instead circuitry on the backplane (glue logic) will look like a single ISA card and do the decoding and and slot selection for 8 slots initially. Each slot will own 4 addresses or 32 bytes with the 8 bit bus. This allows the backplane to be simply an 8 bit bus with slot selects and 2 address lines. This buss will extend to pin headers set at regular intervals for the modules to plug into. The data bus and address lines will be buffered. This arrangement means that a plug in module need only have a register and the optoisolators plus resistors for an input card, adding a driver IC for an output card. 32 bits for each slot means it's easy to have a 16 bit DAC or ADC module with registers for control bits and such. All of this can be well understood and will be well documented so that anyone can add a custom module or special function with tools freely available for Linux. The discrete IO will be very close to that which I designed for the TTL to industrial level translator published earlier. Since I built those for about $3.00 a point, this should accomplish the same price point with optoisolation and .5 amp outputs standard. This will use a single driver that will be about as simple as any driver can be and would also be usable with direct access from almost any language that can read and write from a memory location. I would see to it that there is at least an OSS driver for Linux.

Complex functions like networking are much better handled with modules stacked on the PC104 bus. This means that servo cards and the like
can be serviced at high speed with no fixed relationship to scan time. Many types of PC104 modules are available including some popular
industrial fieldbus protocols thus avoiding the whole IP issue and creating our own standard.

All of this can be accomplished using widely available parts from DigiKey or Jameco or even Radio Shack. By limiting the scope of the project, it can be done on a simple two layer board using the published (GPL) artwork. For those who would prefer not to make their own, bare boards, kits or assembled units could be made available. I may even do this if there is enough interest The cost is low enough for me to build and use in qty one.

The packaging is still a headache. It takes a substantial volume to make tooling costs reasonable for a nice PLC like enclosure. We have a plastic molding house next door and I will make inquiries. Best deal would be if they wanted to make a product out of it and people could buy it directly from them. Because of the regular dimensions, all that is required amounts to a box with card guides that line up with the headers. For the prototype I can build a box out of plexiglas with woodworking tools.

This is my concept for a low cost standard PLC form factor PC automation platform. The elegance and beauty of this approach is that it takes what is already available as commodities and adds only what is special to the automation market and does it in the most accessable, least costly way while maintaining industrial standards in common use.

Regards

cww
_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org http://lists.linuxplc.org/mailman/listinfo/linuxplc


Posted by Thomas B. O'Hanlan on 1 February, 2002 - 5:00 pm
Curt, looks good. i was/am a charter member of the PC/104 consortium. let me bounce this around my group and get comments. Keep it up, Tom O'Hanlan Pres/CEO Sealevel Systems, Inc. www.sealevel.com

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org http://lists.linuxplc.org/mailman/listinfo/linuxplc


Posted by Curt Wuollet on 4 February, 2002 - 9:43 am
Hi Tom

I'd be interested in what they have to say. My day job employer has waived interest in this so I am doing this out of pocket. If someone could loan me a PC104 cpu that already runs Linux for development use it would help also. Most that already have Linux ports are kinda spendy and the Linux consulting business in rural MN has been bleak lately. Please give the members of the consortium my thanks for providing an Open Standard as a basis on terms that are encouraging rather than exclusionary.

Well, back to xcircuit and PCB.

Regards

cww
--
Free Tools!
Machine Automation Tools (LinuxPLC) Free, Truly Open & Publicly Owned Industrial Automation Software For Linux. mat.sourceforge.net.
Day Job: Heartland Engineering, Automation & ATE for Automotive Rebuilders.
Consultancy: Wide Open Technologies: Moving Business & Automation to Linux. _______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org http://lists.linuxplc.org/mailman/listinfo/linuxplc


Posted by Ken Wood on 4 February, 2002 - 9:40 am
>The packaging is still a headache. It takes a substantial volume to
>make tooling costs reasonable for a nice PLC like enclosure. We have a
>plastic molding house next door and I will make inquiries


some reasons why PLC's and the like don't really need a case...
visit www.tri-plc.com
visit www.tern.com

Tooling (plastic molds) can be $15,000-50,000+ per molded part, with $2000-$4000 for every future modification.
how many pieces will this enclosure be made from? Enclosure front, Enclosure back, Enclosure latch for rail mount?...

Maybe an "off the shelf" enclosure will do the trick. (digikey or newark?)

If you could send me information on:
What your hardware would look like.
What type of external mount you would use.
What types of connnections are needed.
What the sales numbers would be over the next few years.

I might be able to recommend a path and some ideas.


Ken Wood
_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org http://lists.linuxplc.org/mailman/listinfo/linuxplc


Posted by Curt Wuollet on 4 February, 2002 - 9:41 am
Thank you Ken

It will be a while as the dimensions will be determined by the space required for the most complex module. I will be using through hole components to simplify construction. I will stick to 2 layer boards as these can be made inexpensively in short order from any number of PC fab houses and assembled by people. PCB (the free board layout
software for Linux) doesn't have an autorouter so there's an element of cut and try involved. They will be somewhat larger than absolutely neccessary as my design rules for industrial boards use wide spacing to tolerate dirty environments without conformal coatings. A simple coat of spray acrylic should do. I have thought about a sheet metal enclosure that could be fabricated on demand locally. This would
require little or no tooling cost. A lot of physical detail is still up in the air, but I have the electronics thought through. The discrete IO I did has been running reliably for quite a while so the design rules seem reasonable.

Regards

cww
--
Free Tools!
Machine Automation Tools (LinuxPLC) Free, Truly Open & Publicly Owned Industrial Automation Software For Linux. mat.sourceforge.net.
Day Job: Heartland Engineering, Automation & ATE for Automotive Rebuilders.
Consultancy: Wide Open Technologies: Moving Business & Automation to Linux. _______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org http://lists.linuxplc.org/mailman/listinfo/linuxplc


Posted by Ken Emmons on 4 February, 2002 - 4:24 pm
Hello Curt,

I read your description about open hardware and I have to agree with your statements. I have been coming down to similar deductions based on my dealings with our system at my day job. We are now using 3U compact PCI stuff, and it is really really nice, but god awful expensive!!! I'd like to fit into an all in one ISA based solution if we could. The ISA stuff initially scared me off at first because ISA is seen in the PC industry as dying off, yet in your SOC and CPU module markets you almost always see a full ISA implementation. Is ISA somehting we can count on in the semi-long term future?? I hope so, since PCI is overly complex for automation tasks. Well, you could easily implement a PCI to ISA bridge (PLX makes sucha chip) and put that on your CPU module if everyone stops making ISA bus.

There are a few interesting points to make. I think there should be no active parts on the backplane. Reliability and troubleshooitng is in question here. I have done both ways in the past and passive is the way to go I think. This would mean that you have an ID to set. I don't think this is such a bad thing if in your standard you simply define soem kind of DIP and/OR hex coded switch interface that would be consistant. I think most people are happy with settinng an ID on the board. Look at devicenet for instance. Heck, some of the PLCs I have used make you key in a dip switch for expansion modules.

So now you have a strictly ISA passive backplane with some kind of CPU and IO modules you plug into it. You could have a bare "routing" board that converts this form factor to other, non-pluggable form factors like PC-104, or somethign like the advantech pluggable CPU modules (forgetting the name but nice looking stuff). It is still electrically ISA and therefore good enough for almost all automation tasks and certainly for ease of software development. We might as well get rid of legacy crap like the -5V requirement and such .. 5V, +/- 12V is good enough. Most PC-104 and such are all 5V driven I think. HAving a standardized interface to Battery backed RAM (Another plug in module, essentially) would be a killer enhancement, since it is something everyone needs but few seem to provide or talk about.

You mentioned packaging as a problem and I agree with you 100%. In fact, packaging is far more complicated than the electrical and programming when you start talking about low quantity usage, etc. I think there is a simple solution, however. Using the Eurocard 3U standard (I.e. the smaller version of the VME style enclosure) is the way to go. There is so much hardware available for these things it is insane. ITs about the size of a PLC (well, not counting the micro tiny PLC's like keyence, etc). I even think there is an ISA backplane specification for a system such as this. So while I think it is great to have open hardware, I think it will be a lot easier if we could springboard off of these existing technologies (It would help PR and acceptance as well). 3U eurocard is big enough to lump on a PC104 computer as well as the System on Module boards and perhaps even the smaller biscuit PC's. I guess my point is that using ISA as the common denominator, you could standardize on the rest of your controller while designing new CPU carrier-interface boards witht he changes in technology.

As far as packaging I also think we would need to ammend a connector spec. find some kind of connector system on the fornt that offers both cage clamp and screw terminal (I prefer cage clamp, but everyone has their own philosophy on this), in flavors of 16 and 32 conductors. While we are at it we could spec a layout for a mass termination cable for special IO boards (Hmm, servo??). I don't wnat to get too crazy here, but at least some general IO connectors would be cool.

I have been havign problems with my PCI based IO system and there is just so much complexity there that I think I should not have to go through to set a few memory values (I have six 16 bit memory bits corresponding to IO). I look forward tot he day when I can use a decent memory bus and actually plug a regular logic analyser into the backplane. Oh, and have soem IO boards made in bulk, with open artwork, for a cheap price. Lets face it, IO boards shouldn't cost $100-$1000. What a concept!! :o)

So are we thinking the same kinds of things here?? What do you think of my points??

~Ken
_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org http://lists.linuxplc.org/mailman/listinfo/linuxplc


Posted by Peter Wurmsdobler on 5 February, 2002 - 10:33 am
Hello Ken,

> ... ISA somehting we can count on in the semi-long term future??
> I hope so, since PCI is overly complex for automation tasks. ..

Under Linux I programmed drivers to be used in RTLinux. Result: PCI is nicer to program, you don't have to care about IRQ and io addresse setup. You can get it from the kernel structure. However, ISA gave slower, but more predictible performance
on a 486, pure ISA, than a PIII PCI. Most ISA boards for DAQ
I wored with can be easily programmed on a register level, so it is very deterministic if you write to a port to start a DAC and to get the value. on PCI devices, you talk in most cases to the a PIC, which is after the PCI chip, so you don't know what happens. E.G.: ADC on a PLC818 takes 10usec, on a 486 triggering an ADC up to the time the value avcailable takes 18usec. On a PCI system with an ICPDAS 1800, programming the channel, gain etc, trigger an AC, get the value took me 33usec.

Concerning ease of use, I like the cPCI system, but as you already mentioned, it is very expensive (in comparison to the PCi counter parts which contain in most cases the same funtionality, but due to the low producation number, cost a lot. If PC104 had only the connector twisted by 90 degree such that it could be plugged into a passive backplane. Sometimes I think I just make such a backplane, and use sone 90 degree middle piece.

But whatr do you guys think about a software architecture, about protocols between control components, etc...

just to add my 2 cents,
peter
--
Peter Wurmsdobler
Control.com Inc.
508-621-3611 fon
508-621-3614 fax _______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org http://lists.linuxplc.org/mailman/listinfo/linuxplc



Posted by Curt Wuollet on 5 February, 2002 - 10:43 am
Hi Peter.

This is a spec for a PLC form factor, PLC compatible, PLC cost competitive machine that will do mostly discrete IO and PLC grade A/D and D/A. It will also handle anything you can get in a PC104 module. With no GUI, a fanless industrial grade CPU of modest horsepower will provide superior performance to most PLC families. If I were to do serious data acquisition, ffts, vibration analysis, 6 axis robots or the like, I would simply choose a more PC like platform of which there are many. I am looking at a total cost of less than what I pay for a PCI data acquisition card for my ATE. This is aimed squarely at providing superior economics to using PLCs and avoiding the PC stigma by being similar in design and execution to "industrial Equipment". For high end applications, there are many ISA and PCI backplane systems and no particular reason for me to design another. I believe this is what you and Ken are thinking about to some extent. This would be economic as
a remote IO rack or perhaps even a micro PLC replacement yet would provide up to 256 points of digital IO. This is something that is missing for PC type automation or obtainable only at
obscene expense. The "Industrial PC" form factor is already well covered. We can scale from micro to mainframe but can't compete with PLCs one for one on a cost basis without this type of
hardware. That's the concept. Does it make sense?

Regards

cww

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org http://lists.linuxplc.org/mailman/listinfo/linuxplc


Posted by Peter Wurmsdobler on 11 February, 2002 - 11:44 am
Curt,

> This is a spec for a PLC form factor, PLC compatible, PLC cost
> competitive machine that will do mostly discrete IO and PLC grade A/D
> and D/A. It will also handle anything you can get in a PC104 module.
> With no GUI, a fanless industrial grade CPU of modest horsepower will
> provide superior performance to most PLC families.

I totally agree with you. Any fancy computation can be done on cPCI or PCI architecture, which costs much mor and might be an overshoot in may cases. What could be suficcient is a single PC104 CPU board with one additional board providing either a couple of digital io points or rather a devicenet/ethernet or whatever network io board. You can put this in a half-a-brick enclosure, put Linux on it, and on top a run time system executing PLC code. peter
--
Peter Wurmsdobler
Control.com Inc.
508-621-3611 fon
508-621-3614 fax _______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org http://lists.linuxplc.org/mailman/listinfo/linuxplc


Posted by Curt Wuollet on 11 February, 2002 - 12:56 pm
Hi Peter

And the part that a lot of folks seem to be missing is that my bus is strictly for running PLC style IO, in limited quantities. With all but the more basic CPU cards you have the option of PC104-plus which is a PCI spec addition to the ISA like PC104. So you can run very high speed modules by simply stacking them on top of the CPU. This gives you very good capabilities in a
PLC form factor package. You aren't really giving up anything if the "PLC" bus is downsized to suit cost and purpose. And of course, our favorite 10/100mb. Ethernet is usually integrated into the CPU and not hobbled by either of the
expansion busses. All I'm doing is providing the
"standard equipment" to be used like a PLC at PLC speeds.

Regards.

cww

PS I wonder how Jiri's doing?

--
Free Tools!
Machine Automation Tools (LinuxPLC) Free, Truly Open & Publicly Owned Industrial Automation Software For Linux. mat.sourceforge.net.
Day Job: Heartland Engineering, Automation & ATE for Automotive Rebuilders.
Consultancy: Wide Open Technologies: Moving Business & Automation to Linux. _______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org http://lists.linuxplc.org/mailman/listinfo/linuxplc


Posted by Curt Wuollet on 11 February, 2002 - 1:33 pm
Hi Peter

I like the backplane idea rather than stacking IO on the PC104. It lets us run a substantial IO count at lower cost than stackable modules. And it gives about the same IO count granularity that PLC users expect. ie plugins of 8 or 16 inputs or outputs or perhaps two analog. The modules can be very simple and inexpensive. An 8 input module could have for example: 74HC register @50 cents 2 quad bidirectional optoisolators @$ 4.00 each. resistors at negligable cost and connectors of your choice. The board blanks will be small and cheap in quantity. This is verses more than $100.00 for any kind of PC104 module. That's why I'm doing the backplane. There's simply no point in doing another outragiously expensive platform, that area is well covered.

Regards

cww
_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org http://lists.linuxplc.org/mailman/listinfo/linuxplc


Posted by Peter Wurmsdobler on 15 February, 2002 - 12:39 pm
Curt,

> I like the backplane idea rather than stacking IO on the PC104.<

Maybe it sounds weird, but would it be possible to make a backplane with PC104 like connectors and a 90degree intermediate piece for commercially available boards.::

peter
--
Peter Wurmsdobler
Control.com Inc.
508-621-3611 fon
508-621-3614 fax
_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://lists.linuxplc.org/mailman/listinfo/linuxplc


Posted by Curt Wuollet on 5 February, 2002 - 10:36 am
Hi Ken

"Ken Emmons, Jr." wrote:
>
> Hello Curt,
>
> I read your description about open hardware and I have to agree with
> your statements. I have been coming down to similar deductions based
> on my dealings with our system at my day job. We are now using 3U
> compact PCI stuff, and it is really really nice, but god awful
> expensive!!! I'd like to fit into an all in one ISA based solution if
> we could. The ISA stuff initially scared me off at first because ISA
> is seen in the PC industry as dying off, yet in your SOC and CPU
> module markets you almost always see a full ISA implementation. Is ISA
> somehting we can count on in the semi-long term future?? I hope so,
> since PCI is overly complex for automation tasks. Well, you could
> easily implement a PCI to ISA bridge (PLX makes sucha chip) and put
> that on your CPU module if everyone stops making ISA bus.

That's one of the reasons for using PC104 SBCs. PC104 is built around the ISA bus adapted to the pin header layout. Some PC104 products offer other busess but they all work with the ISA signals on the pin header bus. Thus, by using PC104 products we are guaranteed a continuance of the standard. So when the doupoly manages to kill ISA, nothing changes for us. If we limit the backplane to scanned IO, there is simply no need to go to PCI or CPCI or whatever the duoploy and friends are pushing to get us all to buy new hardware as frequently as possible. Complex functions can be handled by the full PC104 and PC104 plus by simply stacking these on top of the CPU. It's kinda the best of both worlds. We get a solid, manageable, easy to understand and use bus for the basic automation stuff and we can buy off the shelf modules for fieldbus and functions it doesn't make sense for us to make.

> There are a few interesting points to make. I think there should be no
> active parts on the backplane. Reliability and troubleshooitng is in
> question here. I have done both ways in the past and passive is the
> way to go I think. This would mean that you have an ID to set. I don't
> think this is such a bad thing if in your standard you simply define
> soem kind of DIP and/OR hex coded switch interface that would be
> consistant. I think most people are happy with settinng an ID on the
> board. Look at devicenet for instance. Heck, some of the PLCs I have
> used make you key in a dip switch for expansion modules.
>
> So now you have a strictly ISA passive backplane with some kind of CPU
> and IO modules you plug into it. You could have a bare "routing" board
> that converts this form factor to other, non-pluggable form factors
> like PC-104, or somethign like the advantech pluggable CPU modules
> (forgetting the name but nice looking stuff). It is still electrically
> ISA and therefore good enough for almost all automation tasks and
> certainly for ease of software development. We might as well get rid
> of legacy crap like the -5V requirement and such .. 5V, +/- 12V is
> good enough. Most PC-104 and such are all 5V driven I think. HAving a
> standardized interface to Battery backed RAM (Another plug in module,
> essentially) would be a killer enhancement, since it is something
> everyone needs but few seem to provide or talk about.

Battery backed ram is an option on some PC104 CPUs already. I'm with you as far as ISA being a desirable backplane except for three items,
complexity, cost, and size. ISA is well understood, but way beyond what we need to run a rack full of IO. It is expensive to implement in low volumes and suffers from a lot of headaches like finding X number of open addresses to put cards in. Decoding addresses once and using slot selects solves this problem to a great extent, especially with a slot register. We then only need one five byte window in the crowded ISA hardware address space. The bus I propose will only need about 24 lines including spares. This makes connectors cheap and small and interfacing about as easy as it can be made. No muxed data or addresses, no mysterious signals, just read or write a byte when the your select is true. This makes IO modules extremely simple and straightforward and the backplane itself low tech enough to be fabricated locally in low volumes at any proto PCB house. Using pin headers, you don't need gold edge connectors or fancy retention and your modules can be small and light and simple enough that users can add their own if desired.

> You mentioned packaging as a problem and I agree with you 100%. In
> fact, packaging is far more complicated than the electrical and programming when you start talking about low quantity usage, etc. I think there is a simple solution, however. Using the Eurocard 3U standard (I.e. the smaller version of the VME style enclosure) is the way to go. There is so much hardware available for these things it is insane. ITs about the size of a PLC (well, not counting the micro tiny PLC's like keyence, etc). I even think there is an ISA backplane specification for a system such as this. So while I think it is great to have open hardware, I think it will be a lot easier if we could springboard off of these existing technologies (It would help PR and acceptance as well). 3U eurocard is big enough to lump on a PC104 computer as well as the System on Module boards and perhaps even the smaller biscuit PC's. I guess my point is that using ISA as the common denominator, you could standardize !
on the
> rest of your controller while designing new CPU carrier-interface
> boards witht he changes in technology.

Again, cost and availability. I want DigiKey and Jameco to stock all the repair parts needed. I can get pin headers and sockets locally. I've spent enough time and money chasing down "special" automation bits and pieces to have done this project several times over. And if I never pay $ 100.00 for a "special" ribbon cable connector again, it'll be too soon. The only reason I would empt for non commodity pieces is if there is a valid engineering problem that requires something special. Right now I don't see any.

> As far as packaging I also think we would need to ammend a connector
> spec. find some kind of connector system on the fornt that offers both
> cage clamp and screw terminal (I prefer cage clamp, but everyone has
> their own philosophy on this), in flavors of 16 and 32 conductors.
> While we are at it we could spec a layout for a mass termination cable
> for special IO boards (Hmm, servo??). I don't wnat to get too crazy
> here, but at least some general IO connectors would be cool.

I tend towards the familiar blue captive screw wire connectors. I can get these that are pluggable as well so you can replace a module without disturbing all your connections. The beauty of this thing is that you can add modules that use Phoenix connectors if that's your thing or even Wago style spring connectors. For high density, I'd use angle pin headers and standard ribbon cable and connectors out to the terminal blocks of your choice. Special is a dirty word when it breaks.

> I have been havign problems with my PCI based IO system and there is
> just so much complexity there that I think I should not have to go
> through to set a few memory values (I have six 16 bit memory bits
> corresponding to IO). I look forward tot he day when I can use a
> decent memory bus and actually plug a regular logic analyser into the
> backplane. Oh, and have soem IO boards made in bulk, with open
> artwork, for a cheap price. Lets face it, IO boards shouldn't cost
> $100-$1000. What a concept!! :o)

Like I say, look at what you can get in bulk from any electronics house and the good ideas from commodity products and boards simple enough to build yourself. That's the way it ought to be. If you look at the IO I did for 8255 cards, $3.00 a point is on the high side with optoisolation. And I simply can't find any big advantages for the high buck stuff. They don't have any more or much different electronics.

> So are we thinking the same kinds of things here?? What do you think
> of my points??

Good points, what do you think of mine?

Regards

cww

--
Free Tools!
Machine Automation Tools (LinuxPLC) Free, Truly Open & Publicly Owned Industrial Automation Software For Linux. mat.sourceforge.net.
Day Job: Heartland Engineering, Automation & ATE for Automotive Rebuilders.
Consultancy: Wide Open Technologies: Moving Business & Automation to Linux. _______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org http://lists.linuxplc.org/mailman/listinfo/linuxplc


Posted by Kipton Moravec on 5 February, 2002 - 10:37 am
I am currently designing the first board in a series of boards that I plan to use with Linux and the Linux PLC project.

I am taking a different approach. In the systems I am controlling a 8051 processor is more than adequate. The control is relatively slow, as things change slowly.

The approach we are taking is to have the I/O on a 8051 board, and communicate the I/O over 10 base T Ethernet to a Linux box using IP. Most
of the control will be in the Linux Box as my customer still wants to program it in Ladder Logic. This way we can have I/O all over the plant and they use the existing network. Using just IP means that it will not go through a router, and that prevents someone accidentally communicating to the I/O board.

The board will be a mix of surface mount and through-hole as most of the chips will be surface mount, but all of the connectors are through-hole.

To meet my customers requirements, the first board will have
16 switch inputs (discrete switches)
16 5V (TTL type) logic inputs (Pulled up to 5 V with 10K Ohm Resistor) 16 24V digital inputs 16 optical isolated inputs 16 LED outputs (We normally have membrane switches for the front panel with LED indicators) 16 Solenoid outputs 16 Relay (dry contacts) outputs.
4 4-20 mA inputs
2 4-20 mA Outputs
1 Digital Temperature Sensor (On the board)
1 LCD display interface (1 to 4 line character LCD)

An expansion port for future expansion

Another feature this board has is an EMO relay. If the Relay looses power because the EMO switch is pushed in, all power to the solenoids is removed. This is a mechanical relay, which is required for safety for these units. It is independent of what the processor is doing, and the processor can not override it.

Our unit will use mostly the 24V digital inputs and Solenoid outputs. The dry contacts are for outputs to other machines or indicators. The opto-isolated inputs are for signals from other machines. The switch inputs and LED switches are for a membrane switch. The 5V logic inputs are for other discrete switches on the front panel. (Key switch, door closed, etc.)

The goal is to sell the assembled board for less than $300. It will depend on the volume. We can probably hit it with 100 boards.

The other thing is we don't have to populate the whole board. If you don't want 4-20 mA we will build it without those parts. Or if you don't need the relays, we will build the board without them.

Kip

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org http://lists.linuxplc.org/mailman/listinfo/linuxplc


Posted by Curt Wuollet on 5 February, 2002 - 11:32 am
Hi Kipton

That sounds great too. Yours is kinda closer to the RTU concept if I'm reading it right. No one solution will answer all situations. I want a box that goes head to head with PLCs in a single box configuration. Yet at the same time can be built out with a fast CPU, video, etc to be the controller for a factory full of ethernet connected remote IO with a IDE or SCSI RAID database. Linux on all the nodes will make it very versatile and capable of handling
distributed tasks as well. There are $200.00 cpus for a remote rack or micro PLC replacement and $1000.00 cpus that offer a fully stuffed PC for SCADA and process control applications. That's the concept.

Regards

cww

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org http://lists.linuxplc.org/mailman/listinfo/linuxplc


Posted by Peter Wurmsdobler on 11 February, 2002 - 11:41 am
Kipton,

> The approach we are taking is to have the I/O on a 8051 board, and
> communicate the I/O over 10 base T Ethernet to a Linux box using IP.

This sounds great. How will the linux box get i/o information on IP? Could you give me a sort of c-code example, how the linux box could quesry and set remote io?
FYI: "http://www.sixnetio.com/special_index_pages/index_linux_ipm.html ":http://www.sixnetio.com/special_index_pages/index_linux_ipm.html

will acomplish a similar job.
peter
--
Peter Wurmsdobler
Control.com Inc.
508-621-3611 fon
508-621-3614 fax _______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org http://lists.linuxplc.org/mailman/listinfo/linuxplc


Posted by Kipton Moravec on 11 February, 2002 - 1:05 pm
We are not that far yet. I am meeting with my partner tomorrow (Sunday) maybe I can have an answer for you then.

Let me not speculate on the exact calls until I talk to my partner.

To keep it simple I think you ask for the status, and it will dump all the inputs in one burst. (There is not that many bytes total.) To write you do the same thing, one structure for all of the outputs. Again not so many bytes. I am guessing 20 bytes. It keeps the number of packets transmitted and received low. We will provide a Linux driver that you call from C with the MAC address of the unit for straight IP (non routing), or the IP address if you want a routable TCP/IP address.

At the moment I think you will configure it initially via RS-232 and a terminal program. The parameters will be stored in EEPROM.

These things could change as everything is very fluid at this time. I expect things will be more locked down in a couple of weeks.

Kip
_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org http://lists.linuxplc.org/mailman/listinfo/linuxplc


Posted by Peter Wurmsdobler on 11 February, 2002 - 1:11 pm
Kipton,

> To keep it simple I think you ask for the status, and it will dump all
> the inputs in one burst. (There is not that many bytes total.) To
> write you do the same thing, one structure for all of the outputs.

This sounds simple, straight and predictible. Given your remote io is on an ethernet segment, once could integrate in a potential PLC run time
system a call read (IP,*image) and write (IP,&image) read from the device and a write to the device, respectively. How to set it up? Could the PLC query in the sense : tell me what you have! or does the PLC have to know the remote i/o in advance?
peter
--
Peter Wurmsdobler
Control.com Inc.
508-621-3611 fon
508-621-3614 fax _______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org http://lists.linuxplc.org/mailman/listinfo/linuxplc


Posted by Kipton Moravec on 11 February, 2002 - 1:14 pm
Right now we have one customer with one very specific board for controlling the flow of dangerous chemicals.

However, I see this as being a family of boards, It would be nice to have
a unit with a bunch of digital I/O and some 4-20 mA inputs and outputs too. I think each board type will have a unique identifier, so you can lookup the structure based on the board type.

I have been toying with the idea of offering a web socket for TCP/IP enabled ones, so you can see it from your web browser. This will help confirm it is online, and you can make sure the data you get from your PLC was interpreted correctly

The PLC will have to know the remote I/O anyway, whether I tell it to you or not. You will have to map devices in the PLC to the I/O somewhere. My digital input #1 has to get mapped to say "Manifold Solenoid Status" depending on what you wire to that input.

Even if I told you I have 16 digital I/O that does not mean they are hooked to anything, you still have to know which ones are hooked up.

The first board will also have a LCD display interface, so you can display messages on the remote control panel. For example, the unit has a 4-20 mA pressure gauge, the current is read by the unit, it sends the data to the PLC, the PLC can choose how to interpret the signal, and then what to display. You may want to display the pressure reading, or a message like "Low Pressure".

Kip

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org http://lists.linuxplc.org/mailman/listinfo/linuxplc


Posted by Gary James on 5 February, 2002 - 10:40 am
On Mon, 04 Feb 2002 23:31:45 Curt Wuollet wrote:
> Hi Ken
>
> "Ken Emmons, Jr." wrote:
> >
> > Hello Curt,
> >
> > I read your description about open hardware and I have to agree with
> your statements. I have been coming down to similar deductions based
> on
...
>
> That's one of the reasons for using PC104 SBCs. PC104 is built around
> the ISA bus adapted to the pin header layout. Some PC104 products
> offer other busess but they all work with the ISA signals on the pin
> header
bus.
> Thus, by using PC104 products we are guaranteed a continuance of the
> standard. So when the doupoly manages to kill ISA, nothing changes for
> us. If we limit the backplane to scanned IO, there is simply no need to
> go to PCI or CPCI or whatever the duoploy and friends are pushing to get
> us all to buy new hardware as frequently as possible.

I hate to throw water on the fire but one thing scares me about basing a new product base on PC-104 (ISA) bus. For the most part you are reliant on silicon vendors to make hardware that interfaces with the ISA bus for complex hardware (ie. CPU to ISA interface, Ethernet, Video, etc). Once the ISA bus goes away, so will the silicon that directly interfaces with it.

I just received notice of last time buy on AMD lance ethernet chips with the ISA bus interface built in. All AMD wants to make now (IMHO) are Ethernet chips with PCI interface logic built in. I expect you will see the same thing start to happen with video chips, etc.

I also recently received a "not recommended for new design" notice from a PC-104 board vendor. Seems that the 586 board that we have been buying from them is going obsolete, since they can no longer buy the intgrated VGA chip. The sales girl also hinted that their version without integrated VGA will soon be going obsolete since another chip (I can't remember which one) is going out of production.

There is not enough market in the PC-104 / ISA arena to keep the silicon rolling for much longer!

Although not a perfect solution, one thing that you might want to consider is a compact flash interface. It is similar to ISA (memory mapped, only 1 interrupt source though). One nice thing about the compact flash interface is that it's still easy to interface to like ISA. Also it is newer, and still has a lot of momentum due to the handheld market. The LART board (open hardware) has such an interface (I think), as does iPAQ and similar StrongARM boards from Applied Data Systems (www.applieddata.net) and others. I am using an ADS board right now with a compact flash ethernet adaptor.

Anyway, I just wanted to give my 2 cents to the discussion.

--
Gary James
gjames@twcny.rr.com
http://home.twcny.rr.com/embedded/

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org http://lists.linuxplc.org/mailman/listinfo/linuxplc


Posted by Curt Wuollet on 5 February, 2002 - 1:17 pm
Hi Gary

Gary James wrote:
>
> On Mon, 04 Feb 2002 23:31:45 Curt Wuollet wrote:
> > Hi Ken
> >
> > "Ken Emmons, Jr." wrote:
> > >
> > > Hello Curt,
> > >
> > > I read your description about open hardware and I have to agree
> > > with
> > your statements. I have been coming down to similar deductions based
> > on
> ...
> >
> > That's one of the reasons for using PC104 SBCs. PC104 is built
> > around the ISA bus adapted to the pin header layout. Some PC104
> > products offer other busess but they all work with the ISA signals
> > on the pin header
> bus.
> > Thus, by using PC104 products we are guaranteed a continuance of the
> > standard. So when the doupoly manages to kill ISA, nothing changes
> > for us. If we limit the backplane to scanned IO, there is simply no
> > need to go to PCI or CPCI or whatever the duoploy and friends are
> > pushing to get us all to buy new hardware as frequently as possible.
>
> I hate to throw water on the fire but one thing scares me about basing
> a new product base on PC-104 (ISA) bus. For the most part you are
> reliant on silicon vendors to make hardware that interfaces with the
> ISA bus for complex hardware (ie. CPU to ISA interface, Ethernet,
> Video, etc). Once the ISA bus goes away, so will the silicon that
> directly interfaces with it.

Perhaps, but we have more leverage than striking out on our own and there will always be some sort of simpler, inexpensive solution for embedded use. Really, my point is that to compete with the PLC hardware which is a class of embedded hardware, we need to align more closely to the embedded market than the PC market. PCs are vast overkill for most of these applications, that much hardware is only competitive due to he enormous volumes. I like PCs, I use PCs, I build ATE on PCs, but a PCI DAQ card costs more that the whole system I am proposing. Without a competitive platform, we are going to be relegated to the same esoteric market as AutomationX. We
can do that market, but there's not enough volume in doing only that market for us to standardize anything. So, if PC104 goes away. we simply keep our bus and modules and redesign the backplane to fit whatever takes it's place. There will always be something in that slot between PC's and "deeply embedded" platforms. All that frenetic embedded Linux activity is going to run on something. I want to keep the scope down to what is
special to automation.

>
> I just received notice of last time buy on AMD lance ethernet chips
> with the ISA bus interface built in. All AMD wants to make now (IMHO)
> are Ethernet chips with PCI interface logic built in. I expect you
> will see the same thing start to happen with video chips, etc.

Agree, but ethernet is best left as the SBC vendors problem. If you need ethernet get a proc module with it integrated. This will be the salvation for many of the issues you mention, If they integrate these functions into the SOC chip or chipset they use to build the board, we don't much care how they do it.

>
> I also recently received a "not recommended for new design" notice
> from a PC-104 board vendor. Seems that the 586 board that we have been
> buying from them is going obsolete, since they can no longer buy the
> intgrated VGA chip. The sales girl also hinted that their version
> without integrated VGA will soon be going obsolete since another chip
> (I can't remember which one) is going out of production.

But at the same time SOC vendors are integrating video into the SOC. We let them solve this problem too. ISA and PC104 are important enough in the embedded market for the same reasons I'm using it that there will be a compatible plug for quite a while. It adds very little to a SOC to
maintain compatibility. The only reason I'm interested in the non-SOC designs is that they are cheaper at present.
>
> There is not enough market in the PC-104 / ISA arena to keep the
> silicon rolling for much longer!

But the volume is going up enough in the SOC market that they are making silicon that does all these things on chip. I agree that many existing designs wil be obsoleted but the SOC guys are content with this smaller market and will move into the chip and wire territory. The MachZ is a
brand new SOC design that includes an ISA/PC104 interface. And it boots Linux from the get go. Embedded is a tiny niche for the PC silicon guys but, it's the whole market for SOC.
>
> Although not a perfect solution, one thing that you might want to
> consider is a compact flash interface. It is similar to ISA (memory
> mapped, only 1 interrupt source though). One nice thing about the
> compact flash interface is that it's still easy to interface to like
> ISA. Also it is newer, and still has a lot of momentum due to the
> handheld market. The LART board (open hardware) has such an interface
> (I think), as does iPAQ and similar StrongARM boards from Applied Data
> Systems (www.applieddata.net) and others. I am using an ADS board
> right now with a compact flash ethernet adaptor.

Certainly worth a look. Another design goal is to reinvent as little as
possible. Not to mention it's a lot less work.
>
> Anyway, I just wanted to give my 2 cents to the discussion.
>
And it's greatly appreciated. It really helps me make sure I've got all the bases covered. In my present situation there aren't any hardware guys around to bounce things off of. It would be a great thing if you can stump me before I send the gerbers.

Regards

cww
_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org http://lists.linuxplc.org/mailman/listinfo/linuxplc


Posted by Ken Emmons on 5 February, 2002 - 1:45 pm
Curt,

I don't know why you say that 32 contiguous bytes are hard to come by. Every ISA board I have used has at least mulktiple kilobytes of unused lower memory (in the sub 16MB). For instance, one board has E0000 - EFFFF (32K) that I am using for a NVRAM. Other boards I am using 4K chunks for IO boards on the bus. I don't know who it was that determines ISA space is heavily used, but usually a manufacturers datasheet of the computer is the best. DOS tools give you false info since DOS uses this memory area for certain things.

You seem to be amking an argument that ISA is expensive. I don't know where this comes from since you can buy everythign I am talking about at digikey for cheap money. a 96 pin VME style connector is commodity and is $4.46 at digikey ( part H5096-ND). It has everything you need to have in a pluggable system, i.e. screw mounts for mechanical regidity, proper lead in of the connector for alignment issues, etc. I think if you go with low end headers you will pay the price in reliability and ease of use pretty fast.

Bringing the ISA bs to your cards will allow you to have things like battery memory and such regardless of the CPU board you need to use. Of course you can find vendors that offer these features, but that limits you to certain vendors for your boards, which is what we should be trying to eliminate. I dont like the dependance on PC-104 either. Using it as an option is cool, but your system should not depend on it. The choices in high end PC-104 are pretty bad. I really don't like a stackable system for an industrial system because of maintenance issues. Having a PC-104 computer (or some other form factor) on a base-board that then plugs into the bus makes the most sense to me. It splits the road between full off the shelf and full custom.

I think the bigger problem with the ISA approach will be deciding on a mechanism that will allow the IO boards to know of the base address used byt he computer. Using base address jumpers on your IO boards sucks. Obviously you wont need to whole 24 bits of ISA address for your 'n' number of IO cards, so perhaps an ammendment of the ISA spec would be in order that would allow for a "IO system decode" line that would be asserted when the IO subsystem address range was accessed. This would be ralized by your glue logic decodes on the comptuer interface board. Perhaps we could compromise on this one, Curt, and agree to ammend the ISA bus with your idea of decoding for the IO slots. Then you could have a full ISA board, or a simple to build and understand IO board all in the same system. The cost and complexity of doing this is really low.

Peter - As far as difficulty of programming, we are mostly talking about memory mapped polled IO. No IRQ's really. I have done PCI programming with RTlinux as well and it is pretty nice, you are right :o)

I think we are thinking the same thing as far as IO connectors. Pluggable is good, and if you can mix and match Wago and phoenix, that is even better.

Nobody mentioned anything about the idea of using a 3U VME style card cage. How does this sound??

I think that some diagrams could help break the barrier for some things here. Is there a good way to post a pdf or soemthing to this list??

~Ken

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org http://lists.linuxplc.org/mailman/listinfo/linuxplc


Posted by Curt Wuollet on 6 February, 2002 - 9:36 am
Hi Ken

You kinda missed my point. If you're gonna use ISA cards or PCI cards you can simply get a passive backplane industrial PC. Same for VME, I
believe. And people already make (expensive) processor cards for them. These would be the boxes to use when you need those standards and cards. I'm pretty sure these would run Linux without an issue but they are too spendy to compete with a standalone PLC. The best approach in that area would be to simply design industrial IO cards or translators if TTL cards exist. That was the last project. And I don't want to build computers. What I'm trying to do is design a PLC direct replacement workalike that's din rail mountable in the same space and at an equivalent or superior price point with a PC compatible engine and generic IO cards. We already have small enough x86 SBCs at near commodity prices, we just need to make an IO rack to work with them. By using a simple subset of the PC104 bus the IO cards can be very simple as well. Using standard cards is not an issue as there is no standard and I know of no two PLC plugins that will interchange. In fact, if we did design to use them we would probably get sued. By simplifying, I don't need high density, controlled impedance boards and can use 2 layer boards that are inexpensive even in low quantity. And you can take my artwork and have boards tomorrow.
On the memory issue, that is a different segment of memory. For whatever reason, IBM mapped boards in 218h to 3ffh and then we have the "IO decode range" signal without any extensions in the form of the IOW and IOR already on the bus. These are standards. If I wanted to make a better computer and port Linux to it (which would be entertaining) I can do anything. If I want to run x86 Linux on what works like a PC for simplicity's sake, I need to use the standards. I personally think pin headers are more reliable than edge connectors but probably slightly less so than the expensive two piece designs. A pragmatic compromise. And much easier to find and replace.

Keep asking though, any design decision I can't defend is probably a bad one.

Regards

cww
_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org http://lists.linuxplc.org/mailman/listinfo/linuxplc


Posted by Curt Wuollet on 5 February, 2002 - 10:31 am
UPDATE:

It has come to my attention that 32 bytes of contiguous memory is hard to come by in the low mwmory range used for hardware addresses. This is
a little dissapointing as the simplest possible addressing scheme was a design goal. Fortunately there is a solution that won't add a great deal of complexity and will allow for future expansion. I can shrink the requirement down to 5 addresses by adding a slot register. The change will mean that you write to the slot register to select a slot and then base - base+3 will map to that slot. With a fully decoded 8 bit register we gain expandability to 256 slots at the cost of an extra write per slot.

I'm not getting much feedback. Does any of this make sense? I'd be happy to elaborate.

Regards

Regards

cww
_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org http://lists.linuxplc.org/mailman/listinfo/linuxplc


Posted by Mark Hutton on 8 February, 2002 - 2:09 pm
FYI,

Have you seen the hardware at ZF Micro and Tri-M Engineering?

"http://www.tri-m.com":http://www.tri-m.com
"http://www.zfmicro.com":http://www.zfmicro.com

Regards
Mark Hutton
Software Engineer
e-mail: mark.hutton@plcprogrammer.co.uk
internet: http://www.plcprogrammer.co.uk

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org http://lists.linuxplc.org/mailman/listinfo/linuxplc


Posted by Curt Wuollet on 11 February, 2002 - 11:28 am
HI Mark

Yes, I'm waiting on Tri-M's ICC for a tester project as it has built-in analog and digital. And my first pass at this plc form factor thing was to build a MachZ onto the backlplane. While this isn't ambitious by modern standards, it would be fairly difficult for an individual to do and I had no luck finding a partner with the neccessary equipment. So, the next best thing, which actually has some advantages, is to use a small sbc for the processor and do the backplane with a suitable bus for a rack of IO. Integrating a Machz on the backplane would be cheaper, but being able to take advantage of the array of available PC104 stuff makes the project doable on my own and provides a vehicle for various fieldbus options. SST makes PC104 protocol boards for at least a few of the popular ones. I figure the PC104SBC probably adds $100.00 to the cost for a system over doing my own. But the R&D cost is dramatically less and you can pick the horsepower and features you need. If you like MachZ, check out Diamond Systems Promethius. It has the features of the Tri-M ICC and is shipping now. My concern was that they don't seem to have the grasp on Linux that Tri-M does. I don't communicate very well with Windows pusher^H^H^H^H^H people.

Regards

cww

--
Free Tools!
Machine Automation Tools (LinuxPLC) Free, Truly Open & Publicly Owned Industrial Automation Software For Linux. mat.sourceforge.net.
Day Job: Heartland Engineering, Automation & ATE for Automotive Rebuilders.
Consultancy: Wide Open Technologies: Moving Business & Automation to Linux.

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org http://lists.linuxplc.org/mailman/listinfo/linuxplc


Posted by MMiacca on 5 February, 2002 - 1:18 pm
For years I find for a common hardware and software PLCs.
I think no bus is the best solution for a hardware (PC104).
I/O and CPU systems with serial RS-485 and/or ethernet conections is good, no dimension problems, simple PCBs, no complex conectors. Only the connection and protocol to net need to be standard.

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org http://lists.linuxplc.org/mailman/listinfo/linuxplc


Posted by Curt Wuollet on 5 February, 2002 - 3:57 pm
I agree completely(I think). Unfortunately, people are quite attached to the idea of local IO. Providing IO in the box is where we get into the need for a bus of some sort. My goal is to make it as simple and non-controversial as possible, lowering costs to be in line with the task. Neither the PC104 or the ISA bus are ideal in this role. Neither are the other PC busses. But, we can translate down to what we need with a small number of standard logic chips and buffers. The reason I prefer ISA/PC104 to start with is that they are much simpler and more easily understood than the high bandwidth busses and operate at speeds that are less timing and layout critical, yet more than equal to the task. A backplane that works at ISA speed is much less fussy than one that works at PCI speed. This gives us a lot more freedom in layout.

Regards

cww
_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org http://lists.linuxplc.org/mailman/listinfo/linuxplc


Posted by Peter Wurmsdobler on 11 February, 2002 - 11:39 am
Salute,

> Only the connection and protocol to net need to be standard. <

but which one, not on the transport layer, but the application layer and e.g. a c-library API to access remote io?
peter
--
Peter Wurmsdobler
Control.com Inc.
508-621-3611 fon
508-621-3614 fax _______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org http://lists.linuxplc.org/mailman/listinfo/linuxplc


Posted by Curt Wuollet on 11 February, 2002 - 11:46 am
Hi Peter

It's interesting that there doesn't seem to be a machine to machine protocol that's open and well suited to automation. Socket to socket would be ideal of course, as it's then suitable for intra machine as well as inter machine use. A very useful model for automation use
would be simply a virtual array of registers. This would trivialize communications even in RLL. The problem with a lot of the closed
offerings is that they have a lot of high level cruft and bloat thst results from adapting IS and office software mechanisms when the job to be done in the automation world is often trivial and rather obvious. Most are examples of using 50,000 lines of code to move an integer from one register to another. Horrendously inefficient. For IO, I favor Modbus and Modbus/TCP. Not that they are fantastic, but because they are nearly ubiquitous and nearly open enough and doable without custom silicon.

Do you have some favorites for consideration?

Regards

cww

--
Free Tools!
Machine Automation Tools (LinuxPLC) Free, Truly Open & Publicly Owned Industrial Automation Software For Linux. mat.sourceforge.net.
Day Job: Heartland Engineering, Automation & ATE for Automotive Rebuilders.
Consultancy: Wide Open Technologies: Moving Business & Automation to Linux. _______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org http://lists.linuxplc.org/mailman/listinfo/linuxplc


Posted by Peter Wurmsdobler on 11 February, 2002 - 1:01 pm
Curt,

Socket connection would be my preference also, but on top a higher level protocol ist needed, such as passing a struct or so.

> Do you have some favorites for consideration?<

Modbus/IP would be a starting point, as the protocol is very straight forward and it is publicly available. I also thought of something the PuffinSCADA guys have developed for UNIX systems. They have also a ModBus driver, but maybe their protocol can be implemented natively, if I understand their work correctly.

Or develop something from scratch? What information has to be exchanged, published by or request from a control system component? registers?
values of i/o points?, or even even PLC programs and rungs? But in which format then. Just some thoughts.

Or OPC ? (this is a joke),
peter
--
Peter Wurmsdobler
Control.com Inc.
508-621-3611 fon
508-621-3614 fax _______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org http://lists.linuxplc.org/mailman/listinfo/linuxplc


Posted by Curt Wuollet on 11 February, 2002 - 1:17 pm
Hi Peter

Aye, and there's the rub. For the greatest utility, each machine would want the data plugged into it's addressable map so these can simply be treated the same as any other point. This would be trivial for comms between two LPLCs or two PUFFINS. When you mix them up, you have need for a machine independent representation on the wire similar to what is done in say, NFS. And it would be nice if the size was dynamic so you are not passing any more data than is needed or sending floats when short ints would do. So maybe an ordered linked list of structs with say ints sent first and then floats. Or the traditional approach of a header that gives number of ints, number of floats and housekeeping. Each machine could then dynamically allocate buffers and attend to mapping them to registers. This would also allow for asymmetrical maps as would almost certainly be the case for SCADA or other primarily one way communications. The beauty of this approach is that all this could be handled
automagically and the registers would just be there. This would all of course, be systems programming, fast and efficient.
I would think this could be coded to operate at wire speed.
For a first pass, x86 GCC native representation should work.
If the closed world wants to play, we could rev in the machine independent stuff or simply let them worry about it :^).

Or we could go for buzzword compliance and use XML or something and send an order of magnitude or two more data to accomplish the same task while invoking 100 times more code.

Those last two statements were jokes.

Regards

cww
--
Free Tools!
Machine Automation Tools (LinuxPLC) Free, Truly Open & Publicly Owned Industrial Automation Software For Linux. mat.sourceforge.net.
Day Job: Heartland Engineering, Automation & ATE for Automotive Rebuilders.
Consultancy: Wide Open Technologies: Moving Business & Automation to Linux.

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org http://lists.linuxplc.org/mailman/listinfo/linuxplc


Posted by David Nimmons on 11 February, 2002 - 1:34 pm
1 question and 1 observation:

Question:
Would the hardware from Sixnet not provide a suitable platform?

Observation:
XML data combined with XML-RPC provides a very good way to communicate to the outside world, ie; HMI, etc.

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org http://lists.linuxplc.org/mailman/listinfo/linuxplc


Posted by Harald Albrecht on 11 February, 2002 - 1:36 pm
David Nimmons wrote:
> Observation:
> XML data combined with XML-RPC provides a very good way to
> communicate to the outside world, ie; HMI, etc.

Do you mean XML-RPC or SOAP with RPC?

My .02 euro (note that there is no plural-s for euro): XML-RPC is surely
easy to implement because it is straight to its functionality. No
unnesseary twinkles. However, it is not buzzword-compliant. And it has
no W3C behind it or one of its working groups. SOAP/RPC is a beast. But
you get more support for the whole infrastructure. It is
buzzword-compliant. It has a W3C working group, an official W3C standard
(recommondation). And for its future you will surely get green lights
for your projects easier from managers if you mention "SOAP" -- but not
for "XML-RPC". You will also probably have fewer arguments with firewall
administrators...

Back to my metamodels...
Harald
--
Harald Albrecht
Chair of Process Control Engineering
RWTH Aachen University of Technology
Turmstrasse 46, D-52064 Aachen, Germany
Tel.: +49 241 80-97703, Fax: +49 241 80-92238

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org http://lists.linuxplc.org/mailman/listinfo/linuxplc


Posted by Richard Ahnen on 11 February, 2002 - 1:38 pm
Gentlemen,

Wouldn't a platform such as this:

"http://www.applieddata.net/products_master.asp":http://w ww.applieddata.net/products_master.asp

...has local I/O for E-stop
string & other watchdogs,

& anybody's Ethernet, ModBus RTU, or CAN I/O work well for your purpose(s)?

They already have a Linux image for this platform.

Richard Ahnen
R&D Engineer

GILMAN
A Member of the Johann A. Krause Group
________________________________________________
Gilman Engineering & Manufacturing Co. LLC
305 W Delavan Drive, P.O. Box 1367
Janesville, WI 53547-1367
Phone: 608-741-4787 Fax: 608-757-7028
email: rahnen@gilmanassembly.com
_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org http://lists.linuxplc.org/mailman/listinfo/linuxplc


Posted by Curt Wuollet on 11 February, 2002 - 1:45 pm
Maybe, I don't know enough about StrongArm in the areas of VMM, gcc and the like, maybe somebody else does. I know the uCLinux thing is out
because theres no VMM hardware. There are a lot of cool platforms out there. I'm going with x86 because it should be the easiest, if not the cheapest. I would like to see it running on as many platforms as possible.

Regards

cww
_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org http://lists.linuxplc.org/mailman/listinfo/linuxplc


Posted by Jiri Baum on 12 February, 2002 - 1:20 pm
Curt:
> Maybe, I don't know enough about StrongArm in the areas of VMM, gcc
> and the like, maybe somebody else does. I know the uCLinux thing is
> out because theres no VMM hardware.

Actually, uCLinux doesn't sound all that difficult - I haven't gone through my notes from the conference, but from memory I think only the shared libs would take a bit of ditzing around, but only a bit.

This would be XIP (execute-in-place), to conserve RAM.

Jiri
--
Jiri Baum <jiri@baum.com.au> http://www.csse.monash.edu.au/~jirib
MAT LinuxPLC project --- http://mat.sf.net --- Machine Automation Tools

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://lists.linuxplc.org/mailman/listinfo/linuxplc


Posted by Kipton Moravec on 12 February, 2002 - 3:52 pm
I just found the uClinux website. It pointed us to the DragonBall Processor. It looks like I can build the board cheaper with more memory with the dragon processor than with the 8051!

I went through the hoops this weekend on an 8051 design that had Ethernet. It had a 29 MHz 8051, 64K SRAM, 64K Flash, and the CS8900A Ethernet controller. I was estimating it would be just under 5 8-bit MIPS. The problem with cost was all of the "glue logic" for the interfaces. I looked at discrete and I looked at a CPLD.

I am now looking at the DragonBall processor. I can have a processor, 256Kx16 Flash and 4MB x 16 DRAM and the same Ethernet controller (or a
Realtek) for the same cost, because of no glue logic! I find that amazing, but it looks like that is the direction I am heading. The DragonBall has about 2.7 MIPS but they are 16-bit MIPS so moving data will be much more efficient than with the 8-bit design. And that is mostly what this does.::

Kip
_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://lists.linuxplc.org/mailman/listinfo/linuxplc


Posted by Dan L. Pierson on 12 February, 2002 - 3:28 pm
I suspect that most (all?) StrongArm chips have memory management. The uCLinux effort was aimed at lower end ARM chips as I remember.::

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://lists.linuxplc.org/mailman/listinfo/linuxplc


Posted by Curt Wuollet on 13 February, 2002 - 10:41 am
Hi Dan

Long time no speak.

ucsimm is motorola dragonball.

gotta go::

regards
cww
--
Free Tools!
Machine Automation Tools (LinuxPLC) Free, Truly
Open & Publicly Owned Industrial Automation
Software For Linux. mat.sourceforge.net.
Day Job: Heartland Engineering, Automation & ATE
for Automotive Rebuilders.
Consultancy: Wide Open Technologies: Moving
Business & Automation to Linux.
_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://lists.linuxplc.org/mailman/listinfo/linuxplc


Posted by David Nimmons on 11 February, 2002 - 1:49 pm
I plan on looking into SOAP, but, I decided to cut my teeth on the simpler XML-RPC first.

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org http://lists.linuxplc.org/mailman/listinfo/linuxplc


Posted by Curt Wuollet on 11 February, 2002 - 1:43 pm
Hi Dave

David Nimmons wrote:
>
> 1 question and 1 observation:
>
> Question:
> Would the hardware from Sixnet not provide a suitable platform?

It will, if we can work out all the details. It should be a great platform. PC's will continue to be a great platform. I am addressing a specific market that those two don't. Something that will directly replace a PLC at comparable cost so I can compete in that arena.
I can do what I need to do with a PC and cards and cables and my translator boards. I can't fit that in the enclosures that most PLC's live in. And it wants a display and it's filters cleaned on a regular basis. It may even need cooling on our factory floor. So, another PLC goes in and my next chance is 10 years down the road. There are valid reasons PLC's are popular. I just want LPLC in a package that could reasonably drop in as a replacement. And I want fanless, filterless, industrial tough hardware at a competitive price point. The point that it offers vastly superior capability is moot if you can't compete with a standalone PLC and win.

> Observation:
> XML data combined with XML-RPC provides a very good way to
> communicate to the outside world, ie; HMI, etc.

I agree.

The Hardware:
Let's be clear, I am not proposing that this be THE home for LPLC. This is something I am doing to address the general problem that PC based automation suffers from lack of suitable hardware to go head to head with PLC's in cost and form factor. It is also an experiment to see if Open Hardware can be viable. The fact that I belong to the LPLC project does not mean that I am requiring anyone to support this or bend development efforts to suit. I do intend to run LPLC on it if at all possible and will donate the design to the project for lack of a better home for Open Hardware. I may even decide that it's simply not doable and quit. It's something I can do and something I see a need for. It's a cww project. I of course would welcome support and help because it's an open project too.

The Transparent Ethernet IO thing is something I am proposing for MAT/LPLC. It would of course run on the hardware I propose as well as any other hardware that LPLC will run on. It's an idea that has been banging around in my head for quite a while. I think it would be great if instead of <put protocol/transport here> and all the hassles and setups and licenses and such that that entails, we could simply specify that N registers from this machine be visible on that machine. Poof, communications just became as simple as writing to or reading from a register.
I think this is doable and a really neat way to accomplish the task and couldn't get any simpler for the user. It's clearly doable on Linux hardware, I would like for it to be possible on other hardware that supports TCP/IP. To that end we want to keep it as simple as possible as most other hardware doesn't have a full OS.
I think users of any hardware would like something like this to communicate between machines as the present alternatives are ugly, costly, and in many cases impossible.

Regards

cww
_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org http://lists.linuxplc.org/mailman/listinfo/linuxplc


Posted by David Nimmons on 11 February, 2002 - 1:47 pm
I am asking out of ignorance, because I really don't know. What is it you are trying to do that can not be done with the Sixnet stuff?

Curt Wuollet wrote:
>Hi Dave

>David Nimmons wrote:
>>
>> 1 question and 1 observation:
>>
>> Question:
>> Would the hardware from Sixnet not provide a suitable platform?

>It will, if we can work out all the details. It should be a great platform. PC's will continue to be a great platform. I am addressing a specific market that those two don't. Something that will directly replace a PLC at comparable cost so I can compete in that arena. I can do what I need to do with a PC and cards and cables and my translator boards. I can't fit that in the enclosures that most PLC's live in. And it wants a display and it's filters cleaned on a regular basis. It may even need cooling on our factory floor. So, another PLC goes in and my next chance is 10 years down the road. There are valid reasons PLC's are popular. I just want LPLC in a package that could reasonably drop in as a replacement. And I want fanless, filterless, industrial tough hardware at a competitive price point. The point that it offers vastly superior capability is moot if you can't compete with a standalone PLC and win.
>
>LinuxPLC mailing list
>LinuxPLC@linuxplc.org >http://lists.linuxplc.org/mailman/listinfo/linuxplc
_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org http://lists.linuxplc.org/mailman/listinfo/linuxplc


Posted by Curt Wuollet on 11 February, 2002 - 4:55 pm
Don't feel bad, I seem to be having a problem communicating what I'm
trying to do.

To overcome the resistance to PC control I am trying to remove the obstacles. Call these customer requirements.

It should look like a PLC.
It should cost less that a PLC or at least not more.
It should work like a PLC. No hdd's, floppies, keyboard, display, needed. It should offer a reasonable amount of IO in convenient increments like a PLC so the mix of input/outputs can be tailored to fit the task. All hardware should be industrial grade. It should support a variety of plug in modules that work like PLC modules. DC inputs, AC inputs, Sinking outputs, Sourcing outputs, etc. Field wiring should be reasonably compatible with PLC's. 24 V power should be doable as well. It should offer mounting like a PLC. DIN rail included. In other words it should be reasonable replacement for a PLC.

My requirements:

It should work like a PC and run a Stock Linux distro for development with a compatible pared down version for deployment. processors from 386 class to Athlon class depending on task. Should support full PC functionality for high end projects. No single sourced parts. Purchased parts should be widely available.
Should support fieldbuss, at least Modbus/TCP, Profibus, Devicenet. Completely Open and documented. User should be able to fix, modify, and even add their own modules. Someone with loftier goals should be able to use this as a start for bigger and better things.
Simple enough to build locally if desired. Practical to do so. Identical units commercially built by several vendors in competition
would be best. One would be good. Me if all else fails.

It should be noted that this idea has been done and there is hardware that closely resembles AB PLC's in outware appearance. It is extremely expensive and no linux drivers exist for anything. And I couldn't buy one, they're OEM. Same old lockin ripoff scam. In my view these don't solve the problem. SoftPLC sells some, for the approximate price of a Buick I could use that.

So the short answer to your question is: Be multi sourced, be competitvely priced and fit the same role as a PLC. Theirs is a great RTU, certainly the best from our perspective:^) I am working on the best PLC and/or IO rack from our perspcctive. They fit different places for different functions. I want a way to make LPLC a PLC when I need a PLC.

Regards

cww
_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org http://lists.linuxplc.org/mailman/listinfo/linuxplc


Posted by David Nimmons on 11 February, 2002 - 4:58 pm
I am aware of the existence of Sixnet but don't really know much in the way of details about their offerings ( Hope to obtain some of their stuff in the near future). So if I appear dense, I am. If I understand correctly, your objection is that they don't offer local I/O in a typical plc type chassis. Is that correct?

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org http://lists.linuxplc.org/mailman/listinfo/linuxplc


Posted by Curt Wuollet on 11 February, 2002 - 5:01 pm
Pretty much so.
And they're not as open as I'd like. This isn't their fault, Open Hardware is a brand new concept and they are certainly more open with their software than anyone else in the biz. In fact, I am not criticizing them at all, simply explaining why I don't just use their hardware. I got their
newsletter with the announcement, I could forward that if you'ld like. And please don't take offense, I'm explaining to the whole list at the same time. I may even use their hardware when it fits.

Regards
cww

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org http://lists.linuxplc.org/mailman/listinfo/linuxplc


Posted by David Nimmons on 12 February, 2002 - 3:39 pm
No offense taken. I appreciate your patience, because I realized I was not asking my question very well. I was just trying to figure out what
the criteria that you mentioned that the Sixnet stuff was not meeting. I would like to see their newsletter, if you don't mind sending it.::

Thank you,
David Nimmons
_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://lists.linuxplc.org/mailman/listinfo/linuxplc


Posted by Curt Wuollet on 12 February, 2002 - 3:41 pm
Hi Dave

I've got it at work, I'm home today working on an automotive hardware problem :^) Later today or tomorrow.::

Regards
cww
--
Free Tools!
Machine Automation Tools (LinuxPLC) Free, Truly
Open & Publicly Owned Industrial Automation
Software For Linux. mat.sourceforge.net.
Day Job: Heartland Engineering, Automation & ATE
for Automotive Rebuilders.
Consultancy: Wide Open Technologies: Moving
Business & Automation to Linux.
_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://lists.linuxplc.org/mailman/listinfo/linuxplc


Posted by Johan Bengtsson on 12 February, 2002 - 10:32 am
I agree completely about what you are doing, I am even thinking of (in some time) I could perhaps help you with designing the analog I/O boards with complete isolation you probably want to have.

Btw, how many I/O bits are you planning to have per module?
16? 32? 64?

I would say that you should have at least 32, preferably more (64) since that would allow for some more possibilities when it comes to analog I/O.

/Johan Bengtsson

Do you need education in the area of automation?
----------------------------------------
P&L, Innovation in training
Box 252, S-281 23 H{ssleholm SWEDEN
Tel: +46 451 49 460, Fax: +46 451 89 833
E-mail: johan.bengtsson@pol.se
Internet: http://www.pol.se/
----------------------------------------

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org http://lists.linuxplc.org/mailman/listinfo/linuxplc


Posted by Curt Wuollet on 12 February, 2002 - 3:19 pm
Hi Johan

The count is kinda up in the air right now, I was gonna have 32 points times 8 slots, flat mapped. Then, because of address space concerns, I added a slot register. With the slot register, I can have 64 points per slot times 8 slots and need only 9 contiguous addresses. This is what I'm leaning towards, but for some reason the 8+1 bothers me and 7 +1 would be ugly. In 8+1 you could comfortably fit a 16 bit ADC with a
mux on the frontend and control or at least a pair of 1 channel ADC or DACs. With these counts, one might want a smart driver that reads or writes only occupied space. I'm trying to figure out why the 8+1
bothers me before committing. I've gotta scan the IO memory space
and figure out if 9 bytes would be difficult to place in the normal 0x10 slots used. If so, the 7+1 would give 56 points per slot, an inelegant number. I'm thinking of designing for 0 or 1 wait state
instead of the standard 4 because most machines and hardware are far from 8088 class these days. I won't trade much simplicity for speed
though, because I want the bus to be easily understood and easily interfaced so it is practical for people to add their own cards. Most machines run the ISA bus at a pretty good clip these days. I'm checking the PC104 offerings to see if that's true there also. I don't have any problem with non-isolated cards either, it's just that what I do (interfacing between machines) makes them easier to use.::

Regards
cww
--
Free Tools!
Machine Automation Tools (LinuxPLC) Free, Truly
Open & Publicly Owned Industrial Automation
Software For Linux. mat.sourceforge.net.
Day Job: Heartland Engineering, Automation & ATE
for Automotive Rebuilders.
Consultancy: Wide Open Technologies: Moving
Business & Automation to Linux.
_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://lists.linuxplc.org/mailman/listinfo/linuxplc


Posted by Johan Bengtsson on 12 February, 2002 - 3:42 pm
Ok, I am not following your math here really....

the slot register, that is something supposed to be sitting on the backplane controlling the bus right? with one byte for that you could point out 256 slots and use your other 8 bytes to adress different registers inside these. that would be 64 bits per module and 256 modules, 16384 bits total

These 16384 bits could be arranged in another way if desired, such as 5 bits from the slot register points out module number, the remaining 3 points out different banks on each module giving you 32 modules with a maximum bit count of 512.

Simple modules such as digital in/out would not need anything more than bank 0, and not even all of that one. More "advanced" modules could need more.

Have I interpreted your thoughts corretly, or where did it go wrong?

As I see it you don't even need 9 continous adresses with a slot register....::

/Johan Bengtsson
Do you need education in the area of automation?
----------------------------------------
P&L, Innovation in training
Box 252, S-281 23 H{ssleholm SWEDEN
Tel: +46 451 49 460, Fax: +46 451 89 833
E-mail: johan.bengtsson@pol.se
Internet: http://www.pol.se/
----------------------------------------
_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://lists.linuxplc.org/mailman/listinfo/linuxplc


Posted by Curt Wuollet on 13 February, 2002 - 10:38 am
Hi Johan

8 bit register. 256 slots 8 addresses each 8 bits. Only using 8 physical slots so I could use the other 4 bits for bank switching but I don't want a mux on each card or the complexity.::

Regards
cww
--
Free Tools!
Machine Automation Tools (LinuxPLC) Free, Truly
Open & Publicly Owned Industrial Automation
Software For Linux. mat.sourceforge.net.
Day Job: Heartland Engineering, Automation & ATE
for Automotive Rebuilders.
Consultancy: Wide Open Technologies: Moving
Business & Automation to Linux.
_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://lists.linuxplc.org/mailman/listinfo/linuxplc


Posted by Johan Bengtsson on 13 February, 2002 - 10:55 am
I don't see that it would add that much complexity really, you need perhaps another one or two circuits on the backplane, somewhat depending on exactly how the adress space is to be used

You will need to have a demux for the slot adressing, 8 slots are fine but feeding the remaining bits (or at least 3 of them) to all of the slots they can have that demux if they need different banks, if they don't then that mux isn't necesary at all (it will mean all banks overlap, but it wouldn't matter would it?)

One single 74138 (for example) efter the buffer I suppose you would put there anyway solves the entire problem. For the next 8 slot backplane you need yet one 74138 (but connected differently of course)

I would say: reserve at least 4 bits for slot switching, a backplane with up to 8 slots would only need 3 - of course but anyway. Adding a second 8-slot backplane after the first would be an easy task Have at least 4 bits in total address space inside each slot, that means 128 bits if the module want's that. It would make room for 8 channel 16 bit analog input.

You could do this very well with an adress space of only 3 adresses (one for the slot/bank selection) and two for direct adressing. Simple modules would only need to listen to if they are selected or not but more advanced modules would need to check a lager adress space. The only extra complexity you get is one circuit and the extra pins in the connector. This would need 4 bits from the register selector for the slot adressing, 3 bits from the register selector + one bit from the adress bus of the processor for inside slot adressing. This leaves one bit left from the register selector....

I did by the way find some nice circuits from maxim, max 158 and max 161 (don't seem to be much difference except pinout and price, probably a speed difference). You would only need one of these and few more components to have a complete 8 channel 8 bit analog input, they take care of all the adressing themself...::

/Johan Bengtsson
----------------------------------------
P&L, Innovation in training
Box 252, S-281 23 H{ssleholm SWEDEN
Tel: +46 451 49 460, Fax: +46 451 89 833
E-mail: johan.bengtsson@pol.se
Internet: http://www.pol.se/
----------------------------------------
_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://lists.linuxplc.org/mailman/listinfo/linuxplc


Posted by Curt Wuollet on 13 February, 2002 - 2:10 pm
Hi Johan and all:

This kind became a preliminay sketch of the project

I've been perusing Maxim's catalog also, they make some stuff that clearly had quite a bit of thought behind it as they cut down on the glue logic considerably. I was looking at their input debouncers, but they slow response to 40 ms to debounce. One amazing thing is that there really isn't MSI with all the features needed as input and output registers, There are a lot that are close, but lack something that would make them ont chip solutions. I guess that's why everyone uses the old 8255 chips. They are getting hard to get and kinda spendy, so I'm looking at 74HCx73 and the HCT versions looking for the one that needs the least extra logic. The 8255 isn't all that great either but everyone knows the quirks.

The bus is looking like:

power
ground
8 data wires
8 slot selects, one to each slot so these will only need one pin on
the slot connectors
IOR (buffered)
IOW (buffered)
3 address lines (8, 8 bit registers possible for each slot) reset 3 spares for the future.

This gives me a 20 line bus about an inch wide to a 2x10 pin header connector. The cost would be minimal to go to a 2x12 for extra spares or ? I may go up to the next "standard" size just on principle as revving the backplane will be cheap to add new functionality.

This is really just a subset of the ISA/PC104 bus so people already know how to interface with it except for the slot selects which are pretty self explanitory. I hold this simplicity to be pretty important so we get a variety of cards beyond what I will design.

What I am trying to minimize is the logic on each slotcard so they can be small and cheap. The backplane has lots of room as the height is
determined by the PC104 module dimensions and the length is the PC104 module plus 8 slots on .75" centers. The PC104 connector can be
(I think) at the edge so the glue logic can be layed out underneath it.

Looks like a package about 4" high by 11" wide. Depth will be determined by the real estate needed for the most complex slotcard. Any card with more than 16 inputs (or possibly even 8) will use ribbon cable to a dinrail terminal strip rather than onboard terminals. There simply isn't enough space on the end of a 4 inch card. this is
probably more cost effective anyway as the onboard connectors are a major part of the slotcard cost. If these aren't available at low
cost commercially, it's not a big deal to lay them out as well.

If people want to think about cards, lets say 4" wide with a 24 pin header socket centered on the backplane end. Length to be determined. Through hole components and layout to be preferred so humans can build and work on the cards without special equipment.

This will meet the design goal as a PLC form factor box quite well. Many 8 slot PLC chassis have a larger footprint than this.

All this is, of course quite preliminary and assumes external power. I greatly prefer to use external power to allow choice and get that heat outside the box. The panels for the PC104 space will be kept clear for connectors from the CPU or cards stacked upon it. I may go to 5 or even 6 inch height to accommodate this wiring. I don't
have a PC104 processor to work with yet. I'm working off drawings.

Please speak up if you see anything you don't think will work or if I'm doing anything particularly dumb. Even if I don't get things
together to pull this off, it's a useful exercise on what an Open PCPLC should look like.

johan.bengtsson@pol.se wrote:
>
> I don't see that it would add that much complexity really, you need
> perhaps another one or two circuits on the backplane, somewhat
> depending on exactly how the adress space is to be used
>
> You will need to have a demux for the slot adressing, 8 slots are fine
> but feeding the remaining bits (or at least 3 of them) to all of the
> slots they can have that demux if they need different banks, if they
> don't then that mux isn't necesary at all (it will mean all banks
> overlap, but it wouldn't matter would it?)
>
> One single 74138 (for example) efter the buffer I suppose you would
> put there anyway solves the entire problem. For the next 8 slot
> backplane you need yet one 74138 (but connected differently of course)
>
> I would say: reserve at least 4 bits for slot switching, a backplane
> with up to 8 slots would only need 3 - of course but anyway. Adding a
> second 8-slot backplane after the first would be an easy task Have at
> least 4 bits in total address space inside each slot, that means 128
> bits if the module want's that. It would make room for 8 channel 16
> bit analog input.
>
> You could do this very well with an adress space of only 3 adresses
> (one for the slot/bank selection) and two for direct adressing. Simple
> modules would only need to listen to if they are selected or not but
> more advanced modules would need to check a lager adress space. The
> only extra complexity you get is one circuit and the extra pins in the
> connector. This would need 4 bits from the register selector for the
> slot adressing, 3 bits from the register selector + one bit from the
> adress bus of the processor for inside slot adressing.
> This leaves one bit left from the register selector....
>
> I did by the way find some nice circuits from maxim, max 158 and max
> 161 (don't seem to be much difference except pinout and price,
> probably a speed difference). You would only need one of these and few
> more components to have a complete 8 channel 8 bit analog input, they
> take care of all the adressing themself...
>
> /Johan Bengtsson
>
Major league snippage to keep our hosts happy.::

Regards
cww
_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://lists.linuxplc.org/mailman/listinfo/linuxplc


Posted by Thomas B. O'Hanlan on 13 February, 2002 - 2:31 pm
Look at using a Xilinx or similar PLD to replace multiple 8255s, connected to I/O circuits similar to Curt's isolated I/O modules.::

regards,
Tom O'Hanlan
_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://lists.linuxplc.org/mailman/listinfo/linuxplc


Posted by Thomas B. O'Hanlan on 14 February, 2002 - 1:16 pm
The slot selects could be on the /AEN pin for the 104 bus. This would emulate the function of that pin now, qualifying I/O reads and writes. Are you talking about stacking modules ,ala PC104, or pluggable, similar to a PLC plug-in?::

tom
_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://lists.linuxplc.org/mailman/listinfo/linuxplc


Posted by Curt Wuollet on 14 February, 2002 - 1:18 pm
Hi Tom

Actually, both. The backplane will have slots for plugun cards like a PLC this lets us provide hardened IO in increments. Tbe PC104 engine will plug into the backplane to give us the PC compatible equivalent of a PLC. You can also stack modules on the PC104 bus for fieldbus, multiple serial ports, or whatever else your heart desires, This project is simply the backplane and cards. I would buy the PC104 stuff. So for the relatively easy task of designing the backplane and IO similar to what I've already done we get an Open standardized platform that can compete head to head with PLC's on functionality and cost. Probably compete real hard on the cost :^). Come to think of it, it oughta blow the PLC away on functionality also.
The backplane simply looks like one PC104 card with upto 512 IO points or something less if you fill slots with analog functions. It's very doable, even for me as an individual. The design for backplane and cards will be published and I would invite companies to sell boards, kits or finished product on a non-exclusive basis provided they remain compatible. Since it's PC compatible, any PC based automation software should run which should provide an adequate market.

What do you think?

Regards

cww::

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://lists.linuxplc.org/mailman/listinfo/linuxplc


Posted by Johan Bengtsson on 14 February, 2002 - 1:20 pm
Sounds reasonable.

Power:
What kind of voltage are you suggesting? +5V I suppose. Anything else, or would that be up to each I/O card if they need anything other than that?

How much power would each module be allowed to use? Some reasonable amount have to be selected of course and making sure the backplane and connectors can handle this.

I would suggest you use more than one pin for ground and power. Especially for ground:
- Less current per pin if it is a module needing top power
- Possibly easier routing of the I/O cards if those pins are spread out at smart places
- Possibly less noice, again if they are spread out in smart places

I suppose you are going to make the slot select an active low signal, that seems to fit most circuits best.

Would not a single line connector be better? At least would the routing be easier (especially of the I/O boards) and done smart it would help to reduce noice on the power supply. (By using one side of the backplane as ground - and nothing else on that side. Then make all the power wires as wide as possible between connectors and you have a quite good noice reduction capacitor between those planes.) I would go for 1x36, they are easy to find. They are however cuttable at any place so if you think that is too much you can select a lower number.

No interrupt?
Well, probably not needed but the question does of course need asking, you have probably done that already however.

How high components would be allowed on each side of the board? Even if most boards will be of simple design and not need much space that would not necesarily be true for all I/O boards, 25mm (one inch) on the "component side" and for example 5mm on the other?




/Johan Bengtsson::

Do you need education in the area of automation?
----------------------------------------
P&L, Innovation in training
Box 252, S-281 23 H{ssleholm SWEDEN
Tel: +46 451 49 460, Fax: +46 451 89 833
E-mail: johan.bengtsson@pol.se
Internet: http://www.pol.se/
----------------------------------------
_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://lists.linuxplc.org/mailman/listinfo/linuxplc


Posted by Curt Wuollet on 14 February, 2002 - 3:49 pm
johan.bengtsson@pol.se wrote:

> Sounds reasonable.
>
> Power:
> What kind of voltage are you suggesting? +5V I suppose. Anything else,
> or would that be up to each I/O card if they need anything other than
> that?

Good question. The real headache with our environment is that +24 is all that you can count on. And linear (IC) regulators from +24 to +5 aren't really feasible except for very low current. The PC104 stack is the big consumer, most IO is low power and with isolation the power is gonna come from outside the box or there's no point. I would like a +12 or +15 option that can be used with a spare line for any odd linear that needs it for linearity, etc. 4-20 ma. stuff might like some higher voltage than 5 for compliance range. I don't want switching converters in the box for noise reasons. I'm gonna think that through some more and look at what the PC104 market does.

> How much power would each module be allowed to use? Some reasonable
> amount have to be selected of course and making sure the backplane and
> connectors can handle this.

I would think that 150ma. should be enough for most. I've seen the header connectors used for much more than that.

> I would suggest you use more than one pin for ground and power.
> Especially for ground:

Yes, that's why we may end up with 28 or 30 pins. Relying on multiples to split current is a bad idea because if they don't things come
unsoldered. I'll probably assign multiples but ensure that any one can do the job. Hard to have too many grounds.

> - Less current per pin if it is a module needing top power
> - Possibly easier routing of the I/O cards if those pins are spread
> out at smart places
> - Possibly less noice, again if they are spread out in smart places
>
> I suppose you are going to make the slot select an active low signal,
> that seems to fit most circuits best.

Yes.

> Would not a single line connector be better? At least would the
> routing be easier (especially of the I/O boards) and done smart it
> would help to reduce noice on the power supply. (By using one side of
> the backplane as ground - and nothing else on that side. Then make all
> the power wires as wide as possible between connectors and you have a
> quite good noice reduction capacitor between those planes.) I would go
> for 1x36, they are easy to find. They are however cuttable at any
> place so if you think that is too much you can select a lower number.

I thought of that, but there's two problems. Easier to bend and I haven't seen shrouded ones. The shroud prevents all sorts of headaches. It also means the backplane will use pins which goes against my practice of not having exposed powered pins, but the socket on the plugin is far less susceptable to damage. The pins will be protected by the depth of the machine. Also the female connector is more likely to wear and replacement would be easier if it's on the card. Layout is an issue, but .100" centers are actually coarse by modern standards. It would be nice to use three layers with a good ground plane. But that would make the boards quite a bit more expensive. Tradeoffs, tradeoffs.

> No interrupt?
> Well, probably not needed but the question does of course need asking,
> you have probably done that already however.

That's what the spares are for. If you're interrupt driven you don't look like a PLC. I'll run the hardware interrupts and other interesting pins from the PC104 bus out to pth's so you can jumper a spare as an interrupt. Only drivers and the kernel have access to interrupts
(normally) under Linux but some folks with RTOS may want them. I balance a lot of this with the fact that revving the backplane for enhancements won't be all that tough.

> How high components would be allowed on each side of the board? Even
> if most boards will be of simple design and not need much space that
> would not necesarily be true for all I/O boards, 25mm (one inch) on
> the "component side" and for example 5mm on the other?
>

Convince me. I have been planning on .75" centers card to card, but that's certainly not final. The biggie here would, I suppose, be relays or DC-DC converters or?::

Regards
cww
_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://lists.linuxplc.org/mailman/listinfo/linuxplc


Posted by Curt Wuollet on 13 February, 2002 - 2:07 pm
Oops

should be the other 5 bits.::

regards
cww
_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://lists.linuxplc.org/mailman/listinfo/linuxplc

Your use of this site is subject to the terms and conditions set forth under Legal Notices and the Privacy Policy. Please read those terms and conditions carefully. Subject to the rights expressly reserved to others under Legal Notices, the content of this site and the compilation thereof is © 1999-2014 Nerds in Control, LLC. All rights reserved.

Users of this site are benefiting from open source technologies, including PHP, MySQL and Apache. Be happy.


Fortune
Mother is the invention of necessity.
Advertise here
Advertisement
our advertisers
Help keep our servers running...
Patronize our advertisers!
Visit our Post Archive