Bit/word swapping between PLC's over a network

[sparkotronic 0]

Hi, Firstly I'm a complete noobie when it comes to AB. I've just started a new job and all their PLC's are AB, I've always worked with Siemens. I'm trying to trace where a bit goes in a project, I've managed to trace it to a COP(copy file) function. As far as I know these are either written to or from another PLC on the network. My question is, how do I find out which PLC it is going to and what it's address will be when it gets there. Here is where the bit is used. And here is where it originates from. I'm assuming that #N20:12 originates from another PLC as I cant find it anywhere on this project. There must be a way where I can see exactly where it is going? Any help would be most appreciated! Regards, Colin

[Guest]

Greetings Colin ... sorry – but your assumption is incorrect ... look at the far left of your RSLogix screen – in the "Controller Organizer/Tree" area and you should see a little blue "file" icon representing integer file N20 ... open that and navigate to N20:12 ... the COP (Copy) instruction you have shown is copying the BIT PATTERN (16 ones and zeros) from word N20:12 and placing the copy into the word B203:25 ... DISCLAIMER: the screen shot that you've posted is rather blurry – even when I enlarge it ... the addresses I've mentioned above might not be correct because I can barely make out the text on the screen ... suggestion: if you have more questions, it would be a good idea to post your entire PLC program file so that we can help you track this stuff down ... tip: for Allen-Bradley systems, moving data between PLCs over a network connection is USUALLY (but certainly not always) done with an MSG (Message) instruction ...

[MacSparky 0]

Hi, the way it handles the B's and N's isn't that much different from Siemens, it's just what happens after which confuses me! On Siemens I would be able to trace it through the network settings. Is there a bit in RSlogix where you set up the communications? I've trailed over the program and I did find a block with lots of MSG functions in it, but none that mentioned N20:12. Could it be sent out in some other format? Regards, Colin I had to change user name to get email up dates, for some reason it kept telling me that my email was in use when I tried to change it! Edited 3 Nov 2010 by MacSparky

[OkiePC 14]

It is very possible that one of your MSG instructions is sending or receiving data that includes the Integer which contains the bit you are concerned with. I would suggest that you open the data table (In the tree, double click on the data file "N20"), and click on the Usage button. Every address that is being used by the program will have an "X" in its postiion. Then you can find the word of concern, and look for the group of data that shows usage, find the first used word of that group, right click it, and select find all. You might find that there's a message starting with N20:10, for example and the message might be 8 words in length, so it would include N20:12. Also, I would suggest that you zip the .rss file and attach to a post here (if your company allows this). Then, we can look at the file and help you track down the source of your bit. Edited 3 Nov 2010 by OkiePC

[paulengr 44]

The "cross reference" function will show you address by address (or block by block) which lines are accessing which block of memory, in most cases. It does not handle indirect addressing very well so watch out for that. In fact I go out of my way to document these. Also, cross-PLC messages have issues as well. A READ type MSG instruction is easy and will show which data block is being written in the cross reference. The instruction itself will document where it is reading from but there will be no indication on the remote PLC that data is being read from it. The WRITE type instructions are even worse. You can see the source data but there is no documentation in the destination. I highly recommend for this reason plus an efficiency reason (writes take a 3-way handshake, reads only take 2) that you use READ's and not WRITE's whenever possible. There is of course an exception. If the data is being transferred asynchronously and not very often (such as batch information) then continuous periodic READ's are a waste and in that particular instance, I'd recommend WRITE's. If I write the code and I'm using a WRITE or indirect addressing, I normally insert something like "COP #N20:0 #N20:0 10" which means to copy addresses N20:0-N20:9 on top of itself (a harmless instruction), preceded by an AFI (always fail) instruction. That way this block never executes. HOWEVER, I can also attach documentation to the rung AND it will nicely show up in the cross reference utility so that either my successor or myself can figure out what's going on in the future without struggling as you are doing.

[Guest]

I took that statement to mean that the word "THESE" meant COPy instructions – which were being "written to or from" another PLC processor ... naturally that does NOT happen ... so ... the suggestions that I made still seem to make sense (at least to me) based on how I interpreted the OP's statements ... but ... based on the way that you guys are interpreting those same statements, I'll graciously allow that you're probably correct ... (don't you just love this job?) ... finally ... wouldn't it be nice to have the OP's program file available so that we could nail all of this down without having to "assume" what's really going on? ... party on ...

[MacSparky 0]

I worked it out going backwards. PLC J Bit B203/403 Read as B203:25/5 PLC K In as B403:29/5 out as B203:25/5 PLC Hydro In list as B203/469 It was more down to luck than skill though! The words were transferred PLC to PLC by MSG functions Now for another question! Using the above MSG as an example, say that I was on the ladder for the target device and I'm looking for where B403:29/1 is being written from, Can I find this out on the existing project or do I need to go through all the MSG functions on each PLC in the network till I find it or is there a more scientific(easier!) way? Thanks for your help so far, Colin

[b_carlton 61]

Not that I know of.

[Guest]

I second Bernie's answers ... here's a potential "gotcha" for your future reference ... the phrase "Target Device" should instead say "Other Device" ... specifically, the phrase will NOT change to say "Source Device" when you do a READ instead of a WRITE ... this has confused many people in the past - when they've assumed (incorrectly) that the "target" is necessarily the DESTINATION of the data transfer ... Edited 7 Nov 2010 by Ron Beaufort

[MacSparky 0]

Well that kind of sucks.......looks like I'm in for some fun fault finding then, bring back Siemens, all is forgiven!

[b_carlton 61]

You should be able to search for 'MSG' in the software. After you find them it's Document-Document-Document especially in the target programs.