GearHeads Corner

Floating point numbers are always a little tricky since in many cases they're very close approximations to the actual number.  It's the tradeoff to give you a much larger range than the number of bits involved would suggest.  Your method looks just fine to me, fwiw.

Tests for zero, or even equality with any number, can be a little weird.&nbsp; Unless there's some fudging in the scripting language I learned (back when computers were really rooms full of young woman with pencil and paper :) ) that rather than testing for float == 0.0&nbsp; (well, float .eq. 0.0)&nbsp; it's better to test for abs(float) <= very small number.&nbsp; In this case I'd suggest something like 1.0e-6 but vsn is really determined by the tolerance of what you're measuring.

Correct me if I'm wrong, it happens.&nbsp; HTH

Kirk

&nbsp; It is the nature of the scripter that it passes such numbers as floats. So when a number like
.00000061 shows up it will be printed as 6.1E-7 or such thing, but its still in essence a 0.0
in terms of the math. So you could use a Goto or any math on that number and typically
get the result your looking for.
&nbsp; This is no different than Mach3 or other controller, one of the most common support
questions I got on Mach3 was why the display would show .003421 or something after
a Goto(0,0,0). Of course this is simply less than 1 step of the motors, to move one
step more would be -0.0000xxx.&nbsp; Often when a DRO is showing 0.0 the base value its
displaying could actually be .000000001786 or so.

&nbsp; So dont worry about the number, unless your multiplying by millions, its simply
a rounding error more related to printing it than using it. As Kirk says, its common
to do a comparison to a small number to see if its actually zero. A statement
like
&nbsp; " if( fabs(x) < epsilon ) x = 0; "

is pretty common in code. epsilon changes from situation to situation, but is typically
pretty small. These small floats play a part though as they accumulate small errors
until they get large enough to be a full step of the motors. They play a part in end
accuracy of position over time.

&nbsp; My advice would be to ignore such small numbers, they mostly come from the fact
the motor can only move in quantum increments, so small differences will exist on every
move, but as they accumulate they self correct errors in motion over time.

Art

&nbsp; One other point you should consider. When you use Engine.SetAxisPos(0.null,null,null)
you are actually setting an offset. It doesn't set the index of the motor, that can only be
set by homing.

&nbsp; So as an example, lets say you homed the system and the index is now zero. The Machine
coordinate now shows zero and if you ask for current motor position it returns a zero. So
now you issue Engine.SetAxisPos(100.null,null,null) . If you now ask for the position of
the motors you get 100.000000, which is correct. But now you command a G0X100.01

&nbsp; The motor in question is set to 523 steps/ mm. The system will then move 523 * .01 steps
which is 5.23 steps. The motor can only move 5 steps. This leaves a difference of .23 steps
or .000439771 mms. As this process continues through a program you can imagine the
difference between actual position in steps and actual position in the program will always
swing between&nbsp; 1 and -1 step in increments that can be as small as the systems math
functions allow. So at any given time if you issue a Engine.SetAxisPos(0.null,null,null)
you may be setting the offset to a very small number or even an irrational number so
the offset become 1.666666666666666 . If you then ask for position, the formula
internally is ( motorIndex / numberOfStepsPermm ) - offset. Its not hard for the answer
to be .0000000000666666 or some such small value, it just means your almost right on the
step count, but not quite.

Art

&nbsp; &nbsp;

Ok

Thanks art and kirt

I am only using it for probing and have not found any real issues with it so i will let it be as is...

Thanks gary

Gary:

Version with "ProbeSetupLevel" as variable is now online. Untested but added in the codebase.

Art

Art

Not sure how you set it up, but i tried the GlobalGet..

And the only value i get returned is 0, i assume you are looking for a true or false depending on how the probe is set Right ?..
it was the same value returned 0, for false or true after i changed the probe in config settings..

Gary&nbsp;

Gary:

Its only set at startup, so even if you switch that setting, youd have to restart to see the change.
Theory being one doesnt change that setting in general use so its not realtime checking it. It should
show 1 for true, 0 for false.

I will double check though and fix it up this weekend if it isnt doing it properly..

Thx
Aty

Art

Thank,s i did change from true to false in config and then restarted auggie when i was testing it but always seamed to returning a 0..

Gary

Gary:

Fixed and tested. On startup the current setting is recorded to that variable.
I had a typo in there so it wasn't changing.

Thx for the test.
Art

Art

Yes that fixed it.

Thanks gary

Art


if you can remove the print statements you added for testing that would be great, it's making it hard to follow the print outs on the screen now the script will finish running but the prints will keep scowling for a while after wards and i'm having a hard time keeping tract of whats going on at the time..

Thanks gary