SLC logic not solving as expected...seen this before<?>

I think I've seen or heard of this before, but, its been so
long, I just am not sure.

I have a mature SLC 500 (5/03) that has a rung of logic
that just isnt working right. Yes, I've checked everything,
and, no, its not a program glitch or external source.
(Its a timer that does not appear to be starting correctly)

I think I saw this a few years ago, and the solution was
to upload from the processor,,,,,delete the errant rungs
in the offline mode,,, re-enter the errant rungs exactly
as they were,,,,,and download to the processor
all new.

I'll have specific firmware versions tomorrow, but was
curious if anyone remembers this one.

I don't know if this is the same problem or not, but I have had the problem where all my Timer and Counter settings were zeroed when I downloaded a new program into the PLC. The problem turned out to be a clash between different versions of RSLogix 500.

Tim.

Tim, did you upload the existing program first to put something other than all zeros in your timer/counter registers?


Greg

jdbrandt, are we talking about a TON? Is it in a subroutine? I remember something about the way a TON operates that if its in a subroutine it will hold its accumulated value and start when it is scanned again. I think it has to do with scan time but I can not remember exactly.

Maybe Ron or Ken will see this and offer an answer.

Greetings jdbrandt,

no, I personally don’t remember ever seeing anything like you’re reporting ... after the dust settles, please come back and let us know what you found ...

continuing on ... I know that you said that you’ve “checked everything” and based on that, I certainly believe that you really do have something exotic on your hands ... so what I’m about to post is intended for others who might stumble upon this thread in the future when faced with “normal-run-of-the-mill” TON timer problems ...

when things act "weird" it's often because the program rung is not being scanned ... troubleshooting trick: test the scan with a simple "is-this-being-scanned?" tester ... basic idea: add a new temporary rung immediately (I say again: IMMEDIATELY) below the troublesome rung ... all that this test rung needs is one ADD instruction ... for Source A use a new (previously unused) F8 address ... for Source B use the number "1" ... for the Destination use the SAME F8 address as before ... basically what we have here is a "scan counter" ... the value in the F8 location will be incremented (increased by one) each time the processor scans this test rung ... note: fight your intuition and do NOT use a CTU counter ... it won’t work right for this ...

now crank up the processor and see what happens ...

if the number in the F8 address IS changing, then the test rung is being scanned and executed by the processor ... and therefore the troublesome rung immediately above it is being scanned also ... in this case, a "scanning issue" is NOT your problem ... you've barked up the wrong tree - but at least you now KNOW that the real problem must lie elsewhere ...



if the number in the F8 address is NOT changing, then the test rung is NOT being scanned - nor is it being executed by the processor ... and therefore the troublesome rung immediately above it is NOT being scanned either ... in this case, a "scanning issue" IS your problem ...



troublesome things to look for are RET, TND, JMP, LBL, JSR, and MCR instructions ... these are things which can affect (for better or for worse) the normal sequence of the processor's scan routine ... statistically speaking the most likely candidate is the JSR ... I’ve seen cases where a misplaced “Delete Key” keystroke has entirely deleted a JSR rung ... further scan issue problems can occur when a Ladder File which was previously set up as an STI (Selectable Timed Interrupt) routine has had its status erroneously changed ...



note: if we were talking about a PLC-5 processor, we would add MCP issues to this list of possible culprits ...



NOTE! don’t forget to delete the “scan tester” rung when you’re through with it! ...



now going further ... jdbrandt says that his problem is: “... a timer that does not appear to be starting correctly”



so let’s say that our temporary “scan tester” rung has indicated that “scan issues” are not a part of our problem ... specifically, the TON rung IS INDEED being scanned ... the next logical thing to check would be the TON (an assumption here) timer itself ... some likely culprits: the same timer address (example: T4:0) is being used somewhere else in the program for another TON or RTO or TOF timer ... or possibly an RES (Reset) instruction for our “problem” timer is being executed ...



or possibly this scenario ... note: jdbrandt has been around long enough to have already checked all these things ... again, these are notes for less experienced programmers ...



suppose that the rung which we see on the screen looks like this:

now this is suspicious ... B3/0 is obviously TRUE - as indicated by the green highlight ... yet the timer won’t budge ... the accumulator stays stuck right there at 0 ... and the temporary “scan tester” rung is whipping along at a very fast rate ... so we know that this part of the program IS being scanned ... we’ve checked and the address T4:0 isn’t being used anywhere else in our program ... nuts! ... maybe it’s time to call in “the guru” ...



now let’s increase our view just a little for the “rest of the story” ...

so here’s what’s happening - step by step ...



