View Full Version : SLC500 Peer to Peer comms.

March 31st, 2005, 02:14 PM
I could use some help on SLC500 Peer to Peer comms.
Specifically, I have 2 5/05 processors. Master and slave for clarity's sake. They are on a common ethernet hub.
What I need to do is have the slave call the master's I/O table image and place these images into an N: file in the slave.
What I do understand is I'll be using the MSG command. However AB's documentation of this command in the instruction reference leaves a little bit to be desired. I do have Publication 1747-RM001D-EN-P so please feel free to reference this doc.
I am also wondering about how much overhead this is going to produce in
a- the master SLC, and
b- on the network.
I'll be calling for all 16 bits on 15 digital I/O cards.
This is not time critical data (around 1sec is plenty of responce time) so should I only call the MSG instruction say every 20-50 scans? (using a CTU-RES combo)
Any help would be greatlt appreciated.

March 31st, 2005, 02:55 PM
I am sorta thinking you are overthinking this.

Since you are messaging 15 words of information every second, you might want to rethink that too, but, when you set this up, write your i/o cards info to the N File in consecutive words. Use a self resetting timer (1 second) to activate the message instruction. Set up your destination address and destination file in the message write. Your done.

If you are doing this with several SLC's, then another approach would be better. But since you are only using 2, then I think you will be fine.


March 31st, 2005, 06:08 PM
Read don't write. I don't want PLC "A" to control PLC "B". I think PLC "A"
should be in control of itself. IMHO

March 31st, 2005, 08:09 PM
This thread may help

Derek McFarland
March 31st, 2005, 11:02 PM
I agree with Mickey that Reads should be preferred as it can be difficult to determine where written data is coming from if not documented in the destination. This is wore than the duplicate coil "gotcha".

In addition to David's suggestions you am consider adding a watchdog to the data so that you can determine when the link is lost. If the link is lost the watchdog will time out and the dta can be set to safe state.

I typically set up bi-directional reads with watchdogs both ways when adding messaging. You will have to edit both PLCs anyways, so why not while you'll there? In the source PLc the data to be read usually has to be "collected into an array that is read and tin the destination PLC, the MSG logic, etc needs added. Once the messaging infrastructure is in place, many uses will become apparent.

April 1st, 2005, 07:18 AM
Thanks very much. Awesome suggestions!