CLX Messaging to multiple controllers example

Hi,

I configured this method some months ago, and have just come back to site to do some more work/testing.

What I have found, at the moment anyway, that it is taking in excess of 15-20secs to complete the message, and go to the next one.
I only have 2 CPU's (L32E's) that I am talking to, and cannot recall it being this long back then.
What could be causing this un-acceptable delay? I am thinking about going to prod/cons if I cannot get this sorted (should of been done this way in the beginning, but could not shut down the process).

I am going to try and use wireshark, but am a novice on this, so will be interesting.

A wild guess is that the long delay involves a TCP Connection timing out so that another one can take its place.

Do you have a managed switch in place that can mirror the traffic from the originating module ? That is crucial for the use of Wireshark or any other analyzer.

Is this an application where just one MSG instruction is manipulated so that it targets multiple controllers ? I don't recall a thread or example that you originally used.

Yep, that sounds like more a educated guess than wild!

Do you have a managed switch in place that can mirror the traffic from the originating module ? That is crucial for the use of Wireshark or any other analyzer.

Click to expand...

Yep, I just have to set the correct port to be mirrored.

Is this an application where just one MSG instruction is manipulated so that it targets multiple controllers

Click to expand...

Yep, I copied this from the examples included with RS5k.
This method should be just as reliable as individual blocks, but not as robust as prod/consume?

What exact example you are using?

this one works for sure:
see chapter 3 of 1756-pm012
http://literature.rockwellautomation.com/idc/groups/literature/documents/pm/1756-pm012_-en-p.pdf

Post your program.

If you have only two controllers why not to program two messages? - much easier to troubleshoot.

Something is definitely wrong

lostcontrol said:

What I have found, at the moment anyway, that it is taking in excess of 15-20secs to complete the message, and go to the next one.

Click to expand...

There is a background process time that I think is set to 10% be default. Increase it to about 40%. I have never seen any benefit to increasing this time above 40%. If your communications is still slow the wire shark idea is a good way to find our what isn't responding.

What exact example you are using?

Click to expand...

The MSG_To_Multiple_Controllers, under Projects\Samples\ENU\v16\Rockwell Automation.
I have modified the code slightly, so that a different array can be sent to the required controller, but this is hardly an issue.
Thanks for the link, I will check it out when I have a better internet connection, currently on our now infamous XT network!

If you have only two controllers why not to program two messages? - much easier to troubleshoot.

Click to expand...

There is actually a 3rd as well, but not in use yet. And there is the potential for future CPU's, so I thought that this may be a better option.

There is a background process time that I think is set to 10% be default. Increase it to about 40%. I have never seen any benefit to increasing this time above 40%. If your communications is still slow the wire shark idea is a good way to find our what isn't responding.

Click to expand...

Currently each CPU is at 20%, I forgot to look at this. I am pretty sure I increased this value when I was originally setting up the comms.

I added some monitoring after I originally posted this, and then when I checked before I left site, the cycle time was less than 1sec again.
One thing that I overlooked, was that one of these CPU's does have about 15 Enet VSD's, and some of these may of been switched off, not available to this CPU. The other CPU only has some Point IO, would it be possible that this would have an affect on the response capabilities of each L32E??


I do need to do some wire-sharking, so that I can see what is going on, with nodes present/not present on the network.

Missing VFDs may do it:

Controller uses internal messaging to establish I/O connections. If I/O is missing these MSGs will go over and over. They will sit 30 seconds and wait before timeout.

since only 10 unconnected buffers are available, your other messaging (PLC to plc) will have to wait,

easiest way is to inhibit missing I/O
another wat is to increase amount of unconnected buffers from default 10 to 20 (max value 40)

Where/how do I do this?

Click to expand...

Inhibit checkbox:
Module Properties, Connection Tab

Unconnected buffers:
Page 10 of the same manual I posted above
http://literature.rockwellautomation.com/idc/groups/literature/documents/pm/1756-pm012_-en-p.pdf

Needs to be done once on every power up