MSG Compactlogix to Compactlogix

YoungWint

Member
Join Date
Dec 2012
Location
East Midlands
Posts
77
Hi All

I am trying to read data from one Compactlogix to another Compactlogix.

One is a 1769 L35E and the second a 1769 L32E. I have set up arrays in each PLC, names are different to reflect one is transmitting one is receiving. The L35E is to read from the L32E.

I have selected Mesaage type of 'CIP Data Table Read'.

Communication Path is L35E: LocalEnb,2,192.168.61.145,1,0

I am using a timer, set to 10 secs, and every 10 seconds (on the DN) enabling the MSG. I get a permanent error message 16#00ff (extended 16#000_2107).

Can't get the instruction to work and can't quite see what I have done wrong as all seems correct to me. !!!

Any advice would be greatly appreciated.
 
Welcome to the Forum !

That error code (0x2107) indicates that the data types for the source and destination do not match.

It's not enough for the data types to be similar, or of the same size; they have to be exactly the same.

If the source is a DINT array, the destination has to be a DINT array.

If the source is a UDT, the destination has to be an identical UDT.
 
Ken

Thanks for the reply. Yeah that was correct had already realised that my arrays if different data types.

Made them all the same and now get General Error and sometimes connection failure.

Can ping all the stations and see them in RS Linx, just can't get them to exchange data. Am at a loss as to what is stopping it exchanging.

any other ideas.
 
Ken

Thanks for the reply. Yeah that was correct had already realised that my arrays if different data types.

Made them all the same and now get General Error and sometimes connection failure.

Can ping all the stations and see them in RS Linx, just can't get them to exchange data. Am at a loss as to what is stopping it exchanging.

any other ideas.

I usually set up Produced/Consumed tags for a case such as this.
Only downside , you need to develop any changes offline .

Also, are there other devices on this ethernet network, and do you have either Compactlogix messaging elsewhere?
 
When I did this a little while back, I had better results using the controller name name instead of the ethernet path. Check Module properties and just enter the NAME from the general tab in your instruction and give that a whirl.

Marc
 
One other thing I remember was to tick the Cache connection box on the communication tab of the instruction configuration popup.

Marc
 
One other thing I remember was to tick the Cache connection box on the communication tab of the instruction configuration popup.

Marc

Create a link to CPU in the I/O tree,
and use that name in the message instruction.

ScreenHunter_03 Dec. 05 12.05.jpg ScreenHunter_04 Dec. 05 12.06.jpg
 
Putting the other controller into the I/O tree just creates a background CIP connection that takes up a small amount of processor and Ethernet card resources. It has no effect at all on the way the MSG instruction works, other than making it easier to type in the path.

If this is going to be a connection that is used frequently (which the repeating 10-second timer indicates), then Caching the connection will reserve the controller and daughtercard resources. That's a good recommendation.

Capture the exact error codes, and troubleshoot from there.

Is this controller doing a lot of other messaging or I/O on the Ethernet port ? Is there anything notable about the connection between the controllers (a wireless link, for example) ?
 
If this is going to be a connection that is used frequently (which the repeating 10-second timer indicates), then Caching the connection will reserve the controller and daughtercard resources. That's a good recommendation.

What does "caching the connection" mean in this context ?
 
When you use an MSG instruction, the controller creates a Class 3 CIP Connection, which gets a connection ID and a timeout and otherwise takes up some resources in the controller and the daughtercard.

This takes a couple of transactions to take place, so it's a few milliseconds.

If the MSG instruction is "un-cached", the CIP connection gets torn down once the data payload transfer takes place. This also takes a few milliseconds.

If the MSG instruction is "cached", the CIP Connection stays active so it can be used by the next data payload transfer. This saves on the time and buffer space to create and delete the CIP Connection, in exchange for that Connection semi-permanently occupying the connection resources of the devices and modules involved.

In general, use Cached connections when you intend to fire the MSG instruction frequently (more than every 30 seconds or so).

There are exceptions to this, of course; for example, all MSG instructions passing through a 1756-DNB need to be un-cached. And the 1756-DHRIO module has important limitations on the number of cached messages you can use with it.

