RSLogix 500 SLC 5/03 Watchdog problem...

W

Thread Starter

Warren Boswell

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.
 
M

Michael Griffin

Yes you are overlooking something simple. You are simply doing it all wrong. You never use jump to prevent the scan from continuing. That is not what jumps are for. The scan should always proceed as quickly as possible from beginning to end. You are programming a PLC, not a PIC microprocessor. If the watchdog timer is tripping, it is trying to tell you that your program is seriously wrong.

Your sequence should use the logic instructions to permit it to continue when the correct conditions are present. Steps that are not active can be scanned, they just don't do anything because the bit which enables their rungs is off.

For example, if you are executing step 1, you have a bit which enables each of the rungs associated with step 1 by using a normally open contact instruction at the beginning of each rung. When the conditions are true to proceed to step 2, you turn off the bit which enables the rungs for step 1 and turn on the bit which enables the corresponding rungs for step 2. You can continue with this for as many steps as you want.

This is basic PLC logic programming. There is seldom any reason to use a jump instruction, especially with the type of PLC you are using.

If you want a set of good examples, have a look at the Siemens S7-200 manual (*not* the S7-300 manuals). It's not for your PLC, but it is one of the most well written PLC manuals that I have seen. The S7-200 has "sequence control relays" especially for sequence control, but you can create the same functionality using just ordinary bits. Read this chapter for some good examples and explanations.

There are other sequence control methods as well (such as using a drum controller emulator) but these are much more complex as well as being much less flexible, so I won't bother describing them.

Sometimes you need to jump *forward* over instructions that don't depend on the state of the logic stack (math instructions on a lot of PLCs are like this). That is when you might want to use a jump instruction. There are other applications for jumps, but I won't go into them here.

Oh, and jumping forward over very large blocks of code (i.e. over multiple steps in your sequence) is usually not a good idea either (and doesn't work on many PLCs anyway). PLC instructions are designed to be scanned all the time. Unless you really know what you are doing, you can get into a lot of trouble this way as well.
 
W

Warren Boswell

Thanks Michael...

Do you know what I'm doing wrong regarding the checking of the S:3 byte though? I intend to make the necessary modifications to my program, since you are the umpteenth person who has told me the logic is incorrect, but I am curious as to how I can perform this correctly.

My code looked 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

Like I say, I'm positive it's just something simple I'm overlooking. I have tried swapping the integers, Absoluting the value, dealing with binary files, all to no avail. Any ideas?
 
C

Curt Wuollet

Use a state machine and let the scan proceed. This is a lot easier than what you are doing. One of the PLCs with Stage programming makes this easier, but all you need is enumerated states with defined transitions.

Regards

cww
 
M

Michael Griffin

According to the manual, the low byte contains the current scan time in 10ms increments. The high byte contains the maximum allowed scan, also in 10ms increments. The maximum value allowed in the high byte is 250.

If I look at the instructions in your second message, you are doing a masked move of the high byte into N7:1. You also however need to right shift the byte by 8 bits to get a correct representation. If you don't do that, you are just subtracting the low byte from a very large positive or negative value.

For example, 000Fh = 15 (decimal), but 0F00h = 3840 (decimal). 8000h is actually a negative number.

To go back to your original message, you stated that "should the two values be within 2 ms of each other". The timer has 10 millisecond resolution, not 1 ms.
 
W

Warren Boswell

Hello Michael,

Thanks for your input. Sorry, my description was a bit lacking. I implemented a swap procedure (SWP N7:1) to swap the high and low bytes after the masked move, thus turning the watchdog time (S:3H) into the same binary range as the current program scan time. I also cleared the bits of the destination word with a CLR instruction to prevent any bit contamination. The decimal values that were returned bore little resemblance to the actual values in the status file. Out of interest, I intend to look into this problem deeper as soon as I get the chance, because, theoretically at least, I should have gotten the correct values.

And you're right about the 10ms resolution. Once again, I described my problem poorly. Apologies.

Many thanks.
Warren Boswell
 
Top