Indirect Address

Good day all. I have an alarm that has been triggered and I can't figure out what is triggering it. When I go to the alarm table it shows an indirect address (LAD 9- ALARMS on attachment). Rung 0011 has a NEQ instruction with Source A B52:[N14:201]. When I go to the data table I can't see what in specific is triggering this alarm. Ron explained indirect addressing to me, however, I still don't understand them. Any help would be greatly appreciated. Thank you

I think I am following this correctly...

File B50 is the actual alarm table. It gets OR'd with the UNACK'd alarm File B53 to create alarm file B54. So B54 could be called the current OR unacknowledged alarm table since it will contain a "1" for each alarm that exists or did exist and was never acknowledged.

File B52 is the NEW alarm table. It will only have a "1" in a spot when an alarm first occurs. It's sole purpose might just be to seal in the NEW ALARM bit on rung 11. It is created by AND'ing file B50 with file B51. B51 is the inverse of B50. So, file B52 will only show a 1 when there is an actual alarm, one that wasn't there during the previous scan. Since the bit that triggers rung 11 to seal in will only be true for one scan, then you will probably never see it by looking at that particular file.

To find out what is causing the alarm in the first place, look in file B50, and backtrack search the individual bits.

The indirect addressing used in this program is set up so that every other PLC scan, the pointer N14:201 is incremented, going from 0 to 4 and then back to zero again, so you're only concerned with words 0-4 of your alarm files.

Just like Paul has explained.... I have seen this several times and its a good programming idea

The first alarm is the one that your operators/engineering should be looking at, in the system I have worked on the first alarm would cause many others to happen but were not the reason for the shut down, the first alarm was and this was the one that needed to be addressed.

If there is an HMI on the same system they may list several alarm conditions but this one may flash on the screen but the others may show up in a history file

Ron explained indirect addressing to me, however, I still don't understand them.

Click to expand...

I think it would be more correct to say that you don't "remember" what I explained ... I can assure you that you DID understand indirect addressing when we had that free 2-hour emergency crash course on the phone a few weeks ago ... I am 100% CERTAIN that you understood the concepts at that point in time because I tested you with several questions – and you gave me the correct answers ...

moving right along, based on what you've posted above, I'm guessing that your biggest problem right now is NOT that you don't understand "indirect addressing" – but rather that you've having trouble interpreting the Bitwise AND instruction – and the Bitwise Inclusive OR instruction ...

my distinguished colleagues OkiePC and geniusintraining have already given you excellent advice ... here's another tip that might help if you're still having trouble ...

if the indirect addresses are confusing you, just temporarily REPLACE the indirect addresses with "regular" addresses ... for example: at the specific point in time that the program you've attached was saved, the indirect address "pointer" N14:201 contained the value 3 ...

so ...

temporarily change the indirect addresses involved in your current "problem" area as follows:

change B51:[N14:201] to B51:3 ...
change B52:[N14:201] to B52:3 ...
change B53:[N14:201] to B52:3 ...

the program will now execute EXACTLY the same way that it would have executed using the original indirect addresses – at least at that one specific point in time ...

now with the confusing indirect addresses out of the picture, you can attack the ANDing and the ORing operations with ZERO worries about "indirect addressing" ... the idea is to "divide and conquer" – or in other words, to set things up so that you can concentrate on just ONE problem at a time ...

STOP! ...

you should NOT do this "temporary change" trick on an operating machine – unless you are 100% certain that it will be SAFE to do so ... this is a teaching/learning tool ... if you change out the indirect addresses this way, then the "incrementing" action that OkiePC was talking about will no longer work – and your system might miss some important alarms ...

but ...

the "temporarily-change-the-address" trick that I've just shown you helps MANY students get past their initial confusion regarding indirect addressing ... it certainly wouldn't hurt to make the change on an offline "backup" file – and then see if that helps you understand more about the nuts-and-bolts of how the alarms work ... you might also run the modified rungs in a spare processor if you have one available ...

I hope this helps ...

despite your present confusion, it certainly seems that you're making significant progress beyond where you were when you first started this project ...

Thanks guy's.