comm between micrologix and compact logix

[Jeff23spl]

Hello guys

I would like to know, by your experience, what would be the best effective protocol to use according to easiest of use, speed, reliability and of course... the price...

I will have to use few micrologix as local slave unit controled by 1 compactlogix...

thanks

All CPU won't be far from each others

 

[dmroeder]

Without knowing any details of your project I'd vote Ethernet based CompactLogix (L32E or L35E) and the Ethernet based MicroLogix (1100 or 1400).

If I had it my way, they'd all be CompactLogix. I'd use the L32E/L35E as the master and replace the MicroLogix with the L2X CompactLogix series. Then use Produced/Consumed tags for comms.

 

[Jeff23spl]

ok for ease of use but it will be costly...

If i keep the slave micro and compact master...

Connection config of a micro1400 offer df1 or ethernet ....RS232 DF1 would be a bit slow and obsolete ?

What would be involved to have a compact logix sending and reading information to few micro1400 ? VS using compact for all ?

 

[ArikBY]

Hi

If you concern about the speed go with Compact Logic.With ML you will have to use MSG which will take more time. Using produce and consume it like putting your PLCs on one bus.It cost more.You have to check the speed issue and get the best for you.

 

[dmroeder]

You can connect and configure over DF1, but I don't think that you will be able to communicate between PLC's over DF1.

Like ArikBY said, if you want to communicate between MicroLogix and CompactLogix over Ethernet, you would use message instructions.

 

[nwboson]

I have built numerous systems with CompactLogix communicating with ML 1100 and ML1400 over Ethernet. Works great to keep costs down. Performance is stellar: no measurable performance difference from remote IO or multiple CompactLogix - you just don't have the nice tag architecture you would have with an all-CompactLogix design.

Just use built-in explicit messaging commands of RSLogix 500 and RSLogix 5000 to perform the communication. I usually set it up so the slaves all send updates to the CompactLogix master whenever the slave sees a change, then the CL just works from its own local image. That way you don't have to 'poll' the slaves for changes: its the slaves job to report changes when they happen. I write a timer around every ML change to ensure an oscillating input can't swamp the communication: immediately report changes but limit the maximum number of reported changes per second per signal (max 1 per second in my case).

 

[Jeff23spl]

did you made the slave writing to master because having the master to read slaves was more complex or because it was the way you want it?

Because on my side, i usually have the slave to remain passive with an exchange table and program the master to read and write to slaves...

What about communicating back and forth between just micrologix ETH PLC ?

 

[nwboson]

In a peer-to-peer messaging approach (as opposed to the multicasting used by CompactLogix under the hood for field IO), you have two choices:
1) The slaves each push (blow) new data to a block of memory in the master immediately as its available.
2) The master pulls (sucks) data from each slave in an infinite regular loop: the master has a polling loop to constantly read each slave.

I prefer #1 because it IMMEDIATELY sends new data to the master rather than waiting for the poll to get around to that slave and because it causes way less traffic on the (Ethernet) bus. If you are careful to make sure no slave can swamp the bus traffic (a timer to ensure data for each signal is transmitted no more often than every second), it makes for a very clean architecture.

In #1 I set aside a block of registers in the master with a well defined and well documented purpose for each location: essentially a data structure for all the data that needs to be used between the master and slaves. Then each slave just writes to its own little chunk of master memory.

Once the ML 1400 came out, it has enough memory for the master so there is no need for the CompactLogix in a cost-sensitive application. I have eight ML1400 slaves talking to one ML1400 master in one application (if I run out of memory I just define two units as 'masters' and split their functions according to the application). That same application has 31 VFDs and six Red Lion HMI's using only ML1100 and ML1400. The VFDs communicate to the ML's using modbus and the ML's all communicate to each other using Ethernet. This is installed in many, many locations and is quite reliable as long as the ML's are installed directly to plates instead of DIN rails and the plates are attached to backplanes with rubber isolators: the ML's are sensitive to mechanical vibration on machinery that has vibration.

 

[Firejo]

First off let me say that you can communicate between ANY Allen Bradley PLC’s via DF1. It is not just a configuration protocol. However if EtherNet/IP is an option (the PLC’s you’re going to use have it) then that is a good option. If MicroLogix is one of the PLC’s then you must message but if they are all CompactLogix then you can use “Produce/Consume” which saves time but uses (a lot) of bandwidth. The reality is that every application has different “best practices”. With that, don’t be fooled into thinking that DF1 won’t get the job done. It’s a great protocol and can work well. Do keep in mind that while using the “slave messaging” option does reduce the amount of time it takes for data to be updated it doesn’t let you know if there is a problem with communications. If the Master is doing the polling and one of the nodes goes off line it will figure it out.