on rung 0000, the OTE is being executed with false logic ... this writes a 0 into the bit/box at B3/0 ...



on rung 0001, the XIC looks for a 1 in the bit/box at B3/0 ... it does not find a 1 ... the XIC evaluates as FALSE ... when FALSE logic reaches the TON, the TON is reset ... so the timer’s accumulator stays at 0 ... sneak preview: the XIC just LOOKS true ... it ain't ...



on rung 0002, the “scan tester” rung is being scanned ... each scan increments the number in F8:0 by one ... so the number is steadily increasing ...



on rung 0003, the OTE is being executed with TRUE logic ... this writes a 1 into the bit/box at B3/0 ...



at the end of the scan, the 1 status currently stored in the bit/box at B3/0 is reported to the RSLogix500 program ... this shows up as a green highlight on our monitoring screen ... BUT ... (and here’s the trick) ... the status of the bit/box at B3/0 is flickering off and on during the processor’s scan cycle ... at the instant that the TON rung checks the status, the bit/box ALWAYS contains a 0 ... so the timer won’t run ... and then, just a few microseconds later in the scan, the status of the bit/box at B3/0 becomes a 1 ... RSLogix500 is updated only at the end of the scan ... (hardball: with RSLogix5 the rules are slightly different!) ... so on the screen, B3/0 is ALWAYS shown with a green highlight under these conditions ...



punch line: it’s the old “double-coil” syndrome again ... B3/0 should NOT (usually) be controlled by two OTEs in the same program ... but ... sometimes it happens ...



most important lesson to be learned here: you can’t trust the “green on the screen” ...



secret handshake: earlier when I said:

B3/0 is obviously TRUE - as indicated by the green highlight

Click to expand...

I was just hustling you ... a guru would know that the “obvious” indication is not always the “correct” indication ...



party on ...



PS ... note to former students: troubleshooting these conditions could be done using the same techniques that we covered in the “TRAP BITS” exercise ... see page 10-28 ...

Same goes true for two or more ONS instructions that use the same address; easier to overlook than the multiple OTE usage. Common occurence when copying and pasting sections of code.

If the soft has been running correctly for some time and no changes have been made to it, and the externals check out; what is the possibility of ram failure/corruption in the processor?

I would go with a hardware swap

My $.02
Rod (The CNC Dude)

Ron Beaufort said:

note: fight your intuition and do NOT use a CTU counter ... it won’t work right for this ...

Click to expand...

Greetings Ron.

A counter will work if the rung looks something like this:

For those who may not understand what is happening in this counter: When a rung is true, the CTU instruction first looks at the state of the CU bit. If CU is false, the CTU then adds 1 to the ACC and then sets the CU bit. If the CU bit is already set, the CTU does nothing to the ACC. When the rung is false, the CTU instruction resets the CU bit and does nothing to the ACC. Resetting the CU bit will cause a counter to count every scan. This can also come in handy when using a counter as a state machine core and there is a need to skip steps by using rung conditioning logic.

Off topic: Ron, I was going to call you and ask your opinion on this but decided to start a seperate topic instead: http://www.plctalk.net/qanda/showthread.php?p=126724#post126724

Greg,

I was e-mailed the program by a Customer to modify off site. I modified it on my laptop (which had an older version of RS500). When I downloaded my modified program from my laptop to the PLC on site is when all this happened. The only way I could get around this was to backup my file as an *.ib1 file and then restore it onto the Customers laptop and download it to the PLC from there. I did contact tech support, but they were unable to throw any light on the subject.

Tim.

yes, Alaric, certainly the CTU will work - if you set it up to reset its CU bit each scan ... but ... here we're just trying to make a quick simple "scan test" rung for troubleshooting purposes ... I think that the ADD rung satisfies that objective better than the CTU, and the branch, and the OTU, and the required explanation of the counter’s CU bit ...



but I know you well enough to understand that you brought this up as “learning point” for our readers - and not as a “hey look, Ron, you missed one” type of thing ... and so I appreciate that and I accept your input in the spirit with which I’m sure it was offered ...



and you also realize exactly why I originally cautioned against the intuitive use of the CTU ... specifically, because the unknowing would see the accumulator immediately go to a value of 1 ... the accumulator will then freeze at that value - while the CTU waits on a false-to-true condition ... the unknowing might then erroneously assume that the “tested” section of the ladder had been scanned once (and only once) ...



