RSLogix 500 Watchdog Problem...

Hello all...

I am fairly new to the world of process automation. Could you please assist me with a SLC 5/03 problem.

I am currently writing a sequence for a CO2 dryer. In order to facilitate holding the step on an alarm, I have incorporated JMP and LBL instructions to hold the step and continuously loop backwards should an alarm condition occur.

This would, obviously, cause the watchdog timer to time out though. In order to prevent this I used an MVM on both the High and Low Byte of S:3 (the program scan word), checked the difference between the current program scan and watchdog time, and initiate a temporary end (TND) should the two values be within 2 ms of each other. However, the values I seem to be getting out from the MVM instructions is not at all what I expected.

My suspicion is that the S:3 high and low byte are represented as a byte value from 0-255, while the integer is from -32767 to +32768. Incorporating the low byte value into the integer's bits gives it a negative value. I have tried absoluting it, swapping the bits, importing it into a binary word, etc. all to no avail.

I'm sure I'm just overlooking something simple. Any help would be greatly appreciated. How can I manipulate the bits and integers correctly? If this won't work, what other solutions are possible?

Many Thanks,
Warren Boswell.

Holding the scan because of an alarm is not generally a good way of doing things. Why can't you Latch the alarm and disable any down stream processes that require it, and continue to scan the logic.

Depending on how you're doing it, if an alarm goes away, you will never know it, because you held the scan, so the I/O isn't updating.

The I/O will be updated once it reaches the (TND) statement. I have chosen this approach to prevent the timers timing out and following on to the next step. There is a possibility of using your approach should mine not work though. Thanks. Would like to get the integer and bit handling correct for future reference though.

Oh yeah, the process can not be shut-off. CO2 most consistently be supplied even if the dew-point is out of spec, so shutting off on an alarm is not an option. Need to hold on the step until the faulty condition is corrected...

Looping in logic in order to prevent advancing to another step is the completely wrong way of accomplishing what you are doing.

You should be able to inhibit or hold at any point, while maintaining your normal program scan. Usually in sequence based logic, this involves not advancing until a "Step-Advance-Permissive" interlock bit is set.

Rethink your design, it is as flawed as it can possibly be.

Point noted, easily corrected, thank you... But can anyone actually answer the question?

Answer what question?

Warren Boswell said:

How can I manipulate the bits and integers correctly? If this won't work, what other solutions are possible?

Click to expand...

That one??

The best way to fix the problem, the best solution possible, is to NOT jump backwards in the program. Period. You're asking for watchdog faults when you do that -- regardless of how you try to manipulate the bits.

Plus, it'll be a real mess for someone else down the line to decypher when the processor faults and you're not around to fix it.

rdrast gave you the best answer -- rethink your sequence and pause the sequence on a fault. Don't "pause" the scan.

Greetings Warren - and welcome to the forum ...



is “the problem” related to manipulating bytes and bits using instructions such as the MVM? ... if you want to master those particular skills, I’d suggest that you experiment with moving the various values into “dummy” locations such as a spare binary word (something like B3:2, etc.) and not into the processor’s STATUS file ...



also ... be VERY careful of the details ... for example, you said:

while the integer is from -32767 to +32768

Click to expand...

actually an integer ranges from +32767 to -32768 (signs reversed) ... that’s probably not causing your problem - but little details like that can cause a LOT of confusion ...



if you really want to tackle that bit/byte moving issue, then make up a small project and work on it ... if you can’t nail everything down, just post what you already have - and we’ll help you over the rough spots ... code is ALWAYS better than a text description ... much less chance for a misinterpretation ...



based on what you’ve written so far, I (personally) am not 100% sure what you’re trying to accomplish ... but WHATEVER it is, I’m pretty certain we can help you nail it down - once we understand where you’re headed ...



hope this helps ...

In order to prevent this I used an MVM on both the High and Low Byte of S:3 (the program scan word), checked the difference between the current program scan and watchdog time, and initiate a temporary end (TND) should the two values be within 2 ms of each other. However, the values I seem to be getting out from the MVM instructions is not at all what I expected.

Click to expand...

I do not think that the S:3 High and Low bytes work as you think they do. Even if you get something to work to cause an infinite loop by continuously changing the value of S:3L (the low byte is the one), then that rung itself will also ADD to the scan time AT THE END OF THE SCAN and cause the value of S:3 to change AGAIN, AFTER your MVM instruction, so you are fighting an unwinnable battle.

This is not a valid technique. PLC's are not designed to have their scan cycle halted. You need to find a better method, which is the normal programming method as has been explained to you already.

