ControlLogix to Micrologix MSG via Ethernet

i have a Clx(1756-L73) as the main plc, and it is swapping data with Mlx 1500. The two are connected to a AB managed switch(EMS04T). The mlx 1500's connected to eth by a 1761-net-eni module. based from another thread, i can only read messages.

"Controllogix - Setup an SLC Typed Read message pointing to the Data Table address you wish to read, specify the length and destination. The Communications tab is where you specify your path. It will be the name of your ENBT module, 2, then the IP Address. So if your ENBT is named myenbt and your IP Address is 123.123.123.123 your path will be myenbt,2,123.123.123.123

Micrologix - You will setup routing in the ENI from the Controllogix IP Address to a node on the serial side. This must be node 45-49 for a Controllogix and the Controllogix processor must reside in slot 0. From there your must map the tag to SLC/PLC5 tag, and setup a 500CPU Read message in the Micrologix pointing to the data address you specified in your mapping and the node address configured in the ENI"

so am I correct up until this part?here you can see the msg in the Clx and Mlx
http://www.flickr.com/photos/76004776@N06/7140563437/in/photostream

I did it long time ago but as I remember I only do read/write in the Controllogix platform, whereby you will a create a data file to send it to the legacy PLC...At the Rs5K you go to, Logic-MapPLC - then do the mapping of tags between Logixtagaddressing to Legacy type of addressing.. then use this tag in your msg instruction (Follow the messaging instruction as per normal procedure).. either read or write. you only need to do in your other PLC is to re create the same tag address..

Cheers..
kabayan

What is it that you actually want to do ?

The simplest way to exchange data between a ControlLogix and a 1761-NET-ENI connected MicroLogix is to initiate both SLC Data Table Write and SLC Data Table Read MSG instructions in the ControlLogix.

Any thread that indicates that the ControlLogix can only perform Read commands is mistaken or misunderstood.

Unless you are attempting to perform a "change of state" or "on event" data exchange to limit bandwidth usage, I don't see a reason to have any MSG instructions in the MicroLogix.

Thanks ken, yeah you can do it in either way but the simpliest is doing it in the logix i think what i have said in my previous post pratically wrong, i now remember i did it when i used compactlogix with mitsubishi HMI G2000.. Now i remember.. Thanks again ken..

@Nigasai, sorry for the confusion. but i think there is an extra step due to the NET-ENI,

@Ken for example,i want to know if the Mlx 1(there are 14 Mlx in the system) is stopped,running or faulted which is indicated by N9:1 so the CLx needs to read that from the Mlx. i have read that NET-ENI has 6 max connections. I do not know if there are extra procedures needed due to NET-ENI like the port number must be configured using NETUTIL,then a read MSG must be programmed in the Mlx. maybe that "change of state" was intended from the previous thread or not.

You should be able to read OR write at your discretion from a ControlLogix PLC to any Allen-Bradley PLC it's able to talk to as long as the remote PLC can perform a READ (SLC/MLX/PLC5/3/2). At least this is true today. This thread is a bit old, so the mapping method available today (2016) may not have been an option when the original post was made.

APPLICATION NOTE: If you READ data remotely--rather than WRITE it--you and the end user and anyone trying to troubleshoot the system will almost always be better off. For perspective, the modern Produce/Consume tag method is based on always reading the produced tag. Producing a tag simply makes it available for remote processors to read it. The remote processor then reads the tag to "consume" it.

Always using READ for data transfer is a best practice for several very good reasons:

1. Read signals can be traced back from the destination PLC to the source PLC and upstream from there. With Write, the data just shows up from the cloud and it’s impossible to tell where it came from unless the memory address description is extremely good.

2. Read is passive and doesn’t overwrite data. If Write addressing has a typo or is set up wrong, the destination PLC’s data can be corrupted and the remote program(mer) won't know what happened.

3. The destination PLC has full control of a Read. A Write won’t tell you if the connection is lost and can’t control what happens at the destination. With a Read the destination PLC can zero the incoming data if needed (among other error-handling measures).

To MSG Read a CLX tg from an SLC or MLX (Micrologix), use the Tag Mapper tool in the 'Logic > Map PLC/SLC Messages...' menu. This tool allows you to share a tag using a legacy addressing scheme recognized by SLC, MLX, PLC5/2 processors (probably PLC3 also).

It's similar to setting up a network share for a local hard drive: Specify what resource to share and what to call it when others connect to it. In the screenshot below, the mapping allows a Micrologix controller to read the tag 'SSC02_Data_OUT' as if it were in file N100. I haven't tested this yet because I'm waiting for my MLX PLC, but I worked on an SLC-CLX system last year where someone else had exposed a CLX tag to a legacy PLC using this mapping method.

LlndPrkr said:

APPLICATION NOTE: If you READ data remotely--rather than WRITE it--you and the end user and anyone trying to troubleshoot the system will almost always be better off.

Click to expand...

Wholeheartedly agree with READ being preferable from a troubleshooting/tracing standpoint.

You don't need any mapping for READ from or WRITE to SLC/PLC5, you just choose the correct Message Type and enter the remote address as is.

You definitely do need mapping if a remote SLC/PLC5 initiates communications, simply because neither of the legacy platforms "understands" the tag-based database in the Logix. The mapping is simply a "lookup" table that equates the remote PLC/SLC data-file number to the array tag in the Logix.

One thing not mentioned is that the array tags in the Logix controller must be the same data-type as the legacy PLC/SLC - typically an INT array as the legacy machines are 16-bit.

Good points, daba. I could have been more clear in my original post. Yes, the CLX will read or write since it can handle legacy addressing. This was covered pretty thoroughly in the previous posts and is what prompted me to present the mapping solution that allows the legacy PLC to read from the CLX and thereby avoid the pitfalls of having the CLX also do a MSG Write to the MLX. I saw too many posts saying "it's easiest to just do the Read and Write in the CLX." It's only "easy" until you or your customer have to troubleshoot it.

Excellent point about the data type matching. To exchange INT registers with the MLX and use native DINT words in the CLX programming, I use the Bit Distribute (BTD) instruction to pack two INT words into a single DINT. Same method works going the other direction. It's a little cumbersome, but with being able to have multiple output instructions on one line, it's not too bad for a block of 4 DINT's or so. In my case, it's worth it because we have standard DINT-based UDT tags for the sub-processor interfaces and the program can be standardized on the DINT side of the communication chain.

I suspect a file instruction like FAL would be able to convert larger blocks of INT's to DINT's and vice-versa, but haven't had sufficient reason to try it.

Someone posted this sometime back. You do not need to map PLC5 addresses when the message is initiated by the PLC5. I've used this method several times and has worked great.


View attachment HowMSGPlc5ToClx.doc

Ken Roach said:

Unless you are attempting to perform a "change of state" or "on event" data exchange to limit bandwidth usage, I don't see a reason to have any MSG instructions in the MicroLogix.

Click to expand...

Unless the code is well documented, it is easier to troubleshoot if the tags are always read. If it isn't obvious where the data is coming from, a quick cross reference on the tag will find the MSG block that reads the data. If the tags are written by a different PLC is writing the tag it is harder to track it down.