SLC Messages Scheduling Best Practice

[elfrider]

Hi,

I am looking at the setting up some new ethernet comms which is originating from an SLC 5/05 to four new identical CompactLogix L24ER's (using SLC register mapping), both read and write (yes I know reading at both ends would be more efficient but I currently have no control over the software in the L24ER's).

The SLC will initiate:
1 INT write to each L24
1 FLOAT write to each L24
1 INT read from each L24
1 FLOAT read from each L24

So 16 MSG instructions in total

(if I was designing the L24 software I would have packaged my data as contiguous INT arrays, and manipulate at the other end for decimal places, and therefore halve the MSG requirements, but there we are...)

In order of timeliness (i.e how fast I need to them to update):
1. Float writes (fast)
2. Int reads (fast)
3. Float reads & Int writes (slow-ish)

My question is:
What is the most efficient way to schedule the messages? Is it:

a) Two separate incrementing and looping indexes that loops between 0 - 3 (one for fast and one for slow), that space the messaging equally so that all reading & writing to a given device is executed together (fast on the one loop, slow on the other).
i.e Fast Index = 0 = Device A Fast Write & Fast Read
Slow Index = 0 Device A Slow Write & Slow Read
Fast Index = 1 = Device B Fast Write & Fast Read
Slow Index = 1 Device B Slow Write & Slow Read
and so on...

If I did this would I need to also include an XIO on the .EN for each message as a rung condition to prevent the possibility of adding it to the queue multiple times if the index value comes back round before it has a chance to become .dn?

There is of course no guarantee that the Fast & Slow Indexes won't cross over sometimes causing them to try to fire at the same time.

b) Have each MSG .dn or .er XIC trigger the next MSG and scrap the whole fast/slow idea. Just 16 MSG's with only one firing at any one time as a cascade. I see why this is a nice approach, but if a device is out of action, I'm concerned about waiting till the timeout occurs before moving onto the next MSG. Is there a way to ensure the timing is not altered if a device is not responding? If so this seems the best approach as your are guaranteeing maximum speed at all times without the risk of overloading.

c) just not worry so much and let all MSG blocks re-fire as soon as they are .dn. Is all of the above not now a legacy issue and a properly designed ethernet network is more than capable of handling anything a PLC can throw at it?

Thanks

 

[BachPhi]

I think it's time to upgrade to CompactLogix, or just add a CL so that you will have total control & flexibility.

If you still want to insist on SLC, then use the link below for reference and adjust to your need.

I would have a TriggerRead with a index size of 8 and a TriggerWrite , index size of 8.

https://www.advancedhmi.com/forum/index.php?topic=2682.msg16114#msg16114

 

[elfrider]

I think it's time to upgrade to CompactLogix, or just add a CL so that you will have total control & flexibility.

If you still want to insist on SLC, then use the link below for reference and adjust to your need.

I would have a TriggerRead with a index size of 8 and a TriggerWrite , index size of 8.

https://www.advancedhmi.com/forum/index.php?topic=2682.msg16114#msg16114

Thanks Bach. I should have mentioned that this is only a temporary arrangement - this SLC is being ripped out and replaced with an 1756-L81E (along with all the others at this location) at the end of the year.

I guess I'll still have the same question to answer after this happens in any case.

 

[OkiePC]

I normally run message logic where I use an a block of bits to control the steps, a timer to give a little dead time between each message, and use the DN or ER bits to advance through the cycle. I also will manipulate the Timeout value for each control block (in a SLC or Micrologix) so if there is an error, I don't have to wait 30 seconds to find out and move on.

I also sometimes pack floats into integers for transport which (as you noted) would cut your total number of messages in half. Doing that would require some editing on the Logix5k end.

Note that B3:22/15 is the last useable bit in my block of three words I am using in this example and is used to ensure only one state change per PLC scan.

The FLL instruction clears all the bits (including B3:22/15) and sets the one for the next state. Rungs following rung 4 are pretty much a repeat all the way down to state 13 which has no conditions and is just use to trigger a repeat.

I write to the MTO word on first scan for all the messages to force the timeouts to 4 seconds (which I have found is more than enough time in my case with these radios to complete a message if they're going to). I think in a SLC, the Timeout value is the ninth work of the control block.

EDIT: This screenshot is from a Micrologix, but looks the same in a SLC except the MSG blocks are fatter!

 

[Bit_Bucket_07]

You could do your writes on exception by adding logic to determine if the source value has changed since the last program sweep (or since the last predetermined time interval). That might be helpful in reducing traffic if the values in your source registers for your writes aren't constantly changing.

 

[rdrast]

For all that messaging, and your restrictions, have you considered just using a Red Lion DataStation to handle all comms? Reading from the one PLC, writing to the others?

 

[elfrider]

Thanks all for the help, I think I have enough info now to get the right scheduling set up. I guess as ever there’s more than one way to skin a cat so to speak!