Re: [Emc-users] Controller/machine resolution

[Nicklas Karlsson]

> Floating-point numbers have a huge range due to the floating-point
> nature, but the dynamic range is limited. The mantissa of an IEEE 754
> double-precision float (8 bytes) has a width of 52 bits (not counting
> the sign). This gives 52/log2(10)=15.7 decimal digits of accuracy. For
> linear systems, this will almost never be a problem. Even if a machine
> has a travel range of 1km, the position can still be resolved down to
> approx. 222fm, which is something like 1/1000th of the diameter of an
> average atom.

This is certainly far more than needed even though resolution decrease at 
longer distance. Decimal point may be moved to get a small range or large 
number but number of significant bits stay the same.

> Cheers,
> Philipp

Nicklas Karlsson

--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Controller/machine resolution

[Philipp Burch]

Hi all,

I have to admit that I've not read the rest of the discussion, so please
excuse if that has already been said.

On 03.04.2016 19:09, Mark wrote:
> On 04/03/2016 12:41 PM, Jon Elson wrote:
>> On 04/03/2016 09:46 AM, Mark wrote:
>>> That's why in this theoretical discussion I asked to
>>> disregard the actual machine accuracy and presume you had
>>> the so-called perfect machine. What I was looking for was
>>> how precise/accurate/resolute the controller would be.
>> But, there is no "perfect machine".  All machines have some
>> system for measuring position, whether stepper motors or
>> encoders.  These MUST have some fixed resolution that can be
>> either moved to (stepper) or measured (encoders).  While
>> there are physical positions that exist BETWEEN these
>> resolved points, they cannot be moved to by the motion
>> control hardware.  So, all machines have a lower limit to
>> positional resolution.  In practically ALL cases, this is
>> much coarser than the numerical resolution used in LinuxCNC.

Floating-point numbers have a huge range due to the floating-point
nature, but the dynamic range is limited. The mantissa of an IEEE 754
double-precision float (8 bytes) has a width of 52 bits (not counting
the sign). This gives 52/log2(10)=15.7 decimal digits of accuracy. For
linear systems, this will almost never be a problem. Even if a machine
has a travel range of 1km, the position can still be resolved down to
approx. 222fm, which is something like 1/1000th of the diameter of an
average atom.

BUT: Problems may arise if the travel range is not effectively limited,
as is the case with rotative systems. So if using a double to measure
the angle of some high-speed drive shaft without wrapping (I.e. the
first revolution gives 360deg, the second 720deg, etc.), then it may be
possible to actually hit the accuracy limit of the double. Running this
shaft at 5rpm in the same direction with an angular resolution of 16
bit (approx. 0.005deg) will cause a degradation of accuracy after 954
days or about 2.5 years of continuous runtime. This is most likely still
far more than any such system will be able to continously run, but it's
not some insanely large figure which will never ever be reached.
And: Should the value ever be converted to single-precision
floating-point (like on a microcontroller instead of an x86 PC), the
mantissa is only 23 bits, reducing this dynamic range by 29 bits or a
factor of about 500M. So the system above will suffer of degraded
accuracy after only 154 milliseconds.

That being said, I personally very seldomly care about the precision of
a double when it comes to representing physical quantities. They are
usually just good enough.

Cheers,
Philipp



signature.asc
Description: OpenPGP digital signature
--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471=/4140___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Controller/machine resolution

[Gene Heskett]

On Sunday 03 April 2016 09:38:59 Mark wrote:

> On 04/03/2016 09:28 AM, Dave Caroline wrote:
> > A number is a number regardless of trailing 0's, no affect on
> > accuracy or resolution.
> > Where users do get it wrong though, is not understanding how path
> > following has a tolerance. This is separate from the number and its
> > 0's but the speed of how you can change direction.
> > see http://wiki.linuxcnc.org/cgi-bin/wiki.pl?TrajectoryControl
> > and
> > http://linuxcnc.org/docs/2.6/html/gcode/gcode.html#sec:G64
> >
> > Dave Caroline
>
> Okay, assuming you have the theoretical perfect machine, what actually
> determines the accuracy and/or resolution?  To keep it simple, lets
> just assume straight line moves.
>
> Mark

