PLC backplane protocols

[tomleijen]

I am carrying out some research into PLC backplanes for a new product my company is developing.
I am looking for information on the types of communications busses and communications protocols used in PLC rack backplanes for communication between the CPU and the various I/O cards.
Can anyone help me with this?
Does anyone know a decent website or book to look at for information?

 

[amptramp]

Good luck finding info on Allen-Bradley's backplane bus and protocol.

The only PLC backplane bus that is non-proprietary that I am familiar with was the GE 90-70 family that utilized a VME bus architecture. You could actually purchase off the shelf VME cards and plug them into the 90-70 "rack".

 

[PLCMentor]

Actually the woodhead guys make 3rd party cards for the AB line. I suspect there is a way to contact AB and get that information - I am sure it will not be free. You might do better to handle via a communication path (ethernet i/p, control net, modbus or the like). What platform are you developing for?

Russell White, P.E.
Automation Technologies, Inc.

http://www.AutomationNC.com

Automation Help

http://www.PLCMentor.com

 

[dV8r]

FYI, GEIP still uses the VME64 backplane for their new RX7i PAC and the RX3i is a PCI bus.

 

[StephenVB]

I have tried some and in my experience all the PLC manufacturers are very stingy with their backplane information. If you're not a BIG user and you aren't willing to spend LOTS of time at it you probably won't get anywhere.

You might have better luck trying to work with a standard interface such as Ethernet, Profibus or CAN. Even there there are problems. I was involved in a project to connect Linux PCs to PLC I/O using Ethernet. It was impossible to get info on the particular protocol from AB and difficult from Automation Direct. I was also involved in a project to make a high current solid state module (8 x 120VAC @ 6A) using DeviceNet and SDS(?) CAN based networks. It wasn't easy.

 

[amptramp]

tomleijen:

Actually I thought it unnecessary (obvious) to mention if you were willing to pay for information it may be available. There are several third party manufacturers providing products to the PLC OEM's. Woodhead also supplies modules to Siemens. Horner Electric provides modules to GE. AVG (Uticor) suppies modules to Schneider Electric. And on and on.

Rockwell Automation (Allen-Bradley) refers to their third party program as Encompass. Schneider Electric calls theirs Collaborative Automation Partners Program.

Does anyone know a decent website or book to look at for information?

From your quote I assumed you were looking for free information. Forgive my lack of clarity.

 

[tomleijen]

Thanks a lot for the information.
My company is developing a PLC and I am doing some research for the backplane.
We are looking at using a serial bus so that the PLC and I/O can be arranged in a rack format, but also in a more spaced out format (more for ease of installation in tight spaces than a remote I/O solution).
The aim of the project is not specifically to have other manufacturers' modules connect to our PLC or vice-versa but it would be good to look into the possibility.
The main reason I asked the question is:
I want to know whether there are any PLCs out there that use serial busses as a backplane and which one do they use?
I need some more information on comms protocols, specifically those used for transporting large volumes of data in the backplane of a PLC rack?

At this stage I am looking at either CAN or 485 for the electrical layer, and something similar to CIP for the protocol layer, this is however just from initial research and the comparison to existing PLC systems would do a great deal in justifying my choices.

 

[tomleijen]

Oh and since it is just research at the moment, the budget isn't very high so free information would be preferred.

If the possibility of making our modules compatible with other PLCs does come up however we might rethink the budget and look at the likes of some of those third party schemes.

Thanks,
Tom

 

[jraef]

Backplane comms are not industry standards (with the GE exception I suppose), everyone has their own solution and most claim it is better than anyone else. But by signing up (and paying for the right) as a potential solution partner with any of the majors, you can end up indirectly see how each one does it. Unfortunately that typically also comes with a very strict non-compete clause.




"If I had eight hours to chop down a tree, I'd spend six sharpening my axe." -- Abraham Lincoln
For the best use of Eng-Tips, please click here -> faq731-376

 

[PNachtwey]

My company has made boards for the TI505, TI575, ABPLC5/VME. GE9070, Reliance ??? it has been so long ago, Multibus, VME bus, Modicon 984, Modicon Quantum, SLC5 and Control Logix.

The PLCs manufacturers will not give you any information unless they feel it benefits them. Even so you must agree to have your board tested at their labs and sign non-disclosures. You will not find a website with the information you seek. The PLC manufacturers are fanatical about controlling what is on their bus.

Why would you want to copy some one else's old technology when there are better ways of doing things every year? Most PLC interfaces I would never consider today

I would look at using FPGAs and using a high speed serial interface. PCIe is a good off the shelf option but more expensive .


Peter Nachtwey
Delta Computer Systems

http://www.deltamotion.com

 

[tomleijen]

Thanks for the info and quick responses,

I would look at using FPGAs and using a high speed serial interface. PCIe is a good off the shelf option but more expensive.

That is indeed what we are looking at, but it is always good to look at past successes and failures to see what to do or what not to do.
And the potential to be able to make our product compatible with others might possibly make it worth it to use older technologies.

 

[JohnWaa]

If you are starting from scratch, why not consider USB?

There are tons of chipsets available, the specs are open, and there is all sorts of sample code to look through.

It's fast, easy to connect, and if we can use DeviceNet on mission-critical applications with a straight face, then USB shouldn't have any problem whatsoever.

No one says that you have to adhere to the entire USB spec, pick out the pieces that work for you and ignore the rest.

 

[PNachtwey]

DeviceNet is too slow. USB may work or better yet Firewire with isochronous mode. The problem I have with both is that they are 8 bit interfaces. PCIe chips have 32 bit interfaces with DMA so the overhead is low.


Peter Nachtwey
Delta Computer Systems

http://www.deltamotion.com

 

[JohnWaa]

DeviceNet is too slow.

And not that reliable in my experience. Junk, basically.

USB may work or better yet Firewire with isochronous mode.

The problem I have with both is that they are 8 bit interfaces. PCIe chips have 32 bit interfaces with DMA so the overhead is low.

Well, just glancing at a few datasheets, I see that some of them have DMA access...

But you're a motion-guy, and that means high speed. I work in the world of "same day service", so things are a bit more relaxed for me.

But with the advertised speeds for USB2, I would think that it would keep up with just about anything out there.

I tossed out USB because the chips are out there. As is the protocol, etc, no need to design something new.

And when you need a new I/O block (or whatever), just plug it in to a free port and let the PLC discover it for you.