need help understanding code

[donles 0]

I'm trying to understand how a particular alarm detecting subroutine works and I'm stuck on some FAL instructions. The plc is a AB PLC 5/40e. The main ladder logic runs pumps, motors, valves , etc. and programming for each device looks for feedback from pressure switches, auxillary contacts, etc. to confirm operation. For instance, if a motor failed to start the code would turn on N11:0/2. The main ladder jumps to an alarm-search subroutine and then the alarm sounds. The first FAL instruction is: Control R6:0 Length 10< Position 0< Mode ALL Dest #N11:20 <8 Expression #N11:0 AND -1 2'nd FAL Control R6:1 Length 10< Position 0< Mode ALL Dest #11:40 <0 Expression #N11:20 XOR #N11:30 3'rd FAL Control R6:2 Length 10< Position 0< Mode ALL Dest #11:40 <0 Expression #N11:40 AND #N11:20 Then FSC Control R6:3 Length 10< Position 0< Mode ALL Expression #N11:40>0 The R6:3 IN bit will go high if there is an alarm condition. I'm having difficulty understanding what the FAL's are doing. An explanation is appreciated as is a pointer to some related reading. Thanks donles

[Guest JIMMY]

Looks Like the first FAL compares the alarm words R6.1.0 through R6.3.10 and if there is a bit "on" then it moves the word to the "alarm scratch pad area" call N11:20. On the next scan of the PLC any new alarms detected between scans will be caught. Your logic probably has the real world inputs tied to the outputs R6.x values in the logic somehow. These output values make up the alarm words R6.1, R6.2, R6.3,

[Guest]

