Hello,

It sounds like you guys are on your way to roughing a good spec and I am with you on most points.

I would ammend the following:

- 16 bit data bus

- 12 bit address

- Eurocard mechanical

Here are my arguments:


- I think having a full 16 bit data bus is much better. ISA supports this and it will make your scan time much faster. Most of your IO scan will be consumed by the processor waiting for the slow 8MHz bus, which gets really really slow with a lot of IO points. Basically you get twice performance for 8 lines cost. It can add up with high IO count machiens. Besides, most cards will be at least 16 bit, so you jsut got rid of one decoding operation!

- There should be many more address lines. 8 bytes is fine for simple IO, but not for analog IO, and complex plug in cards like motion controlers and non-vol cards. I suggest 12 bits of address so we can at least get up into the kilobyte range. The only reason NOT to go with more address is that it consumes more pins on the connector, which is not an issue (connectors aren't that much more expensive with more pin counts.) Keep in mind that you have a slot select for address decoding, so its not like you have to decode more address lines for simple cards. Basically you have a coupls 74AC latch chips for 16 bit output, and two 74AC bus transceivers for 16 bit input. When you read or write in the address range of the card the select line goes to the latches and reads/writes. Thats about as simple as they come.

- I really think we should go eurocard for mechanical. a eurocard is approx 3.8 x 6.5x 0.8 (inches). The hardware is really cheap if you buy the parts alone and assemble yourself. You can even get loads of prototype boards from places like vector electronics. You also get the benefit of having a whole boat load of power supplies that will fit in the same mechanical package -- if you so choose to want power in the cage.

I thihk it is important to build a strong and flexible spec so that we can get maximum use out of this across slightly different arenas. At the same time, keep it simple like it is so far. We don't need another PCI bus!! ) ::

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

 

Hi Ken

"Ken Emmons, Jr." wrote:
>
> Hello,
>
> It sounds like you guys are on your way to roughing a good spec and I
> am with you on most points.
>
> I would ammend the following:
>
> - 16 bit data bus
> - 12 bit address
> - Eurocard mechanical
>
> Here are my arguments:
>
> - I think having a full 16 bit data bus is much better. ISA supports
> this and it will make your scan time much faster. Most of your IO scan
> will be consumed by the processor waiting for the slow 8MHz bus, which
> gets really really slow with a lot of IO points. Basically you get
> twice performance for 8 lines cost. It can add up with high IO count
> machiens. Besides, most cards will be at least 16 bit, so you jsut got
> rid of one decoding operation!

Cost benefit isn't there in my view, we simply aren't talking about much data and the scan is limited not by throughput concerns but by the fact that plc type sensor and switch wiring simply can't handle scans under about 1msec. At that speed we aren't pressed for time reading or writing 64 bytes of data on a 8 or 12 mhz bus. 16 bit ISA wouldn't buy us much and the extra real estate isn't worth it. I also want it to be very
simple and non-critical to interface with. Once I put out the artwork, you are free to add whatever you wish. To rev the backplane will take little more than working with PCB and the same expense for board fab. I don't know why most cards would be 16 bit, I haven't designed them yet. The analog cards will likely be between 8 and 16 bit but we don't have to hurry to keep up with them. COnversion times for inexpensive ADC's aren't gonna load the bus. With a 10 mhz bus and 4 wait states a read or write is gonna take maybe 600 nsec. 64 of them will take perhaps 50 usec with some overhead. This is as slow as the bus gets. If the hardware allows zero or 1 wait state or 12 mhz or faster clocking the speed could be another order of magnitude better than we need.

> - There should be many more address lines. 8 bytes is fine for simple
> IO, but not for analog IO, and complex plug in cards like motion
> controlers and non-vol cards. I suggest 12 bits of address so we can
> at least get up into the kilobyte range. The only reason NOT to go
> with more address is that it consumes more pins on the connector,
> which is not an issue (connectors aren't that much more expensive with
> more pin counts.) Keep in mind that you have a slot select for address
> decoding, so its not like you have to decode more address lines for
> simple cards. Basically you have a coupls 74AC latch chips for 16 bit
> output, and two 74AC bus transceivers for 16 bit input. When you read
> or write in the address range of the card the select line goes to the
> latches and reads/writes. Thats about as simple as they come.

The ISA IO Address space is 512 addresses. Unless you memory map. High speed cards stack on the processor and can use whatever a PC will do. That's why the PC104(+) bus will be there and accessable. just plug a PC104 motion controller or other module on top of the processor, load the drivers and hook up your encoders and such. Those cards are non trivial to design and most folks would purchase them. Fieldbus cards require proprietary IP at the least and probably custom silicon. Ethernet is best integrated on the processor card. If you need higher IO counts, you simply attach Ethernet IO.

> - I really think we should go eurocard for mechanical. a eurocard is
> approx 3.8 x 6.5x 0.8 (inches). The hardware is really cheap if you
> buy the parts alone and assemble yourself. You can even get loads of
> prototype boards from places like vector electronics. You also get the
> benefit of having a whole boat load of power supplies that will fit in
> the same mechanical package -- if you so choose to want power in the
> cage.

Again cost/benefit and it's a bitch to hand solder high density connectors. Not to mention it's almost impossible to fan them out on a two layer board. I can buy eurocard racks and cards already, they are aimed at a different market.

> I thihk it is important to build a strong and flexible spec so that we
> can get maximum use out of this across slightly different arenas. At
> the same time, keep it simple like it is so far. We don't need another
> PCI bus!! )

