Transferring Discrete Data (AB PLC 5)

[mdeltat]

I'm tring to understand how discrete info is being communicated between two AB PLC 5's on the DataHwy. The data is in an output file (O:31)of the source PLC and it winds up in an input file (I:31) of the destination PLC. Can someone please explain how this is setup?

Also, if I trace a bit back to some data file (lets call it B10:9/3)and there are no more references to the bit in the program file, I can assume that the bit is being put there in some other way such as a cop, mov, bt, or msg etc. But how can I efficiently find out where this bit comes from without just looking around in the program for some instruction that might be related? The problem is that cross-reference doesn't work because the bit is only one element in an entire word or set of words.

Thank You

 

[Ken Moore]

There are many,many ways to transfer data between 5's. It could even be hardwired. Have you looked for read and write msg's in both processors?

There may be a MOV instruction that moves the output word to an N file, and then the MSG moves the N file, just guessing.

 

[OkiePC]

It's very possible that they are connected not by DH+, but by RIO. You can set one up as a scanner and the other as an adapter and map data tables between them. If this is the case, there may not be any visible commands to send data, it is handled automatically. To find out, you will have to look closely at the channel setup for both PLCs.

 

[Ron Beaufort]

Greetings mdeltat ...

and welcome to the forum ... I’ve got a hunch that my distinguished colleague OkiePC has come up with the right idea on your first question ... although my colleague Ken Moore (also distinguished) could of course be correct too ... anyway ... one possible source of confusion is that just because you see “blue hose” connecting two PLCs does NOT necessarily mean that DH+ (Data Highway Plus) is being used ... specifically, the same “blue hose” can also be used for RIO (Remote I/O) too ...

if OkiePC has guessed correctly, then the answers that I recently posted in this thread on another forum about running a PLC-5 in “adapter” mode should help you understand what’s going on ...

as for your second question ... finding the “control” for something like bit B10:9/3 can be more involved than many people think ... here are some ideas that might help ...

first of all (and simplest) bit B10:9/3 could be controlled at the “bit level” by something like an OTE instruction ... IF (big IF) it is, then the software should show you an “X” when you access the “Usage” feature for the B10 data table ...

next ... bit B10:9/3 could be controlled at the “word level” by something like an MOV instruction ... IF (big IF) it is, then the software should show you a “W” when you access the “Usage” feature for the B10 data table ...

next ... bit B10:9/3 could be controlled at the “file level” by something like a COP instruction ... IF (big IF) it is, then the software should show you an “F” when you access the “Usage” feature for the B10 data table ...

those are the most common ways that bit B10:9/3 MIGHT be controlled - and the simplest indications of how each of those control methods MIGHT be shown on the data table ...

in any of the cases listed above, using a “Find All” search with the “*” as a “wildcard” MIGHT help you track down the controlling instruction ...

going further ... “indirect addressing” might also be involved ... here are some of the things we normally look for in this situation ...

first notice that bit B10:9/3 can also be referred to as bit B10/147 ... here we’re using N7:0 and N7:1 as “pointers” to “indirectly address” the bit ... and this method might be quite tricky to track down ... for one thing, “indirect addressing” does NOT register on the data table when you select the “Usage” feature ... personally I always do a “Find All” search for ONE (and only ONE) of the “[]” square bracket characters when I suspect that “indirect addressing” might be involved - since those characters are always included in an “indirect address” ... then you’ve got to determine just what range of values MIGHT be entered into the “pointers” in order to nail down which bits are being addressed ...

finally (at least for now) in some systems it is also possible that bit B10:9/3 is being controlled by an HMI/SCADA system ... for example: RSView32 or Wonderware running on a networked computer might be controlling the bit ... or a PanelView system might be involved ...

I hope that some of these ideas will help you on your way ... wish I had more time ...

 

[jdbrandt]

I'm tring to understand how discrete info is being communicated between two AB PLC 5's on the DataHwy. The data is in an output file (O:31)of the source PLC and it winds up in an input file (I:31) of the destination PLC. Can someone please explain how this is setup?

Also, if I trace a bit back to some data file (lets call it B10:9/3)and there are no more references to the bit in the program file, I can assume that the bit is being put there in some other way such as a cop, mov, bt, or msg etc. But how can I efficiently find out where this bit comes from without just looking around in the program for some instruction that might be related? The problem is that cross-reference doesn't work because the bit is only one element in an entire word or set of words.

