SLC505 MSG Reads - Best Structure for an 8 device Network

[lectropop 0]

Still transitioning into the AB world, trying to figure out how it all works! I am hoping to interface 6 new MicroLogix 1400 controllers and 1 new SLC505 with an existing SLC505 for a distributed waste-water control system. The controls and logic need to be responsive within seconds, not milliseconds. All controls will be utilizing a fast Ethernet network, all local to the same subnet. Having read up a bit on the MSG command, I believe I will want to implement a read-only strategy (each device will poll a remote device for its data, no remote writes required) as others have described this as a faster routine with less overhead (1 request vs 2 with handshaking?). Any reason not to go this route? For Ethernet Channel Configuration - Multihop - I assume the SLC505 and Micrologix 1400 both support this version of the protocol? I will use this for all message types if this is the case. For communication heartbeat - I am planning to use the MSG error bit and a timer to alarm on loss of comms. Is this sufficient, or should i try to reinvent the wheel and implement my own explicit heartbeat? From what I've gathered the SLC505 can support up to 16 Ethernet channels at a time (I should only have a max of 8 possible, 9 counting the HMI), and up to 4 messages can be processed simultaneously with up to 10 more in a wait buffer. I am going to put the MSG commands in their own unconditional subroutine - Should I add conditional logic to each message rung such that the first message has to complete before the second, and on down the line, or just let the processor handle it? Do the MSG commands need to be supervised by a timer (example: rung is true once every 5 seconds) or can they be held true for every scan? Thanks for the sanity check! Ben

[b_carlton 61]

We handle all messaging with interlocks. I seem to get in trouble when I trust the 'buffers'.

[BobLfoot 302]

+1 to b_carlton for interlocks. The messgae buffer can be a tricky thing to guestimate. I'd recommend your unconditional messageing ladder file use some form of sequencer or state machine. SOmething like the following. Step 0 - CLear all message DN and ER bits to zero, set Step 1 Step 1 - Trigger Message Read From PLC 1 and wait for DN or ER bit then set Step 2 Step 2 - Trigger Message Read From PLC 2 and wait for DN or ER bit then set Step 3 Step 3 - Trigger Message Read From PLC 3 and wait for DN or ER bit then set Step 4 ... .... ..... Step 8 - Trigger Message Read From PLC 8 and wait for DN or ER bit then set Step 9 Step 9 - Reset step count to step 0 You can probably let this run as fast as reasonable, but you may find depoedning on your subnet and hardware you want a pause timer between steps.

[rguimond 1]

I "cascade" them. On the first scan, start the MSG#1. The second one starts when the DN, ER or TO bit from MSG#1 is set. I also unlatch the EN bit for MSG#1 (probably no good reason to, but I do). MSG#3 starts when MSG#2 is DN, ER or TO.... Under the "first scan" bit for MSG#1, put in branches for the last MSG DN, ER & TO. Edited 16 Oct 2012 by rguimond