sutty Posted July 8 Share Posted July 8 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 Quote Link to comment Share on other sites More sharing options...
steve.milici Posted July 11 Share Posted July 11 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. Quote Link to comment Share on other sites More sharing options...
steve.milici Posted July 11 Share Posted July 11 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. Quote Link to comment Share on other sites More sharing options...
sutty Posted July 22 Author Share Posted July 22 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? Quote Link to comment Share on other sites More sharing options...
steve.milici Posted July 22 Share Posted July 22 Yes, the PMAC “value interpreter” is limited to passing values in the range (+/-)2^^(+/-)35. Quote Link to comment Share on other sites More sharing options...
sutty Posted July 23 Author Share Posted July 23 (edited) 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 Quote Link to comment Share on other sites More sharing options...
steve.milici Posted July 23 Share Posted July 23 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. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.