Math Registers in 5/02

[rraley 0]

I'm doing some simple calculations in a subroutine to establish cycle times and the logic works just fine, but the numbers are rounded off and only whole numbers are dispalyed in instructions and hence on the Panel view. I need to display 2 decimal places past the whole number. After reading in the help file it seems that I need to access the S:13 and S:14 math status tags to do this but does not go into detail on process. Is it as simple as changing the value in these registers from 0 to 1 to allow more precision calculation? Edited 1 Jan 2006 by rraley

[hakko808 0]

My guess is that your code is using integer math. Switching to float type variables or scaling data up by 100 could solve your problem.

[gravitar 3]

no floating poing in a SLC 5/02 unfortunately..

[rwraley 1]

I just got through reading the SLC addressing manual and the 5/02 doesn't support it.

[hakko808 0]

My bad. Gravitar is correct nothing but integers in the 5/02. Will scaling your numerator values up and moving the decimal place on the panelview work?

[Snerkel 0]

Try this (paste it into a new rung by selecting to left of rung then right clicking) SOR BST CLR S:13 NXB CLR S:14 NXB DIV N7:0 N7:1 N7:2 NXB MOV S:14 N7:3 NXB MOV S:13 N7:4 BND EOR N7:3 & N7:4 are the result

[TimWilborne 108]

What Snerkel posted will work But I think when calculating the cycle time I would put the hundred multiplier in there. (2.45 seconds would be 245) Then when setting up the tag in your Panelview put a scaling factor of .01 in the Tag Editor. This will make it display 2.45

[rraley 0]

I fixed it the easy way. I slapped in a 5/03 and reloaded the program. I had a math overflow right off the bat, but it was because of a zero divided by zero condition on the first scan so I had to add a OTU the overflow trap after the culprit instruction. The 5/03 also solved my problem in a previous post concerning on board clock although I had already divised a work around. Works great and thanks to all for the help!!

[TimWilborne 108]

Or instead of doing the OTU on the math overflow put the condition before your divide that the divisor(I assume the time) is greater than zero. If it equals zero put zero in your result Personally I do not like to unlatch the math overflow since it makes it harder to catch math errors

[TConnolly 13]

Do you use an error handler routine then? Or do you let the PLC crash? I suggest that if you do not use an error handler that you latch an alarm bit based on the overflow bit state and then go ahead an unlatch the overflow rather than let the PLC crash.

[TimWilborne 108]

Sorry, didn't state I use a fault handler that logs the error to help find it

[TimWilborne 108]

I'm going off of memory here but doesn't a divide by zero just set the math overflow and continue on. I know the Controllogix sets a minor fault and continures but can't remember about the micrologix or SLC. I dont have one in front of me right now.

[Ken Moore 23]

Don't know about the ML's but a math overflow will fault the SLC's. The PLC-5's of the other hand will set the minor fault bit, and continue to run.

[TimWilborne 108]

I think you are right, the SLCs do stop. We don't have but one of them here and I haven't used one in a few years so I can't be sure Actually the Micrologix might. Just looked at my fault handler and it clears errors after logging them. Don't feel like disabling it and crashing one of my Plcs right now but might try later Edited 3 Jan 2006 by TWControls

[Bob O 8]

Just tested a ML1500, it will set the minor error bit and fault. XIC B3:0/2 DIV N7:0 0 N7:1

[rwraley 1]

Yes indeed, the slc does fault on overflow.

[mikeroberson 0]

First: Just unlatch the overflow bit at the end of the program to avoid faults. Second: Multiply your integer math by a factor of 10 to add 1 decimal place. 100 to do 2 decimal places. if you overflow, there is a regester in the system file that catches the overflowed word (high byte). Third: Putting the 5/03 was the best fix. The online programming and chanel 0 port are both worth the upgrade cost. 1 online programming change can pay for your cost in productivity improvement on the process for bigger systems. Finally: nobody's widget is better than anyone elses. AB is good, Omron is good, PLC direct is good, GE is good, Mitsubishi is good, Modicon is good, TI is good, etc. They all have their own little quirks, but all function or they would not be on the market. The important thing is to look at the standards in your company, and try to keep everything in the same family if possible or to two at a max in order to minimize costs of inventory, software liscensing, and training. Thanks Mike Roberson