Adding to a REAL number gives an unexpected sum?

[Peter Nachtwey]

In which application is floating point math more reliable than integer math? ....

This is really a good question. Long ago before floating point chips were available we had only signed and unsigned integers.


Our 2nd generation of motion controllers was based on Intel and AMD 80186s. This only had 16 bit integer math. So we would use two 16 bit words. One would represent integers and the other would represent fractions of integers. The fractions were expressed in fractions of 65536 so 1/2 was 32768 or 8000H. The fraction part was always unsigned where the high part could be signed or unsigned.

https://www.allaboutcircuits.com/te...sentation-the-q-format-and-addition-examples/
I also did a lot of DSP programming. one learns lots of tricks. These "tricks" resulted in much faster results than using a floating point library. The problem was that one had to be good at assembly language programming.


When floating point hardware arrived, programmers got lazy. However they still found the floating point had limits like adding 1 to a floating point number is not a good idea since the mantissa of a REAL is only 24 bits but using two 16 integers would handle this easily way beyond the 16.777M to over 4B.


Even now when we have 64+ bit floating point we are still careful. if you tell our motion controller to move to 10 meters, we offset the command so that all internal moves move to 0 where the precision is higher. Moving to 10m or 10,000mm would result in precision being lost.


You can be lazier with floating point but it can still bite you if you are not careful. This is evident as there are new threads on floating point every month or so on this forum. In college a took a class on numerical methods and part of was about how to reduce floating point errors.


Search for "Q15 format" and "fixed point format"

 

[Duranthas]

Well I got busy, then distracted and I forgot to come back and thank everyone for their input on this. It was appreciated.

janner_10, it does have a .DN bit, but much like the .PC bit it seems to stay true until the motion is called again which is why I couldn't use it.

I'd bet my eyes that someone has a far more elegant way to controlling an axis which requires multi-motion (rapid in feed, first feed, fine feed, rapid return feed), but I wasn't given much time to learn Ethernet/IP servo drive programming so I hodge-podge stuff together as best I could to get it going. As soon as I finish my current project (which is preparing to incorporate more EIP servo drives by upgrading the PLC5 to Controllogix), I will have a small window of time where I plan on trying to "better" my existing programming before rolling it out in more places.

 

[pturmel]

janner_10, it does have a .DN bit, but much like the .PC bit it seems to stay true until the motion is called again which is why I couldn't use it.

This bothers me. It suggests that you tried to use the DN bit as part of your state machine, instead of just an input to your state machine. Lots of physical components stay "done" after their trigger is gone (think double-coil detented solenoids and similar). AB Motion Instructions are like that. The state machine for your process needs to be separate from the state of the individual operations wihtin it.