"Open" Hardware.

C

Thread Starter

Curt Wuollet

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
[email protected] http://lists.linuxplc.org/mailman/listinfo/linuxplc
 
>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
[email protected] http://lists.linuxplc.org/mailman/listinfo/linuxplc
 
C

Curt Wuollet

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
[email protected] http://lists.linuxplc.org/mailman/listinfo/linuxplc
 
C

Curt Wuollet

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
[email protected] http://lists.linuxplc.org/mailman/listinfo/linuxplc
 
K
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!! :eek:)

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

~Ken
_______________________________________________
LinuxPLC mailing list
[email protected] http://lists.linuxplc.org/mailman/listinfo/linuxplc
 
C

Curt Wuollet

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
[email protected] http://lists.linuxplc.org/mailman/listinfo/linuxplc
 
P

Peter Wurmsdobler

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
[email protected] http://lists.linuxplc.org/mailman/listinfo/linuxplc

 
C

Curt Wuollet

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!! :eek:)

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
[email protected] http://lists.linuxplc.org/mailman/listinfo/linuxplc
 
K

Kipton Moravec

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
[email protected] http://lists.linuxplc.org/mailman/listinfo/linuxplc
 
G
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
[email protected]
http://home.twcny.rr.com/embedded/
_______________________________________________
LinuxPLC mailing list
[email protected] http://lists.linuxplc.org/mailman/listinfo/linuxplc
 
C

Curt Wuollet

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
[email protected] http://lists.linuxplc.org/mailman/listinfo/linuxplc
 
C

Curt Wuollet

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
[email protected] http://lists.linuxplc.org/mailman/listinfo/linuxplc
 
C

Curt Wuollet

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
[email protected] http://lists.linuxplc.org/mailman/listinfo/linuxplc
 
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
[email protected] http://lists.linuxplc.org/mailman/listinfo/linuxplc
 
K
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 :eek:)

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
[email protected] http://lists.linuxplc.org/mailman/listinfo/linuxplc
 
C

Curt Wuollet

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
[email protected] http://lists.linuxplc.org/mailman/listinfo/linuxplc
 
C

Curt Wuollet

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
[email protected] http://lists.linuxplc.org/mailman/listinfo/linuxplc
 
C
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
[email protected] http://lists.linuxplc.org/mailman/listinfo/linuxplc
 
Thread starter Similar threads Forum Replies Date
C Open Control 29
W Programmable Logic Controller - PLC 175
K LinuxPLC Project 8
K LinuxPLC Project 6
C Open Control 10
Top