ControLogix com. read from micrologix

Hi,

I have a micrologix 1400 i my cabinet. The customer have a ControlLogix and have requested a ethernet communication from my micrologix.

I'm not used to Micrologix or AB but am I correct in assuming that I don't need any programming on my part to allow the Controllogix to read and write to tags in my PLC?

I'll just provide the tag adresses B1:1/0, N7:1 etc, that they can or should access?

Yes, I know it's better to read then write but this is a general question

/Tim

You are correct, the controllogix can do it all. But as you said, it would be best if you both read each other. Your micrologix can read the ControlLogix's tags using the "Map SLC" option on RSLogix 5000

Although they are named MicroLogix, this family type processors are distant relatives of the Soft-, Flex-, Compact- and ControlLogix CPUs.

You will not be able to transfer data between a MicroLogix and ControLogix controller with the Produce/Consume Implicit type communications.

The method you will have to use is the Explicit Messaging type transfer over an Ethernet connection.

While you could code the MSG on either or both sides, I'd recommend to handle everything within the ControlLogix application.

Just make sure the ML1400 is on the same subnet as a ControLogix ENBT bridge and you group the data to be transferred to/from in contiguous memory partitions (addresses and tags); this would need only one Read and one Write MSG instruction for the entire data batch.

The MSG instructions will be of the CIP Type and the path will be established by browsing with an RSLinx Ethernet driver to the ML1400 controller.

Thanks for the responses.

That is exactly what I wanted, the ControlLogix to handle all the communication. This way I can provide my micrologix and it will be avaliable as a slave to the ControlLogix.

The customer is free to change the adress of our equipment as they like. I'll not be apart of commisioning ever so my intent is to provide an micrologix that can be accessible without me doing anything.

I have already grouped my data a little bit to provide to modbus tcp/ip communication so that part will be covered.

Thanks alot for replies and you time

/T

The MSG instruction in the ControlLogix will be "SLC Type Read" and "SLC Typed Write". The MicroLogix controllers are very similar to the old SLC-500 family, and use the same editing software and a nearly identical instruction set.

Group your data together in Integer, Binary, or Floating Point data tables, ideally ones that are set aside only for communications.

The ControlLogix cannot easily read strings or timers or counters from the MicroLogix, so pack your data into N or B or F data tables.

Ken Roach said:

The MSG instruction in the ControlLogix will be "SLC Type Read" and "SLC Typed Write". The MicroLogix controllers are very similar to the old SLC-500 family, and use the same editing software and a nearly identical instruction set.

Group your data together in Integer, Binary, or Floating Point data tables, ideally ones that are set aside only for communications.

The ControlLogix cannot easily read strings or timers or counters from the MicroLogix, so pack your data into N or B or F data tables.

Click to expand...

Thank you, good advice. I have special data tables that are programmed for the modbus configuration and this is what I also will use to give to my customer.

I have for example grouped all the input and outputs in B data tables,
my inputs range from B31:0/0 to B31:1/7, I have then started the outputs at B31:2/0 to B31:3/2 and variuos bits from B31:4/0 and forward. Would this be a decent way to group the data in your opinion or should I put them directly after each other?

That's a reasonable way to do it. I've always used "N" (integer) registers for my data transfer, because then I can transfer both integer data and binary/discrete data, but if you only need to transfer discrete data, and as long as your data is contiguous, I suppose there's no reason you couldn't use B registers as well.

Just to throw my 2c into the mix as to how to handle the data transfer.

It's simpler from a programming point of view to have the CLX handle all of the data transfer, because that way you don't have to mess about with mapping tags to virtual SLC data tables in the CLX. I have done this before.

However, as a general rule I believe it is always better to read than to write. That is, to have the CLX read whatever data it wants from your ML1400, and have the ML1400 read whatever data it wants from the CLX. The reason for this is for cross referencing and troubleshooting. If you find data changing in your ML1400 and want to work out what's driving that change, you will do a cross reference or find all. If you have the CLX writing to the ML1400, you will turn up no results. If you have uploaded without comments, or if the comments were not adequately entered to begin with, you're now at a complete dead end. If your ML1400 is on a network with 100 other controllers, how are you to know which one is writing to it? There are ways and means of finding out, but none of them quick and straightforward, and at 3am "quick and straightforward" is the only thing you want to see.

It's of course not a hard and fast rule, but I will generally go the way of "read, never write" wherever I can. If you DO wish to write, then make absolutely sure that it's explicitly and clearly detailed in the comments at both ends.