Wild variations in Z

Discuss all things

Moderator: Country_Bubba

joeaverage
Posts: 34
Joined: Tue Aug 09, 2016 8:55 am

Re: Wild variations in Z

Post by joeaverage » Thu Dec 08, 2016 7:49 am

Hi,
another update. I went back to the original PCB file and shifted the origin so that the extents of the gcode
never went negative. AL now produces clean code.

Found another quirk, this time not with AL or even AE but my freeware Gcode viewer, Basic NC. Has always been spot on
but with the AL code it showed wild excursions in the XY plane at cut depth and speed. About ready to tear whats left of my
hair out. Turns out not to be faulty code at all. If AL generates a move that is a whole number then the viewer shows it as
an excursion to zero of that axis.

N9940 G1 X106.6844 Y127.9049 Z-0.535885
N9950 G1 X106.5779 Y127.976 Z-0.535702
N9960 G1 X106.52 Y128 Z-0.535657
N9970 G1 X106.5779 Y128.024 Z-0.535514
N9980 G1 X106.6844 Y128.0951 Z-0.53515

Line N9960 shows such an example, the Y move equates to 128 and the viewer shows that as an excursion to X106.52 Y0 !!!.
Fortunately my machine won't do that as the surrounding lines show.

With another free viewer, Camotics, the toolpath is fine.

Is it possible to always ensure that AL/AE always includes a decimal point?

Still, rather looks like AL may have a fault when one of the XY axes goes negative.

Have attached the probe file from which AL derived the code.

Will keep plugging away.

Craig
Attachments
probedata.txt
(7.03 KiB) Downloaded 107 times

joeaverage
Posts: 34
Joined: Tue Aug 09, 2016 8:55 am

Re: Wild variations in Z

Post by joeaverage » Thu Dec 08, 2016 10:30 am

Hi,
yet another update...are you all sick of me yet?

Following on from deadelus this morning where he was of the opinion that any variation between the actual point
recorded in the probe file vs the expected point based on its own mesh calculation caused failure to recognise the RPF
or generate any useful code, I tried to prove/disprove.

To do it I took the RPF generated by the AL code, posted previously, and manually edited with Notepad++ (marvellous utility
BTW) to conform with the exact probe points anticipated by AE by reading its own probe code it generated from the OGF.
Somewhat tedious but worthwhile as when I submitted the ModifiedRPF to AE it as expected produced a nice little pic for
me. I then edited one coord of one probe point, roughly in the centre of the board. I repeated this experiment trying to
establish AEs sensitivity to probe point conflict.

X92.53479 Y74.50994 Z-0.07800
X82.32848 Y74.50994 Z-0.08600
X72.12217 Y74.50994 Z-0.09000
X61.91586 Y74.50990 Z-0.10400
X51.70955 Y74.50994 Z-0.12100
X41.50324 Y74.50994 Z-0.13700
X31.29693 Y74.50994 Z-0.15200


X92.53479 Y74.50994 Z-0.07800
X82.32848 Y74.50994 Z-0.08600
X72.12217 Y74.50994 Z-0.09000
X61.91586 Y74.50984 Z-0.10400
X51.70955 Y74.50994 Z-0.12100
X41.50324 Y74.50994 Z-0.13700
X31.29693 Y74.50994 Z-0.15200

These two fragments are from the same location in the probe file. In the first group notice I've edited the Y coord of one entry
from 74.560994, the exact point as far as AE is concerned to 74.560990. With this alteration AE would recognise the file and generate
a visualised surface and would produce conforming code.

The second group the same coord has been edited to 74.560984 and AE wouldn't recognise the file nor generate any code.

I'm lead to the conclusion that AE will tolerate 40nm variance but fails at 100nm. 100nm is about 1/5 the wavelength of green
light!! In astronomy we talk of being diffraction limited at 1/4 wavelength....on a good day my machine is good to about 5um.

Craig

daedelus
Site Admin
Posts: 381
Joined: Tue Oct 01, 2013 1:41 pm
Location: London, UK
Contact:

Re: Wild variations in Z

Post by daedelus » Thu Dec 08, 2016 7:01 pm

