ControlLogix messaging interlock ideas

[Latzi]

Hi Gents,


I'd appreciate some ideas on how to slow down some comms between a ControlLogix L63 system and three Micrologix 1400 PLC's. As part of an upgrade project I did replace and upgrade a PLC5 with a Clogix L61 bridge reusing the local PLC I/O and a remote rack I/O . The old system used to be connecetd through RIO to some old SLC's via DCM cards. I removed / replaced the fixed I/O SLC plc's with MLogix 1400 and redone the comms via etherenet. So whatever was interfaced between the old PLC5 system and the three Fixed I/O SLC's via RIO now it's interfaced via Ethernet using message blocks betwen the L63 CPU and the three new MLogix systems,
The system works ok and no issues however the messaging is "fired" from the Clogix to the Mlogix (SLC TYPED READ & WRITE) based on the message block tag .EN bit. This creates some traffic and in the task monitor of the Logix CPU the comms sometimes goes into the red zone 100%. This is not surprising.
My question would be if anyone could give me an idea on how to slow down and interlock these three messages. As in make sure only one is executed at any given time etc.
So onCe again. I have three Micrologix 1400 PLC's . In one of the Contrologix Tasks I have a Program File where I have two messages for each Micrologix 1400. One is a SLC TYPED READ and the Other SLC TYPED WRITE. Typically the Clogix reads from the Mlogix and on some triggers writes some info Back to the MLogix. This happens on the XIO XXXX.EN of the message block bit so it happens as fast as possible and whenever possible.I could obviously put timers in and limit that speed ,etc but I am not sure if this is the best approach.
I am just wondering if anyone had some similar setup and how you solved this.
Any idea hint greatly appreciated.
Thanks.

 

[MarkNightingale]

Use the previous messages DN bit to send the next message, and cascade it through that way, so in effect you have a loop.

On the first message use the DN bit of the last message and or that together with the first scan bit. As soon as the PLC starts the messages start polling.

Only one message block is working at a time.

Mark

 

[The Plc Kid]

Thats the way I do it also. If the data does not need to updated as fast as the loop put a delay timer at the end of the loop that has to be done before the loop restarts.

 

[Kev77]

Make sure that you also use the error bit because if you have a case when message times out you will not get a done bit. I had issue with a group of compressors and when one was offline all the messages would stop.

 

[Oakley]

Rockwell Knowledgebase has an article on a "Message Manager" which is what is being described.

I used in before, and it works nicely if you have a lot of messages that you need to manage.

 

[Kev77]

Thanks Oakley, nice example...

One thing to watch when using the error bit is the error timer value. If it is set to 10 seconds it can really extend the cycle times when one message is unable to complete.

 

[Latzi]

Thanks for your suggestions. I've done all 10 messages (not only the three Micrologix)using the method in the "Message Manager" in the example on RA Knowledgebase.

Only that as Kev said you really have to watch the timers for the .er bit. By default they are set to 30 sec which can delay messaging greatly specially that some of the machinery in my example is purposely turned off so the msg block will always time out.

I did reduce that time to 1.5 sec and no problems. The "pressure" on the comms came right down under 20% from close to 100% after this change.

The only thing to watch is that the timeout values are given in microseconds.

Thanks again.