Greetings donles, adding a little to what Jimmy has already posted ... you should begin your research by reading all of Chapter 8 in the: PLC-5 Instruction Set Reference Manual this will help you understand how “file” operations are handled in the PLC-5 ... next read the detailed information about the FAL (File Arithmetic Logic) instruction which begins on page 9-2 ... skip over the “status bits” to begin with (come back to them later) but pay close attention to the information about how to set up “expressions” ... there is an example of a logical OR expression on page 9-13 ... this should help you understand how your program makes use of the similar AND, and XOR functions ... you’ll also want to study the information on the FSC (File Search and Compare) instruction which begins on page 9-14 ... note: if you're not sure about how the AND, OR, XOR functions work, you can find more about them in Chapter 5 ... when dealing with “files” here is a general (simplified) tip: when you see the # character in an Allen-Bradley address, you may interpret it as meaning “the file begins here” ... using that (simplified) tip, your first FAL will do the following each time it executes: the 16-bit word located at N11:0 will be logically ANDed with the value “-1” ... note that “-1” effectively means “all 16 bits are set to 1” ... so this operation will actually just copy the on/off status of all 16-bits from word N11:0 into the first destination word N11:20 ... then (on the same execution) the 16-bit word located at N11:1 will be logically ANDed with the value “-1” ... again note that “-1” effectively means “all 16 bits are set to 1” ... so this operation will actually just copy the on/off status of all 16-bits from word N11:1 into the second destination word N11:21 ... then (on the same execution) the 16-bit word located at N11:2 will be logically ANDed with the value “-1” ... again note that “-1” effectively means “all 16 bits are set to 1” ... so this operation will actually just copy the on/off status of all 16-bits from word N11:2 into the third destination word N11:22 ... this same pattern will continue for a total of 10 such operations (all on the same execution) since the FAL has a “length” specification of 10 and a “mode” specification of ALL ... in other words, the first FAL merely copies the contents of 10 words beginning at N11:0 into 10 words beginning at N11:20 ... the original programmer probably had a “store-the-information-in-a-buffer” operation in mind ... the second FAL will do the following each time it executes: the 16-bit word located at N11:20 will be logically XORed with the 16-bit word located at N11:30 ... the results of the XOR operation will be stored at N11:40 ... then (on the same execution) the 16-bit word located at N11:21 will be logically XORed with the 16-bit word located at N11:31 ... the results of the XOR operation will be stored at N11:41 ... then (on the same execution) the 16-bit word located at N11:22 will be logically XORed with the 16-bit word located at N11:32 ... the results of the XOR operation will be stored at N11:42 ... this same pattern will continue for a total of 10 such operations (all on the same execution) since the FAL has a “length” specification of 10 and a “mode” specification of ALL ... it’s hard to say since I can’t see your entire program, but my guess is that the original programmer probably had a “find-out-which-alarms-are-old-and-which-alarms-are-new” operation in mind ... the third FAL will do the following each time it executes: the 16-bit word located at N11:40 will be logically ANDed with the 16-bit word located at N11:20 ... the results of the AND operation will be stored right back into N11:40 ... then (on the same execution) the 16-bit word located at N11:41 will be logically ANDed with the 16-bit word located at N11:21 ... the results of the AND operation will be stored right back into N11:41 ... then (on the same execution) the 16-bit word located at N11:42 will be logically ANDed with the 16-bit word located at N11:22 ... the results of the AND operation will be stored right back into N11:42 ... this same pattern will continue for a total of 10 such operations (all on the same execution) since the FAL has a “length” specification of 10 and a “mode” specification of ALL ... since I can’t see your entire program, your guess is as good as mine what the original programmer had in mind with this particular operation ... the FSC (File Search and Compare) will do the following each time it executes: the 16-bit word at N11:40 will be inspected to see if it contains a value greater than 0 ... usually we examine the FD (Found) bit to see if the inspection is true ... the original programmer might have examined the IN (Inhibit) bit instead ... then (on the same execution) the 16-bit word at N11:41 will be inspected to see if it contains a value greater than 0 ... usually we examine the FD (Found) bit to see if the inspection is true ... the original programmer might have examined the IN (Inhibit) bit instead ... then (on the same execution) the 16-bit word at N11:42 will be inspected to see if it contains a value greater than 0 ... usually we examine the FD (Found) bit to see if the inspection is true ... the original programmer might have examined the IN (Inhibit) bit instead ... this same pattern will continue for a total of 10 such operations (all on the same execution) since the FSC has a “length” specification of 10 and a “mode” specification of ALL ... I can’t see your entire program, but my guess is that the original programmer was searching to see if any “new” alarms were present anywhere in the 10-word file which begins at N11:40 and goes through (and includes) N11:39 ... disclaimer: most of this has been written with a lot of “copying and pasting” ... also I’ve been answering a few customer calls while writing it ... naturally there is a definite possibility that I’ve dropped a stitch here and there ... if so, I apologize in advance ... in addition, some of your address entries contain obvious typographical errors ... I’ve made some assumptions (gosh I hate that word) where necessary ... hopefully I came close enough to make the information useful ... I hope this helps ... post again if you have further specific questions ... and welcome to the forum ... best regards, Ron Edited 4 Feb 2005 by Ron Beaufort

[Guest]

and with no offense intended to Jimmy ... the "Control" entries R6:0 through R6:3 will not contain the “alarm” information ... in an Allen-Bradley system, the R6:__ “Control” structures are used as “pointers” to help the processor keep track of “where-in-the-file” he’s presently located ... consider: “T4:__” is used to “time” ... “C5:__” is used to “count” ... “R6:__” is used to “point” ... think of the R6:__ “control” as being an “electronic finger” which the processor runs down through the file structure (example: from N11:0 through N11:9) as it works its way through each of the steps of the FAL or FSC operation ... it will be easier to understand this concept if you’ll research the FAL’s “Position” entry (example: R6:0.POS) ... the “Position” value is similar to a timer’s “Accumulator” ... but instead of tracking elapsed time, the "Position" value keeps track of “how far” down through the data file the instruction has come ... best regards to all, Ron Edited 4 Feb 2005 by Ron Beaufort

[Guest]