Sorry. Have not been on the ball with the forum as much today (been working on some other stuff in relation to the web site) but I have been reading with interest the posts.

You are completely correct about what you say (good work by the way, all the manual editing must have been painful :() I was wrong before when I said the rows reported by my debugger was 7. It actually thinks there's 30 rows; it should say 14 or 15 so its still wrong. This is the source of the problems in the AE code if you are interested:

Code: Select all

    /**
     * Counts the number of distinct Y values in a list of 3D points and assumes that number is
     * the number of rows
     * @param orderedPointList the list of points, usually generated from an RPF
     * @return the number of rows
     */
    @VisibleForTesting
    static int countRowsInList(List<Point3D> orderedPointList)
    {
        Long rowCount = IntStream.range(0, orderedPointList.size())
                .mapToDouble(num -> orderedPointList.get(num).getY())
                .mapToObj(yValue -> new BigDecimal(yValue).setScale(4, BigDecimal.ROUND_HALF_UP))
                .distinct()
                .count();

        return rowCount.intValue();
    }
This code takes the number of distinct Y values after rounding to 4 decimal places as the total number of rows in the probe file. For your original probe file, this number was reported as 30 whereas it should be 14 / 15. This does however nicely explain the reasons why the changes you made to Y in the previous post worked in the first instance and not the second.

You said previously that probing produced several unwanted triplets which you had to delete manually. I would guess that whatever caused this, caused the additional problems with the overall accuracy. I am probably wrong but maybe there is a problem with the smooth stepper. Perhaps some setting needs adjusting with it?
http://www.autoleveller.co.uk/. Software to probe and adjust a GCode file for PCB's or any probe-able surface.

http://www.autoleveller.co.uk/cnc-probe-guide/. A short guide to setting up the probe.

-James

joeaverage
Posts: 34
Joined: Tue Aug 09, 2016 8:55 am

Re: Wild variations in Z

Post by joeaverage » Fri Dec 09, 2016 7:38 am

Hi deadelus,
I agree that we have found the cause of the numeric instability. While I don't read java that code fragment represents some
powerful arithmetic functionality in java.

I have previously used AE with Mach3 and a parallel port controller without difficulty. Mach3 probes by issuing a pulse
stream to XY motors to bring you to the probe point, then streams Z- pulses until it detects the probe event.
It creates a record in the probefile of the expected X,Y and from the elapsed pulses the Z coord. It would create such a record
even if the machine never actually arrived at the desired X,Y point, in fact it reports X,Y as exactly as the Gcode was programmed.
As a consequence AE never baulked on the basis that the reported X,Y were exactly as it had commanded.

The situation with Mach4 and an external motion controller is different. Mach4 issues a trajectory of position and velocity
over time. When the motion controller detects the probe event it stops and reports back its position based on steps for an open
loop steppers such as mine, or if you're lucky enuf to have encoders or linear scales, those values. Inevitably there will be an error
between the desired probe point generated by AE and the actual measurement from the controller. From you description
and my experimentation error of one unit in the fourth decimal place, which in mm units equates to 100nm, is enuf for
AE to go cranky.

I took an AL generated probe job Gcode file, edited it to extract the probe points designated and loaded it into a spread sheet
along side the actual probfile as a result of running that file and the rms error of my machine is 0.0225mm and a max error of 0.0331mm.
I used (deltaXsquare+deltaYsquare) to combine both X and Y errors. I know my machine has 0.7um backlash and 4um lost motion
(torsional flex in the coupler) and 18um/300mm ballscrew error. An average error of 22.5um over 150mm is probably pretty
fair for a home-built hobby machine.

For me to use AE would require either a tolerance as in AL or alternately and equivalently a routine or process which made my
X,Y conform to AEs mesh calcs.

Which rather begs the question...should not the software calculate the Z corrections based on the actual probe points rather than
it expected ones? The thought of doing those calcs makes my head hurt but the question is fair.

Craig

daedelus
Site Admin
Posts: 381
Joined: Tue Oct 01, 2013 1:41 pm
Location: London, UK
Contact:

Re: Wild variations in Z

Post by daedelus » Fri Dec 09, 2016 1:48 pm

Absolutely it should. But the problem is that the raw probe file (RPF) does not contain the actual probe points with the recorded ones, as you know and there is no way to add additional information to the RPF from within the gcode itself (you can in LinuxCNC but not Mach, as far as I know).

The actual points are documented in the probe file generator (PFG) i.e. the gcode file you used to create the RPF. So its possible for AE to correct the X and Y based on the PFG, but, the user would be required to read the RPF and the PFG into AE together in order for the X and Y values to be corrected in the RPF. Doing this is an extra and in most users cases an unnecessary step which I would prefer to avoid if possible. This is why in AL some tolerance was added. It required no extra steps from the the user, but this was not ideal.

Using the PFG to correct the X and Y would definitely help in a few cases however, agreed. But even if this was implemented, you would still need to manually remove those extra points which you had to remove at the start.

I shall document this and add something to AE when I can though.
http://www.autoleveller.co.uk/. Software to probe and adjust a GCode file for PCB's or any probe-able surface.

http://www.autoleveller.co.uk/cnc-probe-guide/. A short guide to setting up the probe.

-James

joeaverage
Posts: 34
Joined: Tue Aug 09, 2016 8:55 am

Re: Wild variations in Z

Post by joeaverage » Fri Dec 09, 2016 7:48 pm

Hi deadelus,
kool!

The upshot is that AE and AL produce usable code for use with Mach4 within the limitation of AE requiring very accurate XY
cords for AE to behave.

While you could argue the case that the software should use the measured probe points rather than the anticipated ones
the numerical evidence I gathered suggests the difference in resulting Z correction is in the nm range. The existing software
is more than adequate for anything short of wafer scale machinery.

There remains some work to be done to make use in Mach4 as seamless as it is in Mach3. The post processing of the RPF to
ensure it conformance with AL/AE could and probably should be built into Mach4. It is my intention to write the required
code to achieve it.

The built in scripting language of Mach4 is LUA. It is new to me and owes much of its structure to C++ which it is written in.
I notice that plain vanilla LUA doesn't have any useful string functions built in but have been advised that there are library
packages that confer that functionality. I will do some research and report back.
C++ modules can also added to Mach4 and may structurally be a better solution.

In the meantime I propose, with your permission, to post the M40, M41 macros and probably some discussion/warnings to
potential Mach4/Autoleveller users in a new thread, rather than burying it in this almost 'arcane' thread.

Work continues apace to resolve the multiple data records generated by Mach4, I'm sure you'll be pleased that the barrage
of emails are directed elsewhere! While I can't categorically state that the probe hardware is not faulty the evidence I have
leans me in that direction. Which leads me to believe that the fault lies in either the motion controller or Mach4. Mach4 can produce
a logfile but have yet to establish whether it can be filtered to highlight the events I'm interested in. Likewise the motion controller
can place a realtime diagnostics page in the Mach4 GUI. I have yet to establish whether I can intervene that data flow and extract
particular events. Both Mach4 and the SmoothStepper are commercial products and so I can't inspect or modify the code and am
restricted to the interface between them.

If a hobby is regarded as being successful if measured by what you learn along the way then hobbyCNC must rate as one of the
purest!

Craig

daedelus
Site Admin
Posts: 381
Joined: Tue Oct 01, 2013 1:41 pm
Location: London, UK
Contact:

Re: Wild variations in Z

Post by daedelus » Sat Dec 10, 2016 4:12 pm

In the meantime I propose, with your permission, to post the M40, M41 macros and probably some discussion/warnings to
potential Mach4/Autoleveller users in a new thread, rather than burying it in this almost 'arcane' thread.
Would be a very useful addition. I'm sure other Mach4 users would find it invaluable. I can make the new post a sticky one so it doesnt get lost.

Yes :) I have certainly learnt a lot with my little CNC machine. I am at a loss myself with the multiple records generated in Mach4 problem but it sounds like you are making good progress with that yourself and I am sure you will find a solution soon. Good luck with that.

Cheers.
http://www.autoleveller.co.uk/. Software to probe and adjust a GCode file for PCB's or any probe-able surface.

http://www.autoleveller.co.uk/cnc-probe-guide/. A short guide to setting up the probe.

-James

Post Reply