The Cached vs. Un-Cached configuration of the MSG instruction is unlikely to be the problem in this particular thread, unless the controller is on the edge of its connection capacity.
 
Putting the other controller into the I/O tree just creates a background CIP connection that takes up a small amount of processor and Ethernet card resources. It has no effect at all on the way the MSG instruction works, other than making it easier to type in the path.

If this is going to be a connection that is used frequently (which the repeating 10-second timer indicates), then Caching the connection will reserve the controller and daughtercard resources. That's a good recommendation.

Capture the exact error codes, and troubleshoot from there.

Is this controller doing a lot of other messaging or I/O on the Ethernet port ? Is there anything notable about the connection between the controllers (a wireless link, for example) ?

Ken, "I am not worthy" to comment on any of your statements, but would not a CompactLogix to Compactlogix ethernet message best be a Produced / Consumed configuration? This is the way I always do it when messaging is between logix processors.

I will then use a GSV instruction to test the health of the Ethernet connection to the other PLC(s). Only thing I cannot test on a large interval between messages is a heartbeat to determine if the other PLC is in Program mode.
 
I agree that a Produced/Consumed Tag is more efficient and straightforward than a MSG instruction triggered by a timer.

There might be a reason the O.P. is using a MSG instruction; the most common one I see here on the Forum is "I can't change anything in the source controller".

A Produced/Consumed Tag would have the same sort of configuration, network, resource, and media challenges as the MSG instruction.

If the O.P. has a noisy network, or his CompactLogix is out of CIP Connections, he's going to have just as much trouble with either method.
 
I agree that a Produced/Consumed Tag is more efficient and straightforward than a MSG instruction triggered by a timer.

There might be a reason the O.P. is using a MSG instruction; the most common one I see here on the Forum is "I can't change anything in the source controller".

A Produced/Consumed Tag would have the same sort of configuration, network, resource, and media challenges as the MSG instruction.

If the O.P. has a noisy network, or his CompactLogix is out of CIP Connections, he's going to have just as much trouble with either method.

The O.P. is bringing up a topic I see more and more with some of our customers who are jumping on the Ethernet bandwagon.
They complain, I tested the patch cord and it passed, I can ping Ethernet module and no issues, I can browse to Ethernet module web page, but I cannot figure out why my Ethernet IO and messaging keeps failing.

I think the O.P. needs to clarify what else is on this Ethernet network.
 
I know this thread is pretty old, but i am having the exact same problem currently. I am using a UDT and it is exactly the same on both ends. The problem i am having is that my UDT is DATA, so my source looks like DataToPLC.DATA and destination is DataFromPLC.DATA, and it doesnt work, but it does when it is DataToPLC.DATA.DINT and DataFromPLC.DATA.DINT. I have STRING's, DINT's, REAL's in the UDT. Any help would be amazing!!
 
Dlaudy, I'd recommend starting a new thread. Consider posting screenshots of your MSG configuration as well as the UDT definitions in each processor. Not sure I follow the DataToPLC.DATA vs. DataToPLC.DATA.DINT arguement. Without a lot of detail, we're all left to assuming. Don't wanna go there!

Does "exact same problem" mean you're getting the same error as the OP, or something else?
 
Last edited:

Similar Topics

Does anyone know if is possible to read data out of a ProfaceHMI/PLC into a CompactLogix PLC? I have a bunch of OEM machines on our plant floor...
Replies
2
Views
468
Hey Guys Having some trouble again with message path, I thought I had these figured out but I've not been able to get this one working. I...
Replies
4
Views
536
I'm working on a project currently that is requiring me to log a username and a and number. I need to MSG a string file, the username, and an INT...
Replies
13
Views
2,047
Hi all I'm trying to setup a MSG connection (which I'm not familiar to) between a CompactLogix CPU (L310ER) and a Micrologix 1400 CPU. At the...
Replies
1
Views
798
Hello Everyone, Can two PLCs on two different subnets pass data via CIP MSG Read Instructions? I would be using the HMS Fl3xy NAT 1:1 feature to...
Replies
6
Views
2,425
Back
Top Bottom