Current [x10 ms] S:3L
The value of this byte (low byte) tells you how much time elapses in a program cycle. When SVC or REF instructions are contained in your program, this value will appear to be erratic when you monitor it with a programming device. This is because the SVC or REF instructions allow this value to be read in mid-scan, while it is still incrementing.

Watchdog [x10 ms] S:3H

This byte value (high byte) contains the number of 10 ms ticks allowed to occur during a program cycle. The default value is 10 (100 ms), but you can increase this to 250 (2.5 seconds) or decrease it to 2, as your application requires. If the program scan value (S:3L) equals the watchdog value, a watchdog major error is declared (code 0022).

RSLogix 500 - Copyright Rockwell Software 2000

Click to expand...

Hello all and Good morning...

Thanks everyone for their input... I'm more used to sequential execution of a program as in Computer programming. I apologise if my statement was ambiguous and led to some confusion.

I'm not specifically trying to manipulate the value of S:3L directly, but rather just comparing it with S:3H to see whether it is within 20ms of causing a watchdog timeout and if so initiating a temporary end to reset the scan timers and refresh the I/O.

The code looks something like this (from memory):

MVM S:3 00FFh N7:0

MVM S:3 FF00h N7:1

SUB N7:1 N7:0 N7:3

LEQ N7:3 2 TND

Have already tried swapping the bits since I suspect it moves the high byte into the high byte of the integer. Have also tried absoluting the values. Like I say, I think I'm making a stupid mistake somewhere... Can someone point it out to me?

I am rather curious at this thinking though... Can someone please enlighten me as to the reason for your statements that my programming was flawed. In all fairness, I believe my programming eliminated unnecessary scanning of rungs that would have not been executed anyway, so processing the rungs would have been rather pointless. Secondly, I got the idea from Allen-Bradley themselves where they mentioned that if you jump backwards in a program or create a loop within your program, be cautious that the watchdog timer does not timeout.

A PLC scans logic & solves it.
Your solution will be considered a kluge by about any one who typically programs PLCs.
You simply need to pause your process, but still update & solve logic. There is no reason to fiddle with the PLC's scan when another simple, clean solution is available & obvious.

Warren Boswell said:

Hello all and Good morning...

Thanks everyone for their input... I'm more used to sequential execution of a program as in Computer programming.

Click to expand...

Well, PLC's do not process a program the same way as a computer application. In general, all logic is solved every pass. Do not apply the thought that because a bicycle has pedals and a chain, that when you get into a car, you should control it by pumping pedals directly connected to the drive axle.

The two devices are different.

I am rather curious at this thinking though... Can someone please enlighten me as to the reason for your statements that my programming was flawed. In all fairness, I believe my programming eliminated unnecessary scanning of rungs that would have not been executed anyway, so processing the rungs would have been rather pointless.

Click to expand...

Again. It is flawed for many reasons, firstly because all logic should be scannable at all times. By monkeying around with jumps, and fiddling with TND's (which should really ONLY be used for debugging purposes), you can easily, and indeed intentionally bypass any other logic that might be required for machine or human safety.
You prevent outputs that SHOULD turn (off/on) FROM turning (off/on). You break anything that might be timed in the PLC, and you are developing an completely improper thought process for solving logical problems using a PLC.

Secondly, I got the idea from Allen-Bradley themselves where they mentioned that if you jump backwards in a program or create a loop within your program, be cautious that the watchdog timer does not timeout.

Click to expand...

That isn't advice to PLAY WITH THE TIMER, that is a WARNING OF WHAT WILL HAPPEN IF YOU EMPLOY IMPROPER PROGRAMMING PRACTICES.

You all have made your point, quite bluntly as well. I promise never EVER to play with the timer again. Really, I swear! No need to bludgeon me with a club. Returning to the original point...

Can anyone tell me what I was doing wrong in the code above?

Warren Boswell said:

You all have made your point, quite bluntly as well. I promise never EVER to play with the timer again. Really, I swear! No need to bludgeon me with a club. Returning to the original point...

Can anyone tell me what I was doing wrong in the code above?

Click to expand...

What code?
And the answer has been given. Utilize interlocks/permissive booleans in order to pause a sequence, or at least prevent advance.

Any sequential programming can be implemented with relatively simple logic.

Never mind. Read this thread.
http://www.plctalk.net/qanda/showthread.php?t=2217&highlight=Step

In other words, what I was doing incorrectly when I moved the variables from the S:3 word that it gave me bogus values... I've already understood your point. Constantly reiterating it just makes yourself annoying...

/sigh. Giving up.