RSLogix 500 Watchdog Problem...

[kamenges]

Guys-


In Warren's defense, you aren't answering his question. He's going to do what he's going to do anyway. We might as well answer the detailed question. You know, the type of question we always ask for.

From post #9:

Originally posted by Warren Boswell:

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

Warren, Lancie1's post in #8 gave you the info you needed. These are two free-standing byte values stacked into a word. In AB's infinite wisdom they will do stuff on the firmware level that uses byte access but don't allow the end users to easily do the same. Having done higher level programming before it surprises me a little you didn't notice this. The value in N7:1 needs to be shifted down by 8 bits before you can subtract N7:0 from it. Because there is no way to perform an 8-bit shift in a single scan in an SLC and the MSB in the high byte may be set the quickest way I can think to do this is to shift everything down one bit then divide by 128.

Keith

 

[Ron Beaufort]

based on what I THINK we're looking for, let's see if this helps ...

Warren, I used N7:33 instead of S:3 simply because it's easier to plug in various numbers to make sure things are working ...

 

[Lancie1]

Can someone please enlighten me as to the reason for your statements that my programming was flawed.

1. The value in N7:1 needs to be shifted down by 8 bits before you can subtract N7:0 from it.

2. You assume that your "TEND" statement will STOP the Watchdog timer dead in its tracks. Not true! This timer times the ENTIRE SCAN cycle. Please review the basic PLC structure to see what this includes. The scan cycle does not end just because a particular instruction has been scanned. The watchdog timer will keep incrementing until the END of the SCAN.

3. Your only hope to make this work would be to make it the absolute last instruction that gets scanned, for EVERY scan. How do you plan to implement that condition? Even then, the timer will increment until the end of the scan, which includes the current instruction, plus the I/O update time.

4. How can you be sure that the Watchdog timer is updated before your TEND becomes effective? What if the scan time update occurs after? Then you will still suffer a time-out.

 

[Ron Beaufort]

I may be wrong, but I think that our new friend Warren has decided to NOT follow through on his original approach ... hopefully we can let go of that particular subject ...

moving right along ...

I only posted the code above in an effort to help him answer what is now just a purely academic question ... specifically, how to take a HIGH byte and a LOW byte from the same integer location - and then convert those two bytes into two meaningful numeric values ...

or at least I think that's what we're engaged in now ...

 

[kamenges]

Good one, Ron. I forgot about the swap instruction. Maybe AB is a little friendly.


Keith

 

[Warren Boswell]

Hello all,

Thanks for your replies.

Correct. After being informed that my logic was flawed, I have changed my approach and allowed the scan cycle to complete. Thanks for pointing me in the right direction. I still was curious, exactly as kamenges and Ron Beaufort said, how to convert the high and low byte in the S:3 word into meaningful values.

Keith and Ron: In my original program, I implemented exactly the same code you posted here, with the exception of the CLR instruction. I cleared the word with a COP. However, even when I swapped the high byte around and performed the subtraction, I ended up with bogus values. The first thing I noticed was that the values I was importing from the S:3 word were turning out to be negative.

Since the Watchdog and Current Program Scan Timers CAN ONLY be positive values (a byte ranging from 0 - 255), this was rather confusing.

The original bytes 8-bit matrix (correct word?) looked as such:

128 64 32 16 8 4 2 1

The integer's 16-bit matrix looks as such (once again, not sure if that is the correct term):

+/- 16384 8192 4096 2048 1024 512 256 128 64 32 16 8 4 2 1

The implementation of the signage bit is where certain languages allowed you to define an unsigned word which ranged from 0-65535.

The sign bit was always definitely 0. Where was my mistake creeping in?

After this, I tried absoluting all the values to get their positive value, and performing the calculations with these, but I noticed the integers stored in the data table through the MVM command, after swapping and absoluting them bore little, if any resemblance to the true values as viewed in the S2 Status file, which will be a value between 0-255 multiplied by 10ms.

I'm sure it was something simple that I overlooked. Any ideas?

 

[kamenges]

Just to take out any possibility of bit contamination, you might want to use a bitwise AND instead of an MVM. An MVM will leave the non-masked bits in the destination unchanged. If you are somehow getting some contamination in the destination values before the MVM those extra bits will stay there. A bitwise AND will definitely zero the bits not covered by the mask.