Thank You

Two questions, two answers:
1 (Assuming you mean 'access over data highway', or 'transfer over data highway', and NOT 'update VIA datahighway"....) One of the ways I'm surprised that nobody mentioned (yet) is the Data Highway Station Status Word (perhaps the wrong name...its been a while). The way this works is that you assign a register to the Data Highway status word (normally, its unassigned), and, then, when you write to any of its 16 bits, these 16 bits end up going around the DH+ and ending up in EACH PLCs Station Status File (also a configuration setup). In this way, each stations puts 16 bits 'on the highway', and, when each station gets the token, it updates its particular bits, and reads everybody else's. Pretty cool, and, no specific MSG-type instructions to deal with. And, it hardly slows down the DH+ or the program scan, since its already a feature of the DH+.

2 Now, if you have unknown bits coming from unknown locations, the only way to find them is with a cross reference printout from the ladder software. IF a bit is used as part of a word, you must also look at the word references to that bit (in your example, B10:9). BUT (caution), don't assume that the bit is actually used as an output anywhere. You could be looking at left over programming from a previous version, or something that someone tried during commissioning, or similar such 'dust balls'. Also consider that these may have come in from an indexed routine, so, in your example, you'd want to also look at B10:0, B10:1. Worse yet, the file number is able to be indexed as well, so you'll have to look at Bxx:10/9, where xx equals any integer or binary file. If you have three routines, all acting on three identical devices, perhaps the orignal programmer used indirect addressing to make his life easier (and your live more complicated). In your cross reference, these will stand out like a sore thumb, with an arcane looking address reference like: B[N7:12]:9/3.

Good Luck

(Ron's reply (above) is certainly more detailed than mine, but, we were both typing at the same time....he beat me to the ENTER button.)

 

[Ron Beaufort]

and one more thing that I forgot to mention ... make SURE that the entries shown below (for GLOBAL and WRAP ON) are set correctly before doing any “Find All” searches ...

while my distinguished colleague jdbrandt is certainly correct about how the “Global Status Flags” feature can be used to transfer information over the DH+, I personally passed over that scenario in your case - since you mentioned only the Input and Output data tables in your problem statement ... basic idea: the Global Status Flags feature usually involves setting up N-type (integers) for the communications buffer ...

Ron ... beat me to the ENTER button.

now that’s something that doesn’t happen very often ...



finally ... if you need further help finding your bit references, consider posting your .RSP file ... there are a LOT of people here who are qualified to help you track down whatever it is you’re looking for ...

 

[mdeltat]

Thank You

Wow! I didn't expect replies this thorough and prompt. Thank you gentlemen for taking the time to help me out. I'll review the posted information and reply soon.

Thanks Again

 

[Doug-P]

I also would agree with OkiePC. The default rack address for a PLC-5 in adapter mode is rack 3. This lines up with the I:31/x and O:31/x shown. I:30/x is reserved for status information. It appears someone set up discrete data transfer through the I/O system using pretty much the basic guidelines in the manuals.

 

[mdeltat]

OK, I checked it out and indeed it is set up in adapter mode and the other is in scan mode. What resources do you guys recommend for learning about this and RIO in general?

 

[OkiePC]

Look at ab knowledgebase technote ID 17673 formerly G17837.

Here is a link to the word doc it contains...not sure this link will work...

http://rockwellautomation.custhelp.com/cgi-bin/rockwellautomation.cfg/php/enduser/fattach_get.php?p_sid=eirx4EBi&p_accessibility=0&p_tbl=9&p_id=17673&p_created=1171051372&p_olh=0

 

[mdeltat]

Thanks for the coaching Okie. Also, thanks to everybody for your help with a special thanks to Mr. Beaufort for the thoroughness of your reply. It has lead me down several new paths to better understanding many more aspects of PLCs.

 

[Ron Beaufort]

Greetings mdeltat ...



you’re quite welcome to any help that I was able to provide ... but as I looked back over one of my previous posts above, I noticed that I had somehow left out a link that I meant to include ...



click here and see if the material I posted there helps you with the adapter mode ... sorry I failed to include that earlier ...