We agree on that. What we need is a small cheap bus to do PLC type stuff. We can use existing standards to do the fancy stuff.::

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

 

I agree fully with Curt in keeping it simple. As it stands now you will probably need 3 bus chips on each board anyway (2 '244 and 1 '245). More address or data lines will just add more chips required for each board.

16 bit data bus is way overkill. If you have digital I/O with an 8-bit data and address bus that could be 2048 inputs and 2048 outputs. (256 * 8). That is way more than most PLC configurations. 100 I/O points is a big PLC.

Most of the stuff I see being done with PLCs is turning stuff on or off, and monitoring the states. In factory monitoring things don't happen really fast. In most (not all but most) cases if an alarm is sounded within 3-5 seconds of the fault occurring that is sufficient, especially when it could take 3 to 5 minutes (or more) for someone to respond.

In the project I am doing, I constantly monitor for leaks of some nasty chemicals. I have measured that I usually check the inputs about 20 times a second, unless I have a heavy communications load which may slow it down a little. However the customer does not want an alarm sounded or action taken until the signal is constant for 3 seconds!

If you are doing stuff with tighter control, you can do a lot with 30 Hz update rate. That is not a big load on the bus even if you take three bus I/O operations to read an A/D controller.

I am doing something similar, and I think 8 bits is enough.

If you want NV memory, serial EEPROM are the way to go. Two wires (for I2C) and you have up to 8K bytes, per chip. The nice thing about I2C is that you can bit bang it. Since it is NV memory, you can move the data into RAM at startup, and only update it when you need to. So the slowness is usually not an issue.

I don't think eurocards are a good idea either. They are a pain to work with. Since the I/O count is so low, I would recommend each card have a right angled box header for the connector to the motherboard. They are cheap, and the 100 mil spacing is easy to design with on a 2 layer board. You can get the board mount sockets to mate for the backplane. which are keyed so you can't plug it in backwards. You can, if need be, make the backplane from ribbon cable, and not require a rigid backplane.

If you have 8 address and 8 data, and a read and a write, we are looking at 18 pins. (I would probably add a master clock signal too) A 26 pin header will allow you to put the power and ground on a couple of lines for redundancy. Each line is usually rated at about 1 A. You probably will not get anywhere close to that, so being redundant with 4 power and 4 ground lines will probably do it easily. If you need more go up to a 34 pin header. I did a project where I put two 40 pin right angled box headers on the card, it worked nice. The cards were simple, I had a lot of pins, and it was cheap. The motherboard had 12 slots and it was cheap and easy to build. The board had 10 mil traces with 10 mil spaces which was very manufacturable.