and just as a point of discussion ... in my troubleshooting classes, I actually lead into this particular “scan tester” exercise by demonstrating a little “receptacle tester” to the class ... it’s just a little 7-watt lamp bulb screwed into a socket with a 120 plug on the other end ... I plug it into the TOP of a wall receptacle and make the point that “I know that I have power here because the lamp lights up” ... heads are nodding ... then I plug it into the BOTTOM of the same receptacle ... again the lamp lights up ... and then I ask: “What does this tell us?” ... “That we have power there too” is the obvious and correct answer ...



now we learn to apply the same type of “power-yes or power-no” test to the PLC’s ladder logic program ... of course this time we’re talking about a “scan-yes or scan-no” type test ... but the concepts are exactly the same ...



so now the stage is set ... and we drop the ADD rung “scan tester” into the program ... the ADD isn’t adding ... what does that tell us? ... “that the processor isn’t scanning this part of the program” ... exactly ... and notice, class, that the “power rails” at the left side and the right side of the ladder are GREEN ... most people confuse this “green-power-rail” indication with a “yes, this ladder is being scanned” condition ... but that’s incorrect ... the “white-rails-aren’t-being-scanned” condition is a part of the “ONLINE/REMOTE RUN MODE” editing sequence ... by this point in the class the students have all gotten used to the “testing-the-rung-edits” step ... and so confusing the “green-rails” and “white-rails” with “scanned” and “not scanned” is perfectly logical ... unfortunately it’s also incorrect ... the students need to know this ...



so now we know (beyond a shadow of a doubt, WE KNOW!) that this part of the ladder program is not being scanned ... now what “problem” conditions should we start looking for? ... missing JSRs, unexpected TNDs, etc., etc. ...



most (all?) of the students who come to my classes have been told over - and over - and over - things such as: “the scan is too fast to understand” ... the “scan is too random to understand” ... “the scan is too complicated to understand” ... and so on ... they’ve heard this line time-and-time-again from the people around them who “know” PLCs ... now - finally - they’re learning that the scan is actually something that they certainly CAN understand ... they can test it ... they can trace it ... they can explain exactly what’s happening step-by-step as the processor scans through the program ... they like this approach ...



finally, Alaric, I’m not sure whether you’ve been a forum member here long enough to remember some of the similar discussions that we used to have with my distinguished colleague, Allen Nelson ... he doesn’t post here much anymore ... I for one miss him ... and I especially miss his “yeah, but - what about this?” approach to a lot of the issues that came up ... personally I learned a lot from those discussions ...



anyway, thanks for bringing this particular subject up ...



now as for jdbrandt’s original “timer won’t start” problem ... I still think that he’s got something exotic going on ... but ... here’s one more situation that occurred to me last night just before I fell asleep ...

a TON timer will not advance if its DONE bit is already on ... I ran into this situation once when a brand-new programmer had programmed a CLR (Clear) command to “reset” the timer’s accumulator ... the timer just froze and wouldn’t “start over” again ... the RES (Reset) instruction fixed the problem, of course ... the RES resets not only the accumulator, but also the Enable bit, the Done bit, and the Timer Timing bit ... the TON timer could also be “restarted” by going to the Program Mode and then back to the Run Mode ... in that case, the processor’s prescan sequence would reset the accumulator - and all of the status bits ...

I had a move instruction do that. the rung logic was true but it would'nt move the data. wierd as it may seem all i did was cut the move instruction inserted a new one and it worked. it's been fine for years now.

I like things simple.

AH the good ole days when I used RS 500 and RS5.

These issues seem almost fun, so easy to search and right click find all , OH look 2 OTE and 14 RSTs...........

Now I am fighting Step7 ....................oh yeah, I used to think AB was tricky.................Leave it to Germans to make something simple like a PLC ( a box of relays) and make complicated.

And I would add on the whole NO NC versus ladder issue.

When I write or disscuss a machine function , I use "and" , "and not".

This is how I explain it in class.

Ask the knowledgeable operator what he wants to happen in plain simple language.

"What are we trying to affect or change?"

"I want this valve to open."

"Under what conditions?"

"This door needs to be closed, and that valve open and that motor off, then open the valve."

So we need "not door" "and valve1" "and not motor1" then "out valve2" .

-----]/[----] [----]/[-------(OTE)
DOOR V1 M1 V2

It almost sounds like regular English, I write ladder in my head while people talk about the function, when they end the meeting I am nearly done.

IF "and not door" "and V1" "and not M1" "then V2"
(yes the first one always sounds funny)

Most ladder is a series of IF THEN ELSE statements. In fact most of life is too.

Using "and" and "and not" in place of norm open and norm closed makes things more clear for some people. Especialy when you get into the issue of a NC hardware switch that is represented by a "normaly open" ] [ in the software and vice versa.