Just need to verify what is happening in the wizards

Background info - X and Y axis are set at 480 steps per Unit(mm) - resolution is 0.0020833 of a mm.
Input is JogVal=0.20833

When i code this
Code "G31  Y" & JogVal & " F" &ProbeFeed

Output to DRO and movement is 0.20833

However if the code is
Code "G31Y" & JogVal & " F" &ProbeFeed
Notice the missing space between G31Y.....

Output to DRO and movement is 0.20625

This appears to only occur in Wizards, inputting this in the MDI brings the same value to movement and DRO 0.20833

Could any one verify that this occurs for them as well please.

Wes

So is that a trip value or end of travel value? I don't have YOUR probe to test with(;-) The difference of  distance between the Y and the one is MORE than .002 so it could not be that (;-).

(;-) TP

Hi TP,
The value is a full move value. Probe is not in play at this stage. No calculations have been performed.
Just a simple move and its bugging me that the space in the code is creating the difference in the outcome.

At this stage i'm just looking for repeatability in some one else's wizard setup.
BTW the centre finder wizard is were this first showed up. Manually moving the Y axis produced the fault and the X axis moves did not.
When I traced the code, the only difference I could find was this G31Y having no space. I altered it to G31 Y and hey presto the fault disappeared.
Is it a bug? who knows unless we can duplicate the Fault. Hence the Question.

Wes

IN mach3's Gcode spaces do not matter SAME with the scripting language. BUT(;-) I will run some tests as well.

(;-) TP

OK here is a macro in a button script that I tested with. It also writes to a log file so you do not have to stare at it all day. It has cycled well over 1000 loops without failing to correctly show the same values in the DROs and the point file from the G31.

NOW does it round UP/down funny ?YEP BUT the same very time no matter if spaced or not in the gcode.

Steps PER = 200000
DRO resolution = 0.0000000  (7 dec)

'Mach3 G31 readout and point test
test = 0
Open "C:\Mach3\Test549.txt" For Append As #1
Do While test <= 10
Code"G0Y0X0"
While Ismoving()
Wend
code"G31Y0.21111111 f100"
While Ismoving()
Wend
Code"G0 Y0"
While Ismoving()
Wend
code"G31 Y0.21111111"
While Ismoving()
Wend
Print #1, "Ydro: " & Getdro(1) & " Ypnt: "& Getvar(2001)
While Ismoving()
Wend
message "Test# " & test
test = test+1
Loop
Close #1
End    



HERE is a sample of the log file with 10 loops.

Ydro: 0.211105 Ypnt: 0.211105
Ydro: 0.211105 Ypnt: 0.211105
Ydro: 0.211105 Ypnt: 0.211105
Ydro: 0.211105 Ypnt: 0.211105
Ydro: 0.211105 Ypnt: 0.211105
Ydro: 0.211105 Ypnt: 0.211105
Ydro: 0.211105 Ypnt: 0.211105
Ydro: 0.211105 Ypnt: 0.211105
Ydro: 0.211105 Ypnt: 0.211105
Ydro: 0.211105 Ypnt: 0.211105
Ydro: 0.211105 Ypnt: 0.211105

(;-) TP
    

Hi TP
I have review your test system and while it does produce results like this some times, it doesn't always.

I have produced a wizard and a test file that i ran on my system for your perusal and playing.
The error generated is 1 missed step every time.

Your thoughts on this would be appreciated. My single step is 0.002083333333333333., however as you can see from the text file it isn't this specific number that the issue arises from.

Wes

OK I will review that .

Are you sure you are not seeing error from the probe trip itself. Lower end 3point pivot probes CAN be innaccurate when moving in certain directions such as not in line with a pivot ball. They are 3 point most accurate and 3 points worse accurate. It between it can vary as well.

Also are you sure it is not a step resolution problem where it cannot get to the position because of step resolution. It will add the remainder of the lost step value into the next move.

Just a thought, (;-) TP

OK I will review that .

Are you sure you are not seeing error from the probe trip itself. Lower end 3point pivot probes CAN be inaccurate when moving in certain directions such as not in line with a pivot ball. They are 3 point most accurate and 3 points worse accurate. It between it can vary as well.
The probe is not being used at this moment, Just trying to find the source of the erroneous error

Also are you sure it is not a step resolution problem where it cannot get to the position because of step resolution. It will add the remainder of the lost step value into the next move.
You will see that the only step I use in the program is the actual resolution and multiples of it in the Wizard

Just a thought, (;-) TP

The background for this was that I was probing a ground internal Diameter to get ready for a cut and I noticed a discrepancy in the numbers coming back on the dro's.
At first i thought there was contamination on the probe tip or job surface causing loss of electrical continuity. I eliminated this, then went on to Backlash, Steps per Axis etc etc. Eventually all that was left was an error in the actual program. In the MDI I couldn't find it, so I went back to the Wizard and that's were I found the error occurring.
Hence this Forum Discussion. I believe the error is specifically the G31 command has problems with large decimal place numbers and is truncating them using some method. Or it is simply missing the first microstep/step, either way there is an error in the G31 coding or my installation of Mach3. The issue doesn't raise its head unless you have large decimal place numbers, so 0.0125 or 0.0250 etc will work but 0.00208333333 or odd multiples of this don't. These are actual step values I use so im really baffled as they are "all" multiples of the smallest step value

Wes

I tried your wiz but it did not make any sense without intructions.  ALSO it takes FOREVER to run a segment. I will retry it now that I know a little more about it.

(;-) TP

YEPPER there is something really ODD going on with the G31 moves from a wizard.  Next is to test it outside of a wizard.

Then back up in ver to see IF it goes away. It is in V.067 and V.062

(;-0 TP