Using 74HC parts I made a backplane out of unshielded ribbon cable 7 feet long running 8 MHz with only a 100 Ohm source resistor at the processor (at one end) to help cut down reflections. It had 17 boards plugged into it. Even at that length, I could not detect the reflections with my scope.

Another approach that I have done in the past is to use serial I/O. 74HC165 for inputs and a 74HC164 for outputs. You can clock really fast to move the data, it takes three lines or so for each direction, and you can daisy chain as many as you want. for lots of digital inputs or outputs. However it will not be too good for A/D converters and D/A converters.

Just my $0.02 worth.

Kip

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

 

Kipton:
> In most (not all but most) cases if an alarm is sounded within 3-5
> seconds of the fault occurring that is sufficient, especially when it
> could take 3 to 5 minutes (or more) for someone to respond.

If you have pushbuttons, you need reasonably fast scans for that. I'm not sure of the exact speed required, but 20 Hz sounds like it'd be OK. The first symptom is that the buttons have to be pressed firmly.::

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

 

Hi Kipton

Another interesting thing are the I2C ADC's and DAC's. Since ADC in particular will require several scans, (setup,start acq,wait,read,read) a person could include an I2C bus on the backplane and handle these asynchronously, probably simpler than parallel as you could simply wait on data. But, I think for the first pass, I'll do the "normal" thing. I believe the I2C ADC's are single sourced also, although this might have changed since I last checked. I think for NVRAM and DOC, I'll use whatever the PC104 SBC vendor supports. Again for simplicity. Many have watchdogs and battery backed storage options as well.::

Regards
cww
_______________________________________________
LinuxPLC mailing list
[email protected]
http://lists.linuxplc.org/mailman/listinfo/linuxplc

 

They could be latched & the latches cleared when they get a read strobe.::

--
Gary James
[email protected]
http://home.twcny.rr.com/embedded/
_______________________________________________
LinuxPLC mailing list
[email protected]
http://lists.linuxplc.org/mailman/listinfo/linuxplc

 

Jiri:
> > If you have pushbuttons, you need reasonably fast scans for that.
> > I'm not sure of the exact speed required, but 20 Hz sounds like it'd
> > be OK. The first symptom is that the buttons have to be pressed
> > firmly.

Gary:
> They ould be latched & the latches cleared when they get a read
> strobe.

Yeah, but:

- that sort of admits defeat on the part of the controller, and

- you have to realize that that's a problem, early enough to get it in place (relays, wiring, allocated output for the read strobe)::

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

 

Hello,

About latching, we use a 500us scan, using rtlinux periodic thread. On occassion there is still a problem with parts passing somehting like a photo sensor at extremely high speeds and producing a short pulse. We have seen parts pass in about 100us. Of course you can have pulse stretchers in hardware and latches, etc. but it isn't a uniform and convenient solution.

Anyhow, one solution to the latching issue is to do it in software. Using a kernel level IO driver in rtlinux, you can scan really fast (ours is 250us ). Every sacn I read in ports and break them up into integer variables that my user programs can read. I also write a latch variable, one for true and one for false depending on the state of the variable. In your user code you simple do this:

// if a part passed since last time we reset latch
if( my_photo_sensor_latch==TRUE){
do_some_action();
my_photo_sensor_latch = FALSE; //reset our latch for next time... }

Translate this to ladder or whatever language you prefer. (I prefer C, don't tell anyone!!)

This is another reason for using kernel level device drivers coupled with a real time kernel. WE have been using this for years and it works quite well, especially when you have some sequential code where you can't be checking an input all the time.

~Ken

_____________________________________________
LinuxPLC mailing list
[email protected] http://lists.linuxplc.org/mailman/listinfo/linuxplc

 

A minor issue, but I tend to code it as:

// if a part passed since last time we reset latch
if( my_photo_sensor_latch==TRUE){
my_photo_sensor_latch = FALSE; //reset our latch for next time...
do_some_action();
}

Which will allow the latch to retrigger during the do_some_action() processing and not be lost. If the logic is scan-based and polled, it may make no difference, but if the latches are asynchronouse or hardware based it could make a difference.

Rufus::

______________________________________________
LinuxPLC mailing list
[email protected]
http://lists.linuxplc.org/mailman/listinfo/linuxplc