Greetings donles, I had a few spare minutes and decided to share this possible issue with you ... the expression “#N11:40 > 0” which you listed for your FSC instruction MIGHT have a “bug” in it ... here’s what I’m talking about ... first suppose that N11:40 contains a pattern of ALL bits turned OFF ... in that case, the value of N11:40 would NOT be GREATER THAN 0 ... and the FSC expression would test FALSE ... the original programmer probably anticipated this ... now suppose that N11:40 contains ANY pattern of bits turned ON ... EXCEPT bit N11:40/15 which is OFF ... in that case, the value of N11:40 WOULD be GREATER THAN 0 ... and the FSC expression would test TRUE ... the original programmer probably anticipated this ... now suppose that N11:40 contains ANY pattern of bits turned ON ... AND that bit N11:40/15 is ON ... oops! ... bit /15 is the “sign bit” ... when this bit is ON, the value in the integer word will be a NEGATIVE value ... in that case, the value of N11:40 would NOT be GREATER THAN 0 ... even though some “alarm” bits would still be ON ... and the FSC expression would test FALSE ... indicating “no alarms present” ... the original programmer probably did NOT anticipate this ... basic idea ... many programmers think about it this way: “if ANY bit in the word is ON, then the value of the word will certainly be GREATER THAN 0 ... so I’ll just test to see if the value of the word is GREATER THAN 0 ... if it is, then I’ll know that at least one of the bits in the word is ON” ... unfortunately that approach fails to consider the “sign bit” of an integer word ... specifically, if the “sign bit” (bit /15) is ON, then the word will have a NEGATIVE value ... and if the test is based on the word’s value being GREATER THAN 0, then the test will fail to recognize the ON status of ANY “alarm bits” which happen to be turned ON ... since I can’t see all of your program, I can’t tell you for sure whether this is (or is not) an issue ... but it’s definitely something that you need to consider ... IF (big if) there is the possibility that the /15 bit in any of your “alarm data” words could ever be used to signify an “alarm” condition, then there is a definite possibility that an alarm involving that bit might not be properly registered ... the term “bug” comes to mind ... suggestion: consider changing the expression for the FSC to the following: “#N11:40 <> 0” ... this particular expression will test TRUE if the value in the word is NOT EQUAL TO 0 ... specifically, now if ANY bit within the word is turned ON (even the “sign bit” /15) then the expression will test TRUE ... this is probably the way that you want the program to function ... disclaimer: remember that I can’t see all of your program ... there is a definite possibility that the issues that I’ve raised here are nothing to be concerned about ... but I just thought that I’d pass this information along for what it’s worth ... you might find it helpful ... best regards, Ron Edited 5 Feb 2005 by Ron Beaufort

[donles 0]

Ron, Thank you for your detailed answer to my question. I've read through it once and will go over it again now with my program code handy. I'll look for the typos that you mentioned. I thought that I was accurate with the instructions but it's easy to do. Thanks again, donles

[Guest]

Greetings donles, I wouldn’t get too hung up on the typo’s if I were you ... you’ve got bigger fish to fry ... but here are a couple of “corrected” examples: these are MINOR and my assumptions are probably close enough to what you meant ... the issue with things like this is that even though they themselves might be MINOR, they tend to call into question other things that might be MAJOR ... for example: is the original expression of your FSC really and truly “#N11:40>0” as you posted? ... or could you have simply dropped a stitch and really meant to say “#N11:40<>0” instead? ... all in all though, you did a VERY good job of describing your program ... I couldn’t have put anything near the same amount of detail into my answer if you hadn’t ... good luck ... keep us posted ... best regards, Ron

[donles 0]

[Gerry 13]

Unless the original programmer avoided the use of bit 15 in the alarm words, you should definitely alter the expression to test "not equal to" rather than "greater than" zero. The FSC will find the first occurence satisfying the test expression. If all of the words are not not equal to zero (i.e. they are all equal to zero) then the FSC will complete with its done bit(DN) on and its found bit(FD) off. This is the condition you should look for to determine that there are no alarms (done and not found). You shouldn't need a second FSC. An FSC with length of one can be replaced with one of the compare instructions. Edited 10 Feb 2005 by Gerry