All the springiness in the motor coupling or belt drive, the errors in 
the screws (which can be cumulative or canceling as thats usually rated 
at .001" per foot) and the nuts backlash, and the springing of the frame 
error caused by stiction at low speeds.  Overall thats difficult to 
measure but put a dial on the axis, and remove the backlash from the ini 
for that axis, then command a slow move, .01" a minute, and watch the 
dial, when it has moved to a convienient mark on the dial, write down 
the DRO readings, then move some more in the same direction to check for 
jerking moves which would be stiction, running it to the dials limit.

Then do an mdi move in the other direction back to the co-ordinate you 
wrote down. The dial won't come back to that mark, but the amount it 
lacks is pretty close to the backlash setting you should then put into 
the ini file for that axis.  Reset the dial to watch Y, wash rinse & 
repeat, ditto for Z.

As for mapping screws to compensate for their error, that would take an 
external DRO of known accuracy, something I do not have.  That level of 
accuracy is more lab standard stuff, and will need a childs wagonload of 
SBAnthony dollars to obtain.  And I don't even have the childs wagon. :(

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Controller/machine resolution

[Gene Heskett]

On Sunday 03 April 2016 09:37:05 Mark wrote:

> I understand that, but that doesn't really answer the question - what
> determines the machine/controller resolution/precision, the machine
> and electronics notwithstanding.  If I set the G Code coordinates to
> x.x is the resolution/accuracy actually 0.1" or is it 0.01" or 0.001"
> or something greater?
>
> Lets say the machine is at X 0.0 and Y 0.0.  The G Code commands a
> move to X 1.0 Y 0.0 (again in inches).  Does the machine move to that
> new position with a precision of 0.1", 0.01", 0.001" or something
> greater (using the theoretically perfect machine of course)?
>
> Does it make a difference if the G Code coordinates have one, two,
> three or more digits to the right of the decimal point?
>
> Mark
>
> On 04/03/2016 09:06 AM, John Thornton wrote:
> > http://linuxcnc.org/docs/2.7/html/gcode/overview.html#_number
> >
> > JT
> >
> > On 4/3/2016 7:48 AM, Mark wrote:
> >> Friend of mine and I have had an email discussion going over the
> >> last few days about movement precision, accuracy and resolution.
> >>
> >> Lets say there are three different G Code files, A, B and C.
> >>
> >> In file A, the coordinates are such:  X x.x Y x.x
> >>
> >> In file B, the coordinates are such: X x.xx Y x.xx
> >>
> >> In file C, the coordinates are such:  X x.xxx Y x.xxx
> >>
> >> For simplicity's sake, no Z axis and the units are inches.
> >>
> >> Using file A for example, with the coordinates only given with 0.1"
> >> precision, what exactly does the controller do?  Does it actually
> >> work to 0.1" precision or does it work to moreprecision, vis-a-vis
> >> when making moves?
> >>
> >> Is file C, with precision to three decimal places the standard
> >> precision in controllers, or do we just use three decimal places in
> >> the G Code because it's good enough for gummint workand the
> >> controller can actually make more precise moves (dependent of
> >> course on the machine, the mechanics and the electronics)?
> >>
> >> Mark

As others have said, the missing precision in the command is filled with 
zero's, clear down the the micro-step needed (for steppers anyway) to 
get X to 1.1000. In servo setups I'd assume the deadband is at least 
the backlash else it will hunt. So that in a servo setup, would probably 
be the major part of the actual positioning error.

How close it gets to that is up to the machines mechanical variables.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Controller/machine resolution

[Mark]

On 04/03/2016 12:41 PM, Jon Elson wrote:
> On 04/03/2016 09:46 AM, Mark wrote:
>> That's why in this theoretical discussion I asked to
>> disregard the actual machine accuracy and presume you had
>> the so-called perfect machine. What I was looking for was
>> how precise/accurate/resolute the controller would be.
> But, there is no "perfect machine".  All machines have some
> system for measuring position, whether stepper motors or
> encoders.  These MUST have some fixed resolution that can be
> either moved to (stepper) or measured (encoders).  While
> there are physical positions that exist BETWEEN these
> resolved points, they cannot be moved to by the motion
> control hardware.  So, all machines have a lower limit to
> positional resolution.  In practically ALL cases, this is
> much coarser than the numerical resolution used in LinuxCNC.
>
> Jon

Understood there's no "perfect " machine.  I was just looking for the 
ultimate theoretical accuracy/precision/resolution that could be gotten 
from the controller.  Which is why I didn't want to concern the 
discussion with the actual machine limitations.

This was started with basically a coffee table discussion on controller 
resolution.  My original query was worded poorly because I didn't know 
what I didn't know, to paraphrase a certain Secretary of Defense.  ;-)

Thanks all for the enlightenment.

Mark

--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Controller/machine resolution

[Jon Elson]

On 04/03/2016 09:46 AM, Mark wrote:
> That's why in this theoretical discussion I asked to 
> disregard the actual machine accuracy and presume you had 
> the so-called perfect machine. What I was looking for was 
> how precise/accurate/resolute the controller would be.
But, there is no "perfect machine".  All machines have some 
system for measuring position, whether stepper motors or 
encoders.  These MUST have some fixed resolution that can be 
either moved to (stepper) or measured (encoders).  While 
there are physical positions that exist BETWEEN these 
resolved points, they cannot be moved to by the motion 
control hardware.  So, all machines have a lower limit to 
positional resolution.  In practically ALL cases, this is 
much coarser than the numerical resolution used in LinuxCNC.

Jon

--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Controller/machine resolution

[Jon Elson]

On 04/03/2016 08:37 AM, Mark wrote:
> I understand that, but that doesn't really answer the question - what
> determines the machine/controller resolution/precision, the machine and
> electronics notwithstanding.  If I set the G Code coordinates to x.x is
> the resolution/accuracy actually 0.1" or is it 0.01" or 0.001" or
> something greater?
First, the entered coordinates are in "user units", which 
are definable when the system is configured.
mm and inch are the typical units.

Assuming a stepper-controlled machine, the limit is not 
mathematical, it can be moved to some discrete step on the 
motor. If servo-controlled, then the encoder resolution is 
the limit.  You cannot establish a position EXCEPT by 
reference to a stepper step or an encoder count.  These are 
usually THOUSANDS of times coarser than the internal numeric 
representation.
> Lets say the machine is at X 0.0 and Y 0.0.  The G Code commands a move
> to X 1.0 Y 0.0 (again in inches).  Does the machine move to that new
> position with a precision of 0.1", 0.01", 0.001" or something greater
> (using the theoretically perfect machine of course)?
It figures out the mathematical position requested, and then 
finds the closest position that can be achieved by the 
mechanical motion system and moves there.
> Does it make a difference if the G Code coordinates have one, two, three
> or more digits to the right of the decimal point?
>
>
We have already tried to make clear, it does NOT make a 
difference. All coordinates entered are immediately extended 
to the full double float precision.

Jon

--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Controller/machine resolution

[Jon Elson]

On 04/03/2016 07:48 AM, Mark wrote:
> Friend of mine and I have had an email discussion going over the last
> few days about movement precision, accuracy and resolution.
>
> Lets say there are three different G Code files, A, B and C.
>
> In file A, the coordinates are such:  X x.x Y x.x
>
> In file B, the coordinates are such: X x.xx Y x.xx
>
> In file C, the coordinates are such:  X x.xxx Y x.xxx
>
> For simplicity's sake, no Z axis and the units are inches.
>
> Using file A for example, with the coordinates only given with 0.1"
> precision, what exactly does the controller do?  Does it actually work
> to 0.1" precision or does it work to moreprecision, vis-a-vis when
> making moves?
>
>
All axis coordinates are extended to full 64-bit floating 
precision as the interpreter reads them.
So, 1 (no decimal), and 1.000 will end up as the same 
value internally.  Now, some odd numbers run into problems 
with their floating point representation, and so can't be 
printed out as cleanly as they were entered.
So, you can get numbers that show up on the screen with lots 
of digits to the right of the decimal point.
Such as 5 divided by 3 will give something like 
1.67 But, this is still represented internally 
to the greatest precision a double float can handle.  (Which 
will be more accurate than a wavelength of light, in most 
cases.)

So, specifying LOTS of zeros to the right of the decimal 
point accomplishes nothing.  In some cases, such as 
specifying arc start and end points, there can be problems 
determining the radius due to roundoff, so specifying more 
digits can help.  (Or, you can specify radius instead of I 
and J and never have that problem.)

Jon

--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Controller/machine resolution

[Mark]

On 04/03/2016 10:14 AM, Nicklas Karlsson wrote:
>> On 04/03/2016 09:31 AM, Nicklas Karlsson wrote:
 Lets say there are three different G Code files, A, B and C.

 In file A, the coordinates are such:  X x.x Y x.x

 In file B, the coordinates are such: X x.xx Y x.xx

 In file C, the coordinates are such:  X x.xxx Y x.xxx

 For simplicity's sake, no Z axis and the units are inches.

 Using file A for example, with the coordinates only given with 0.1"
 precision, what exactly does the controller do?  Does it actually work
 to 0.1" precision or does it work to moreprecision, vis-a-vis when
 making moves?

 Is file C, with precision to three decimal places the standard precision
 in controllers, or do we just use three decimal places in the G Code
 because it's good enough for gummint workand the controller can actually
 make more precise moves (dependent of course on the machine, the
 mechanics and the electronics)?

 Mark
>>> Machine resolution depend on for example: Movement for each step or micro 
>>> step for a stepper motor. Resolution of encoder for a motor with encoder. 
>>> Resolution may be degraded from this but if number of encoder pulses is 
>>> sent back to linuxcnc this should be the maximum resolution.
>>>
>>>
>>> Then it might be worth noting: Float point according to IEEE 754 is 23 bits 
>>> and double 53 bits regardless of decimal point position. Float work great 
>>> for values read from an analog to digital converter since number of 
>>> significant bits will be the same regardless of decimal point position 
>>> which vary depending on what value is representing.
>>>
>>> For float it may also be worth noting values will be closer together for 
>>> small values.
>>>
>>> Then unit is changed decimal point will be moved and there will be some 
>>> rounding errors so then using for machine control the question between 
>>> float and double will be. Is 23 bits resolution enough? Or is 53 bits 
>>> resolution needed? Are there any difference in computational speed?
>>>
>>>
>>> Regards Nicklas Karlsson
>> I get that, but let's assume the theoretically perfect machine.
>> Disregard the shortcomings of the stepper/drive, servo/drive, or any
>> slop and inaccuracy that would exist in the typical machine hardware
>> like bearings, etc.
> Machine accuracy because hardware is not perfect is a hard problem.
>
>
> Nicklas Karlsson

That's why in this theoretical discussion I asked to disregard the 
actual machine accuracy and presume you had the so-called perfect 
machine.  What I was looking for was how precise/accurate/resolute the 
controller would be.

Mark

--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Controller/machine resolution

[Mark]

On 04/03/2016 09:42 AM, Dave Caroline wrote:
> we are all saying it makes NO difference how many trailing 0s you have
> the accuracy is machine and its maths, see Andy's answer
>
> Dave Caroline

It's a theoretical discussion, hence my usage of the theoretically 
perfect machine, which has no slop or limitations due to the electronics.

Andy's was the answer I was looking for.

Thanks everybody!

Mark

--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Controller/machine resolution

[Mark]

On 04/03/2016 09:55 AM, andy pugh wrote:
> On 3 April 2016 at 14:47, Mark  wrote:
>
>> Okay, now we're getting somewhere.  Assuming the theoretically perfect
>> machine, a commanded move in a straight line (keeping it
>> simplified)would stop within
>>
>> x.x0" of it's commanded position, correct?
> Yes.
>
> Less theoretically, CAM systems that give arc coordinates to less than
> 3 figures of precision often fail the LinuxCNC arc consistency checks.
> So often you have to change the default precision to persuade LinuxCNC
> to draw the arc. (This is a consequence of pi being irrational)
>
Gotcha.  Thanks for the infoguys!

Mark

--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Controller/machine resolution

[Nicklas Karlsson]

> On 04/03/2016 09:31 AM, Nicklas Karlsson wrote:
> >> Lets say there are three different G Code files, A, B and C.
> >>
> >> In file A, the coordinates are such:  X x.x Y x.x
> >>
> >> In file B, the coordinates are such: X x.xx Y x.xx
> >>
> >> In file C, the coordinates are such:  X x.xxx Y x.xxx
> >>
> >> For simplicity's sake, no Z axis and the units are inches.
> >>
> >> Using file A for example, with the coordinates only given with 0.1"
> >> precision, what exactly does the controller do?  Does it actually work
> >> to 0.1" precision or does it work to moreprecision, vis-a-vis when
> >> making moves?
> >>
> >> Is file C, with precision to three decimal places the standard precision
> >> in controllers, or do we just use three decimal places in the G Code
> >> because it's good enough for gummint workand the controller can actually
> >> make more precise moves (dependent of course on the machine, the
> >> mechanics and the electronics)?
> >>
> >> Mark
> > Machine resolution depend on for example: Movement for each step or micro 
> > step for a stepper motor. Resolution of encoder for a motor with encoder. 
> > Resolution may be degraded from this but if number of encoder pulses is 
> > sent back to linuxcnc this should be the maximum resolution.
> >
> >
> > Then it might be worth noting: Float point according to IEEE 754 is 23 bits 
> > and double 53 bits regardless of decimal point position. Float work great 
> > for values read from an analog to digital converter since number of 
> > significant bits will be the same regardless of decimal point position 
> > which vary depending on what value is representing.
> >
> > For float it may also be worth noting values will be closer together for 
> > small values.
> >
> > Then unit is changed decimal point will be moved and there will be some 
> > rounding errors so then using for machine control the question between 
> > float and double will be. Is 23 bits resolution enough? Or is 53 bits 
> > resolution needed? Are there any difference in computational speed?
> >
> >
> > Regards Nicklas Karlsson
> 
> I get that, but let's assume the theoretically perfect machine. 
> Disregard the shortcomings of the stepper/drive, servo/drive, or any 
> slop and inaccuracy that would exist in the typical machine hardware 
> like bearings, etc.

Machine accuracy because hardware is not perfect is a hard problem.


Nicklas Karlsson

--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Controller/machine resolution

[andy pugh]

On 3 April 2016 at 14:47, Mark  wrote:

> Okay, now we're getting somewhere.  Assuming the theoretically perfect
> machine, a commanded move in a straight line (keeping it
> simplified)would stop within
>
> x.x0" of it's commanded position, correct?

Yes.

Less theoretically, CAM systems that give arc coordinates to less than
3 figures of precision often fail the LinuxCNC arc consistency checks.
So often you have to change the default precision to persuade LinuxCNC
to draw the arc. (This is a consequence of pi being irrational)

-- 
atp
"A motorcycle is a bicycle with a pandemonium attachment and is
designed for the especial use of mechanical geniuses, daredevils and
lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1916

--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Controller/machine resolution

[Mark]

On 04/03/2016 09:34 AM, andy pugh wrote:
> On 3 April 2016 at 13:48, Mark  wrote:
>
>> Using file A for example, with the coordinates only given with 0.1"
>> precision, what exactly does the controller do?  Does it actually work
>> to 0.1" precision or does it work to moreprecision, vis-a-vis when
>> making moves?
> It will move from X x.x0 to X x.x0
>
> The internal representation is double-precision floating point mm.
> Double-precision has at least 15 digits of decimal precision.
> https://en.wikipedia.org/wiki/Double-precision_floating-point_format
>
> If someone was to make a micro-machining system that needed better
> than femtometer precision they would have to "lie" to the system and
> set up the feedback and scaling so that a G-code command of X10 moved
> 10nanometers (or whatever)
>
>
Okay, now we're getting somewhere.  Assuming the theoretically perfect 
machine, a commanded move in a straight line (keeping it 
simplified)would stop within

x.x0" of it's commanded position, correct?

Mark


--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Controller/machine resolution

[Mark]

On 04/03/2016 09:31 AM, Nicklas Karlsson wrote:
>> Lets say there are three different G Code files, A, B and C.
>>
>> In file A, the coordinates are such:  X x.x Y x.x
>>
>> In file B, the coordinates are such: X x.xx Y x.xx
>>
>> In file C, the coordinates are such:  X x.xxx Y x.xxx
>>
>> For simplicity's sake, no Z axis and the units are inches.
>>
>> Using file A for example, with the coordinates only given with 0.1"
>> precision, what exactly does the controller do?  Does it actually work
>> to 0.1" precision or does it work to moreprecision, vis-a-vis when
>> making moves?
>>
>> Is file C, with precision to three decimal places the standard precision
>> in controllers, or do we just use three decimal places in the G Code
>> because it's good enough for gummint workand the controller can actually
>> make more precise moves (dependent of course on the machine, the
>> mechanics and the electronics)?
>>
>> Mark
> Machine resolution depend on for example: Movement for each step or micro 
> step for a stepper motor. Resolution of encoder for a motor with encoder. 
> Resolution may be degraded from this but if number of encoder pulses is sent 
> back to linuxcnc this should be the maximum resolution.
>
>
> Then it might be worth noting: Float point according to IEEE 754 is 23 bits 
> and double 53 bits regardless of decimal point position. Float work great for 
> values read from an analog to digital converter since number of significant 
> bits will be the same regardless of decimal point position which vary 
> depending on what value is representing.
>
> For float it may also be worth noting values will be closer together for 
> small values.
>
> Then unit is changed decimal point will be moved and there will be some 
> rounding errors so then using for machine control the question between float 
> and double will be. Is 23 bits resolution enough? Or is 53 bits resolution 
> needed? Are there any difference in computational speed?
>
>
> Regards Nicklas Karlsson

I get that, but let's assume the theoretically perfect machine. 
Disregard the shortcomings of the stepper/drive, servo/drive, or any 
slop and inaccuracy that would exist in the typical machine hardware 
like bearings, etc.

Just the controller.

If the G Code commands a straight line movement from X 0.0 Y 0.0 to X 
1.0 Y 0.0, disregarding accel and decel for the moment, is the 
precision/resolution of that move (in inches as before) 0.1", 0.01", 
0.001" or greater?

Mark

--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Controller/machine resolution

[Dave Caroline]

we are all saying it makes NO difference how many trailing 0s you have
the accuracy is machine and its maths, see Andy's answer

Dave Caroline

--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Controller/machine resolution

[Mark]

On 04/03/2016 09:28 AM, Dave Caroline wrote:
> A number is a number regardless of trailing 0's, no affect on accuracy
> or resolution.
> Where users do get it wrong though, is not understanding how path
> following has a tolerance. This is separate from the number and its
> 0's but the speed of how you can change direction.
> see http://wiki.linuxcnc.org/cgi-bin/wiki.pl?TrajectoryControl
> and
> http://linuxcnc.org/docs/2.6/html/gcode/gcode.html#sec:G64
>
> Dave Caroline

Okay, assuming you have the theoretical perfect machine, what actually 
determines the accuracy and/or resolution?  To keep it simple, lets just 
assume straight line moves.

Mark

--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Controller/machine resolution

[Mark]

I understand that, but that doesn't really answer the question - what 
determines the machine/controller resolution/precision, the machine and 
electronics notwithstanding.  If I set the G Code coordinates to x.x is 
the resolution/accuracy actually 0.1" or is it 0.01" or 0.001" or 
something greater?

Lets say the machine is at X 0.0 and Y 0.0.  The G Code commands a move 
to X 1.0 Y 0.0 (again in inches).  Does the machine move to that new 
position with a precision of 0.1", 0.01", 0.001" or something greater 
(using the theoretically perfect machine of course)?

Does it make a difference if the G Code coordinates have one, two, three 
or more digits to the right of the decimal point?

Mark

On 04/03/2016 09:06 AM, John Thornton wrote:
> http://linuxcnc.org/docs/2.7/html/gcode/overview.html#_number
>
> JT
>
> On 4/3/2016 7:48 AM, Mark wrote:
>> Friend of mine and I have had an email discussion going over the last
>> few days about movement precision, accuracy and resolution.
>>
>> Lets say there are three different G Code files, A, B and C.
>>
>> In file A, the coordinates are such:  X x.x Y x.x
>>
>> In file B, the coordinates are such: X x.xx Y x.xx
>>
>> In file C, the coordinates are such:  X x.xxx Y x.xxx
>>
>> For simplicity's sake, no Z axis and the units are inches.
>>
>> Using file A for example, with the coordinates only given with 0.1"
>> precision, what exactly does the controller do?  Does it actually work
>> to 0.1" precision or does it work to moreprecision, vis-a-vis when
>> making moves?
>>
>> Is file C, with precision to three decimal places the standard precision
>> in controllers, or do we just use three decimal places in the G Code
>> because it's good enough for gummint workand the controller can actually
>> make more precise moves (dependent of course on the machine, the
>> mechanics and the electronics)?
>>
>> Mark


--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Controller/machine resolution

[andy pugh]

On 3 April 2016 at 13:48, Mark  wrote:

> Using file A for example, with the coordinates only given with 0.1"
> precision, what exactly does the controller do?  Does it actually work
> to 0.1" precision or does it work to moreprecision, vis-a-vis when
> making moves?

It will move from X x.x0 to X x.x0

The internal representation is double-precision floating point mm.
Double-precision has at least 15 digits of decimal precision.
https://en.wikipedia.org/wiki/Double-precision_floating-point_format

If someone was to make a micro-machining system that needed better
than femtometer precision they would have to "lie" to the system and
set up the feedback and scaling so that a G-code command of X10 moved
10nanometers (or whatever)


-- 
atp
"A motorcycle is a bicycle with a pandemonium attachment and is
designed for the especial use of mechanical geniuses, daredevils and
lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1916

--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Controller/machine resolution

[Nicklas Karlsson]

> Lets say there are three different G Code files, A, B and C.
> 
> In file A, the coordinates are such:  X x.x Y x.x
> 
> In file B, the coordinates are such: X x.xx Y x.xx
> 
> In file C, the coordinates are such:  X x.xxx Y x.xxx
> 
> For simplicity's sake, no Z axis and the units are inches.
> 
> Using file A for example, with the coordinates only given with 0.1" 
> precision, what exactly does the controller do?  Does it actually work 
> to 0.1" precision or does it work to moreprecision, vis-a-vis when 
> making moves?
> 
> Is file C, with precision to three decimal places the standard precision 
> in controllers, or do we just use three decimal places in the G Code 
> because it's good enough for gummint workand the controller can actually 
> make more precise moves (dependent of course on the machine, the 
> mechanics and the electronics)?
> 
> Mark

Machine resolution depend on for example: Movement for each step or micro step 
for a stepper motor. Resolution of encoder for a motor with encoder. Resolution 
may be degraded from this but if number of encoder pulses is sent back to 
linuxcnc this should be the maximum resolution.


Then it might be worth noting: Float point according to IEEE 754 is 23 bits and 
double 53 bits regardless of decimal point position. Float work great for 
values read from an analog to digital converter since number of significant 
bits will be the same regardless of decimal point position which vary depending 
on what value is representing.

For float it may also be worth noting values will be closer together for small 
values.

Then unit is changed decimal point will be moved and there will be some 
rounding errors so then using for machine control the question between float 
and double will be. Is 23 bits resolution enough? Or is 53 bits resolution 
needed? Are there any difference in computational speed?


Regards Nicklas Karlsson

--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Controller/machine resolution

[Dave Caroline]

A number is a number regardless of trailing 0's, no affect on accuracy
or resolution.
Where users do get it wrong though, is not understanding how path
following has a tolerance. This is separate from the number and its
0's but the speed of how you can change direction.
see http://wiki.linuxcnc.org/cgi-bin/wiki.pl?TrajectoryControl
and
http://linuxcnc.org/docs/2.6/html/gcode/gcode.html#sec:G64

Dave Caroline

--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Controller/machine resolution

[John Thornton]

http://linuxcnc.org/docs/2.7/html/gcode/overview.html#_number

JT

On 4/3/2016 7:48 AM, Mark wrote:
> Friend of mine and I have had an email discussion going over the last
> few days about movement precision, accuracy and resolution.
>
> Lets say there are three different G Code files, A, B and C.
>
> In file A, the coordinates are such:  X x.x Y x.x
>
> In file B, the coordinates are such: X x.xx Y x.xx
>
> In file C, the coordinates are such:  X x.xxx Y x.xxx
>
> For simplicity's sake, no Z axis and the units are inches.
>
> Using file A for example, with the coordinates only given with 0.1"
> precision, what exactly does the controller do?  Does it actually work
> to 0.1" precision or does it work to moreprecision, vis-a-vis when
> making moves?
>
> Is file C, with precision to three decimal places the standard precision
> in controllers, or do we just use three decimal places in the G Code
> because it's good enough for gummint workand the controller can actually
> make more precise moves (dependent of course on the machine, the
> mechanics and the electronics)?
>
> Mark
>
>
> --
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785471=/4140
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users


--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

[Emc-users] Controller/machine resolution

[Mark]

Friend of mine and I have had an email discussion going over the last 
few days about movement precision, accuracy and resolution.

Lets say there are three different G Code files, A, B and C.

In file A, the coordinates are such:  X x.x Y x.x

In file B, the coordinates are such: X x.xx Y x.xx

In file C, the coordinates are such:  X x.xxx Y x.xxx

For simplicity's sake, no Z axis and the units are inches.

Using file A for example, with the coordinates only given with 0.1" 
precision, what exactly does the controller do?  Does it actually work 
to 0.1" precision or does it work to moreprecision, vis-a-vis when 
making moves?

Is file C, with precision to three decimal places the standard precision 
in controllers, or do we just use three decimal places in the G Code 
because it's good enough for gummint workand the controller can actually 
make more precise moves (dependent of course on the machine, the 
mechanics and the electronics)?

Mark


--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users