Concepttually, what you are doing should give you the correct values, especially yhe watchdog value. That should be rock solid. What is your watcxhdog time set to?

Keith

 

[Ron Beaufort]

The integer's 16-bit matrix looks as such (once again, not sure if that is the correct term):

+/- 16384 8192 4096 2048 1024 512 256 128 64 32 16 8 4 2 1

the word “matrix” is fine with me ... I personally can’t come up with anything better ...



but ... here’s where we can make a slight “improvement” on what you’ve just posted:



-32768 16384 8192 4096 2048 1024 512 256 128 64 32 16 8 4 2 1



notice that the SIGN BIT is actually given the value/worth of NEGATIVE 32,768 ... important concept: it’s not just a SIGN ... it also has a VALUE ... and the value happens to be a NEGATIVE value ...



basic rule of binary: (which you already know) ... for every bit/box which is marked by a ONE, we ADD the value of that bit’s position into our “total pot” ...



so ... if all of the bits are turned ON (marked with a ONE) EXCEPT for the “sign bit” we’ll have our LARGEST possible POSITIVE number ... in this case (16-bit integer) that number will be 32,767 ... that’s as far we can go in the POSITIVE direction ...



now, suppose that we turn that final (sign bit) ON also ... we’ll ADD its (NEGATIVE) value to our “total pot” ... let’s do the math ...



+32,767 ORIGINAL VALUE

-32,768 PLUS SIGN BIT’S VALUE

--------

-1 RESULTS



suggestion: RSLogix5 and RSLogix500 make it EASY to see this in action ... just monitor an UNUSED integer location TWICE - once with the radix set for “binary” and the other with the radix set for “decimal” ... (if you don’t know the trick, it’s right-click the Integer Data Table and select “New Window”) ...



now when you type a value into EITHER display, the software (yes, even without a processor online) will instantly show you the corresponding value ...

for beginners: a word of caution ... yes, the Windows Calculator will make these types of conversions for you ... just realize that the calculator does NOT display “leading zeros” the way the RSLogix software does ... bad situation: Tommy Technician uses the Calculator to make his conversion and then types the resulting binary number in going from LEFT-TO-RIGHT ... if there any leading zeros (and therefore less than 16 digits), then he gets the wrong results ... ooops! ... I have actually SEEN that happen in the field - with “UN-GOOD” results ...



now back to the part that Warren says is confusing him ... I would recommend that you post your .RSS file and let us find out why the code you’ve entered isn’t working correctly ... as you said, you’re probably just overlooking something ... we’ll be glad to help you spot it ...



and finally, here’s a “technician’s trick” straight from the PLC Boot Camp ... a way to make use of the tricks that we just covered ...



suppose that we have a stack of output modules to test ... each module has 16 output terminals - and we need to test each one ... suppose that we slide the modules (one at a time) into a SPARE chassis in our lab ... and at the end of our ladder file we add these two TEMPORARY rungs ...

now the SLC’s “seconds” reading from the real-time clock will turn ALL of the outputs ON for one second ... and then turn ALL of the outputs OFF for one second ... we’ll move down through the terminals and probe each one - without having to constantly be toggling all of those bits ON and OFF as we go ...



no real-time clock on your processor? ... well, surely we can program a one second flasher of our own ... or use a suitable bit from the "free-running timer" ... etc. ...



final disclaimer: the binary “rules” above are for 16-bit integers using the “Two’s Complement” method ... other types of processors might use different approaches for their binary numbers ...

 

[Warren Boswell]

Lesson Learned...

Hello all.

Thanks everyone for your help. I've completed the project, incorporating step advance bits rather than my original idea. Using the step advance logic simplified many issues further down the line as well. Many thanks for the nudge in the right direction.

As for the original issue with the MVM instructions giving me bogus values, I can only assume bit contamination was creeping into my COP instruction somehow. I have tried it now again, using a CLR instruction as in Ron's example and it works like a bomb.

I can't imagine ever using the idea anywhere, but at least it taught me a load about bit manipulation.

Thanks to all.

P.S. Rather interesting about the final bit being equal to -32768 Ron. Never knew that. I was actually curious why the integer ranges from -32768 to +32767. It all makes sense now.

 

[Ron Beaufort]

It all makes sense now.

that's what keeps us going ... glad we were able to help ...