Ron Beaufort
Lifetime Supporting Member
this is WAY up there on the Weird-O-Meter ...
DISCLAIMER: THE CONCLUSIONS BELOW ARE BASED ON THE "STRIPPED DOWN" PROGRAM WHICH WAS POSTED ... HAVING THE FULL PROGRAM AVAILABLE MIGHT LEAD TO DIFFERENT CONCLUSIONS ...
first of all, this appears to be a program from an SLC processor (SLC-5/03 or higher) which has somehow been "shoehorned" into a MicroLogix 1000 ...
the program makes use of data files which do not even exist ... (example: F10 and F205 – among many others) ... it's impossible to track down how the data is intended to be used – when the data doesn't actually exist ... we need the "real" file in order to nail everything down ...
another weirdness is that Ladder #16 (which incidentally DOES contain some pretty important looking code) is set up as a "Debug" file ... debug files like this do not get downloaded to the processor – and so the JSR which would try to call the "Debug" file would generate a runtime fault ... what's going on here? ...
another weirdness ... someone has apparently tried to program an STI (Selectable Timed Interrupt) operation in Ladder #4 ... their use of the STS instruction for this purpose is VERY unorthodox ... personally, I've been working with PLCs for over 20 years and this is the FIRST time I've ever seen this type of instruction used ... in fact, I had to read the "book" to get an idea of what it does – and frankly I think that the "book" has an error in it ...
specifically, consider the phrase:
my initial tests show that the wording should be corrected along these lines:
specifically, as long as the STS rung stays TRUE, I was unable to get the STI to execute at all ... (disclaimer: I haven't completely tested this as far as I want to – but I'm 99% sure that my conclusions are correct) ...
also, someone has programmed STE and STD instructions WITHIN the STI file itself ... I've got a hunch this isn't going to work either ... I'll test it later as time permits ...
note that Rung #3 in Ladder #2 has a JSR instruction to "call" Ladder #4 (the would-be STI file) ... the XIC on this rung uses an undocumented bit B14/150 which is apparently not controlled by anything in the program ... I'm just GUESSING here – but possibly when the programmer couldn't get the STI to function properly, this rung was added as a "temporary" patch which could be manually toggled on or off for testing/debugging purposes ...
now on to the S:24 concerns that initiated this thread in the first place ...
DISCLAIMER: THE CONCLUSIONS BELOW ARE BASED ON THE "STRIPPED DOWN" PROGRAM WHICH WAS POSTED ... HAVING THE FULL PROGRAM AVAILABLE MIGHT LEAD TO DIFFERENT CONCLUSIONS ...
as near as I can tell, the only things in this program which could have left S:24 at a value of "3" would be the FFL located in Ladder #20 – or the matching FFU – also located in Ladder #20 ...
this FFL and FFU arrangement is apparently being used to track data which is taken from zones "prior to" or "after" a piece of Minster machinery ... I'd bet significantly more than pocket change that this FFL/FFU setup caused the value of "3" to be left in S:24 ...
there are quite a few COP instructions in this program which also make use of (and could alter) the value stored in S:24 ... based on what has been posted, all of the COP instructions are either:
(1) not being executed (due to the faulty STI arrangement) ... or ...
(2) being executed only on the First Pass of the processor when it enters the Run mode ...
moreover, a COP instruction will normally return S:24 back to a value of "0" at the end of its execution ...
conclusion: none of the COP instructions were responsible for the "3" value of S:24 which has been causing concern ...
the only other obvious use of S:24 is apparently in numerous MUL instructions ... one example (shown below) is the MUL located on Rung #6 of Ladder #17 ... note that I am unable to fully track the operation of these MUL operations since the data that they use does not exist in the data tables of this "stripped down" program ... specifically, F10:19 and F205:0 do not exist – and therefore I can't tell exactly how the original program made use of these locations ...
at this point, my best GUESS is that:
(1) the "#" characters denoting Indexed Addressing (using S:24) were entered by mistake at some point in the past ... or ...
(2) that the "#" characters were (or still are) part of an attempt to have the MUL operations "track" simultaneously with the data being handled by the FFL and FFU operations ...
note that the same basic pattern of MUL instructions is present at:
Rung #6 - Ladder #15 ...
Rung #6 - Ladder #16 ...
Rung #6 - Ladder #17 ...
Rung #6 - Ladder #18 ...
Rung #6 - Ladder #19 ...
this is a recurring pattern which makes reference to "INVERTED REFERENCE" for each of several "punches" ... it's very interesting that SOME of the addresses used in these MUL instructions have the "#" character – but then other corresponding addresses do NOT ...
once again, I can't tell for sure what's going on here without seeing the original program ...
DISCLAIMER: THE CONCLUSIONS ABOVE ARE BASED ON THE "STRIPPED DOWN" PROGRAM WHICH WAS POSTED ... HAVING THE FULL PROGRAM AVAILABLE MIGHT LEAD TO DIFFERENT CONCLUSIONS ...
this is the best I can do with the material I have to work with – and with the time that I can devote to the project ... I'll be teaching next week so my future participation will be extremely limited ... hopefully what I've put forward here might be helpful to others who can dig deeper and come up with some useful suggestions ...
party on ...
.
DISCLAIMER: THE CONCLUSIONS BELOW ARE BASED ON THE "STRIPPED DOWN" PROGRAM WHICH WAS POSTED ... HAVING THE FULL PROGRAM AVAILABLE MIGHT LEAD TO DIFFERENT CONCLUSIONS ...
first of all, this appears to be a program from an SLC processor (SLC-5/03 or higher) which has somehow been "shoehorned" into a MicroLogix 1000 ...
the program makes use of data files which do not even exist ... (example: F10 and F205 – among many others) ... it's impossible to track down how the data is intended to be used – when the data doesn't actually exist ... we need the "real" file in order to nail everything down ...
another weirdness is that Ladder #16 (which incidentally DOES contain some pretty important looking code) is set up as a "Debug" file ... debug files like this do not get downloaded to the processor – and so the JSR which would try to call the "Debug" file would generate a runtime fault ... what's going on here? ...
another weirdness ... someone has apparently tried to program an STI (Selectable Timed Interrupt) operation in Ladder #4 ... their use of the STS instruction for this purpose is VERY unorthodox ... personally, I've been working with PLCs for over 20 years and this is the FIRST time I've ever seen this type of instruction used ... in fact, I had to read the "book" to get an idea of what it does – and frankly I think that the "book" has an error in it ...
specifically, consider the phrase:
my initial tests show that the wording should be corrected along these lines:
specifically, as long as the STS rung stays TRUE, I was unable to get the STI to execute at all ... (disclaimer: I haven't completely tested this as far as I want to – but I'm 99% sure that my conclusions are correct) ...
also, someone has programmed STE and STD instructions WITHIN the STI file itself ... I've got a hunch this isn't going to work either ... I'll test it later as time permits ...
note that Rung #3 in Ladder #2 has a JSR instruction to "call" Ladder #4 (the would-be STI file) ... the XIC on this rung uses an undocumented bit B14/150 which is apparently not controlled by anything in the program ... I'm just GUESSING here – but possibly when the programmer couldn't get the STI to function properly, this rung was added as a "temporary" patch which could be manually toggled on or off for testing/debugging purposes ...
now on to the S:24 concerns that initiated this thread in the first place ...
DISCLAIMER: THE CONCLUSIONS BELOW ARE BASED ON THE "STRIPPED DOWN" PROGRAM WHICH WAS POSTED ... HAVING THE FULL PROGRAM AVAILABLE MIGHT LEAD TO DIFFERENT CONCLUSIONS ...
as near as I can tell, the only things in this program which could have left S:24 at a value of "3" would be the FFL located in Ladder #20 – or the matching FFU – also located in Ladder #20 ...
this FFL and FFU arrangement is apparently being used to track data which is taken from zones "prior to" or "after" a piece of Minster machinery ... I'd bet significantly more than pocket change that this FFL/FFU setup caused the value of "3" to be left in S:24 ...
there are quite a few COP instructions in this program which also make use of (and could alter) the value stored in S:24 ... based on what has been posted, all of the COP instructions are either:
(1) not being executed (due to the faulty STI arrangement) ... or ...
(2) being executed only on the First Pass of the processor when it enters the Run mode ...
moreover, a COP instruction will normally return S:24 back to a value of "0" at the end of its execution ...
conclusion: none of the COP instructions were responsible for the "3" value of S:24 which has been causing concern ...
the only other obvious use of S:24 is apparently in numerous MUL instructions ... one example (shown below) is the MUL located on Rung #6 of Ladder #17 ... note that I am unable to fully track the operation of these MUL operations since the data that they use does not exist in the data tables of this "stripped down" program ... specifically, F10:19 and F205:0 do not exist – and therefore I can't tell exactly how the original program made use of these locations ...
at this point, my best GUESS is that:
(1) the "#" characters denoting Indexed Addressing (using S:24) were entered by mistake at some point in the past ... or ...
(2) that the "#" characters were (or still are) part of an attempt to have the MUL operations "track" simultaneously with the data being handled by the FFL and FFU operations ...
note that the same basic pattern of MUL instructions is present at:
Rung #6 - Ladder #15 ...
Rung #6 - Ladder #16 ...
Rung #6 - Ladder #17 ...
Rung #6 - Ladder #18 ...
Rung #6 - Ladder #19 ...
this is a recurring pattern which makes reference to "INVERTED REFERENCE" for each of several "punches" ... it's very interesting that SOME of the addresses used in these MUL instructions have the "#" character – but then other corresponding addresses do NOT ...
once again, I can't tell for sure what's going on here without seeing the original program ...
DISCLAIMER: THE CONCLUSIONS ABOVE ARE BASED ON THE "STRIPPED DOWN" PROGRAM WHICH WAS POSTED ... HAVING THE FULL PROGRAM AVAILABLE MIGHT LEAD TO DIFFERENT CONCLUSIONS ...
this is the best I can do with the material I have to work with – and with the time that I can devote to the project ... I'll be teaching next week so my future participation will be extremely limited ... hopefully what I've put forward here might be helpful to others who can dig deeper and come up with some useful suggestions ...
party on ...
.
