Incorrect calculations on 48 bits fixed-point (D:) Variable in high ranges (above 35 bits)

[sutty]

Hi!

I am using V1.945 on a DSP56311

I set m1->d:$0010FF

I set m1=(2^35)-1  (34359738367)

I increment/decrement m1 by 1: m1=m1+1 resp m1=m1-1 - but the result is not always +1 higher / less:

Is this issue known / solved in later fw-releases?

Greetings, Anton

[steve.milici]

The internal servo, interpolation, and commutation routines all operate with fixed-point arithmetic, 24-bit and 48-bit, for maximum speed.

User programs, motion and PLC (and on-line math), use 48-bit floating-point arithmetic (48 bits with a 36-bit mantissa and a 12-bit exponent) regardless of the “source” register format (intermediate formats are all floating-point values).

The PMAC “value interpreter” is limited to passing values in the range (+/-)2^^(+/-)35. Values outside this range are truncated so there would be a loss of fidelity in the least significant digits with integer calculations that large. This is unavoidable.

[steve.milici]

As a “workaround”, you could break up your unity increments to “x/y” definitions, where “y” is the least significant 24 bits, but you will need to handle the rollover “manually”. When the “y” register reaches 2^^24 - 1 (16,777,215) set it to zero and increment the “x” register (carry one). Then continue to increment the “y” register until the next “manual rollover” is needed.

[sutty]

Hi Steve!

How does this correlate with Curts post, where he says [.] P and Q variables can represent count values up to 64 trillion with no loss of whole-count resolution [.]. This would be way higher than 2^35 counts.

Or is this rather owed to the PMCA "value interpreter" as you mentioned latetly?

 

[steve.milici]

Yes, the PMAC “value interpreter” is limited to passing values in the range (+/-)2^^(+/-)35.

[sutty]

OK.

So these here are the maximum ranges for any 48-bit floating point number without loss of "counts" from smallest to biggest in both directions (since any value passes the PMACs value interpreter):

Right? (comprehension question: but shouldn't it rather be +34.359.738.367)

If I need to go bigger, your workaround mentioned above is the only way?

Edited July 23 by sutty

[steve.milici]

You are “mixing your metaphors”, so to speak. Your original post was about the “D” definition “Long Fixed-Point signed (two's complement) integer” not PMAC 48-bit FP. My answer was in reference to that. It is true that the PMAC 48-bit FP may have no loss of fidelity but its only internal, the PMAC input and display “value interpreter” prevents any “external” usage.