Counting higher than 1.677722e+7

Buhsman · Oct 14, 2012

I have an application where I need to keep a running stroke count that goes higher than 16,777,220. I am currently adding 1 to a float in a SLC 5/04 every time the machine cycles and am displaying it on a Panelview. I've now reached 1.677722e+7 and would like to count higher and still be able to display an accurate number on the PV. Any ideas on how to do this?

Thanks
Kyle

rdrast · Oct 15, 2012

First, floats are the wrong thing to use here.
http://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html

I don't believe the 5/04 handles a LONG data type, so you will probably have to roll your own extended numeric. Since this is for display on a PV, I'd go ahead and use a couple INT's, the base would count from 000 to 999; once it rolls over, add one to the next INT, which represents 1(000) to 999(000), continue for as large a count as you need.

Aman607 · Oct 15, 2012

Its quite simple, Cascade the counters.
like if you want to count 200 and 100 counts are possible using 1 counter,then use 1 counter for 100 counts and when this counter counts 100,start counting from 2nd counter.. and when both have their respective 100 counts, you get your 200 counts.

daba · Oct 15, 2012

Buhsman said:
I have an application where I need to keep a running stroke count that goes higher than 16,777,220. I am currently adding 1 to a float in a SLC 5/04 every time the machine cycles and am displaying it on a Panelview. I've now reached 1.677722e+7 and would like to count higher and still be able to display an accurate number on the PV. Any ideas on how to do this?

Thanks
Kyle

You have run headlong into a trap that many people make - that is thinking that a floating-point number can accurately hold a very large value.

As you can see from your quoted "maximum" value above, 1.677722e+7, the floating-point value has only so many digits it can use for display. What happens is that the relative size difference between what you are adding (1), and what you are accumulating becomes too great, and the add of the very small number to the very large number yields no increase.

As already stated, it is easiest to use cascaded counters to achieve your aims - see the pic for a counting method up to 1,000,000,000,000 (which is either one trillion, or one billion see this wikipedia article). Whatever it is called, it is 10^12, or 1000^4.

If you counted the piston strokes of an engine running at 5,000 rpm, this counter would last for over 380 years !!

Peter Nachtwey · Oct 15, 2012

I would use two INTs and use the carry bit to add 1 to the most significant INT when it is set. One must be sure to clear the overflow bit.

daba · Oct 15, 2012

Peter Nachtwey said:
I would use two INTs and use the carry bit to add 1 to the most significant INT when it is set. One must be sure to clear the overflow bit.

Having a 32-bit result in 2 INTs is not going to help in displaying the count on the PanelView, it's gonna need a lot of "persuasion", as the lower INT isn't 16 bits - it is 15

I assume you mean the "Overflow Trap" status bit, S:5/0, which if not cleared would major-fault the processor.

shooter · Oct 16, 2012

I would also use one low counter like max 1000, if counter higher add 1 to next counter and subtract 1000 from low counter ( do not reset it as in the time between it could have a pulse.
the display just the high INT with kilometers attached.
every time my wheel turns the counter is added, but i can not see these numbers in my car.

daba · Oct 16, 2012

shooter said:
I would also use one low counter like max 1000, if counter higher add 1 to next counter and subtract 1000 from low counter ( do not reset it as in the time between it could have a pulse.
the display just the high INT with kilometers attached.
every time my wheel turns the counter is added, but i can not see these numbers in my car.

This is not going to happen in an SLC as the I/O is only updated/refreshed between program scans.

Even on the Logix5000 platform, which can update I/O asynchronously to the program scan, the code I posted only "looks at" the input once, so all the carry's are handled correctly.

TConnolly · Oct 17, 2012

Peter Nachtwey said:
I would use two INTs and use the carry bit to add 1 to the most significant INT when it is set. One must be sure to clear the overflow bit.

Agreed, If I had an HMI that were capable of treating two consecutive N words as a long integer (Redlion G3 for example) then this is how I would do it. It is a lot simpler than stacking multiple display elements in the HMI to have the illusion of one number.

When kludging 32 bit addition in the SLC the carry bit S:0/0 doesn't always work intuitively (at least to me), but 1 + 65535u (1 + FFFFh, or -1 signed) does generate a carry so for 32 bit counting it is simple and straight forward.

BST ADD N7:0 1 N7:0 NXB XIC S:0/0 ADD N7:1 1 N7:1 NXB OTU S:5/0 BND

Be sure to set S:2/14 to allow overflow.

If the HMI is not capable of handling a long integer then stacking counters is the best way.

daba · Oct 17, 2012

TConnolly said:
Agreed, If I had an HMI that were capable of treating two consecutive N words as a long integer (Redlion G3 for example) then this is how I would do it. It is a lot simpler than stacking multiple display elements in the HMI to have the illusion of one number.

When kludging 32 bit addition in the SLC the carry bit S:0/0 doesn't always work intuitively (at least to me), but 1 + 65535u (1 + FFFFh, or -1 signed) does generate a carry so for 32 bit counting it is simple and straight forward.

BST ADD N7:0 1 N7:0 NXB XIC S:0/0 ADD N7:1 1 N7:1 NXB OTU S:5/0 BND

Be sure to set S:2/14 to allow overflow.

If the HMI is not capable of handling a long integer then stacking counters is the best way.

It's not about whether the HMI can handle "Long" integers, it's about the fact that the PLC can't handle it during the counting.

The Allen-Bradley Integer format is always SIGNED, therefore the "carry" will occur at 32767+1.

This is a long, long way away from when you want the carry to occur if you are treating the low-order integer as the lower 16-bits of a 32-bit value.

It probably could be done, but it's not the carry you should carry to the high-order INT, but the transition from -1 to 0 in the low-order INT.

32767     0111 1111 1111 1111

+1        0000 0000 0000 0001

=         1000 0000 0000 0000 which is -32768, and Carry is set

OkiePC · Oct 17, 2012

I guess I am weird but to avoid overflows using A/B ints, I always chose 10,000 stacked two deep (0-9999 side by side on the HMI with zero hidden on the left one of the higher order).

These were things like machine lifetime cut cycle counters that would't fit in the positive signed range.

I never needed to count past 100 million or send the information anywhere past a screen.

Counting higher than 1.677722e+7

Buhsman

Member

rdrast

Lifetime Supporting Member

Aman607

Member

daba

Lifetime Supporting Member

Peter Nachtwey

Member

daba

Lifetime Supporting Member

shooter

Member

daba

Lifetime Supporting Member

TConnolly

Lifetime Supporting Member

daba

Lifetime Supporting Member

OkiePC

Lifetime Supporting Member

Similar Topics