communicating with AB PLCs


Thread Starter


I'm getting involved again with PLCs after being away for about 12 years, specifcally Allen Bradley.

The concept of I/O hasn't really changed.
But just trying to communicate from lap top to the PLC has become a little tricky.

Using RSLOGIX 500 and LINX is at time frustraing.

Is there a easy to understand book or manual on this topic?

Curt Wuollet

Not that I've found. It's scattered here and there
and quickly degenerates into alphabet soup and
devices known only by their bulletin or product
number. The biggest problem I've seen is port


You must provide a little bit more of data:
a) are you trying to program the SLC?
b) How to you connect your PC: serial, DH+, DeviceNet or Ethernet?
c) are you trying to read data from the controllers with OPC?

I agree, each of the above could fill a whole book... that's why I'm asking.

Regards from Switzerland,


Bob Peterson

RSLinx configuration is pretty straightforward, but as Curt indicated the information for doing so is scattered and not easily available.

Port conflict is only an issue with serial ports, and that is really a windows problem.

All of the protocols and networks configure about the same way, except for the ethernet driver. It is the only one that cannot browse and find existing devices on the network. You have to manually add every device you want to browse into a list or the driver won't find them.

The ethernet driver also requires at least some basic understanding of how ethernet works. That makes it substantially more diffiuclt to configure and use than the other networks AB has.

Curt Wuollet

Yeah, we don't do much AB networking. We have at least a dozen different makes of PLCs which means we have almost no hope of doing networking of any kind. I'm kinda on the top floor of the Tower of Babel. I assumed he might be just trying to communicate with the various AB processors one on one, which can also be a lot more challenging than it ought to be. RSLinx is way overkill in this instance and I much prefer those that don't introduce another whole layer of software. I can see why they did this though, as there seems to be no single way to talk to all their own PLCs!!!???!!.



Michael Batchelor

AB has made a fortune by turning something simple into something complicated that you have to buy another tool to accomplish.

Just look at the number of $90.00 three wire serial port cables they sell with one pin in a weird place. Sometimes I admire their marketing
moxie (they're clearly making more money than me), but other times I just think it's obscene.


Curt Wuollet

Yeah, it's kinda bizarre except from the nickel and dime perspective. "Let's design a PLC that won't talk to the software we have now." "And when we figure out how to talk to the thing we can sell that kludge for big bucks". Equally strange is explaining to folks that their PLC uses a TTY interface when most of them haven't ever seen a teletype except possibly in a museum. Not that a current loop isn't a good thing for long wires. It's just kinda long in the tooth. I have a really hard time seeing the fatal flaws of using a standard RS232 port for programming with the bizarre stuff being an expensive option..

But then I couldn't sell pushbuttons for $75 either.

Your AB rep should be able to supply you with the DH protocol book if you ask him.

I had to write a DH driver for an Hitachi microcontroller to talk to a PLC5 years ago (about 1994!) - AB UK gave me the protocol book for free!

The protocol was simple enough to code for what we needed to do (read and write to N files).

The only tricky bit was how AB handles the value 16. 16 is a DLE tag in AB speak (a delimiter), thus if you want to send the VALUE of 16, you have to send it twice! This requires extra code to be written to spot and strip out extra DLE tags before the comms layer passes the data up to a higher level.

Interesting stuff as I remember. Those were the days!


Mark Wills MSc, MIAP