"Open" Hardware.

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

Johan Bengtsson

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: [email protected]
Internet: http://www.pol.se/
----------------------------------------

_______________________________________________
LinuxPLC mailing list
[email protected] http://lists.linuxplc.org/mailman/listinfo/linuxplc
 
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 <[email protected]> http://www.csse.monash.edu.au/~jirib
MAT LinuxPLC project --- http://mat.sf.net --- Machine Automation Tools

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

David Nimmons

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

Johan Bengtsson

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: [email protected]
Internet: http://www.pol.se/
----------------------------------------
_______________________________________________
LinuxPLC mailing list
[email protected]
http://lists.linuxplc.org/mailman/listinfo/linuxplc
 
K

Kipton Moravec

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

Johan Bengtsson

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: [email protected]
Internet: http://www.pol.se/
----------------------------------------
_______________________________________________
LinuxPLC mailing list
[email protected]
http://lists.linuxplc.org/mailman/listinfo/linuxplc
 
C
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.

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

Johan Bengtsson

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: [email protected]
Internet: http://www.pol.se/
----------------------------------------
_______________________________________________
LinuxPLC mailing list
[email protected]
http://lists.linuxplc.org/mailman/listinfo/linuxplc
 
C
[email protected] 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
[email protected]
http://lists.linuxplc.org/mailman/listinfo/linuxplc
 
P

Peter Wurmsdobler

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
[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