Wild variations in Z

Discuss all things

Moderator: Country_Bubba

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

Wild variations in Z

Post by joeaverage »

Hi All,
have started using Mach4 to make boards.

Rename and mild edits of M400 and M401 macros that ship with Mach4 result in usable
M40 and M41 macros to open and close the probe file and match Mach3 functionality.

I've encountered a few problems along the way.

The first is that Mach4 would intermittently record two or more data triplets for each probe
cycle. Have not encountered this behaviour with Mach3 using the same probe hardware.
Was necessary to introduce a 1000us filtering on the probe pin to nearly eliminate the issue.
I presume Mach4 responds that much faster that switch bounce/noise causes multiple records
whereas Mach3 did not.

Once I resolved the issue of having more recorded data triplets than probe points is the probe
file visualisation shows wild variations in Z and an unusable levelled Gcode file as a result.

The test piece I have in the machine is 150x150mm and has a max deviation over the board
of 0.8mm, ie not very flat but not shocking either. The X,Y columns of data on the visualisation
page match the probe points of the Gcode probe file within .02mm. The Z column shows the
wave and/or slope of the board ie within 0.8mm and certainly nothing to indicate the wild peaks
of the visualisation.

My first question: is there some numerical limit in Z variation that causes Autoleveller to go
cranky?

The next requires some explanation: Autoleveller chose to probe the board at 210 locations, about
10.05 mm apart but the maximum segmented length is 5mm. If two probe points are fractionally further
apart than the max segment could it cause the wild variations I see?

One last point which I should mention, not that I believe is material to the above, but may have some
bearing. My Windows 8 laptop has recently stopped running AE, the browse windows would not open
and I could not manually type in the file and path. I added a post to a thread in the 'bug' section that
dealt with the same issue. Consequently my testing has involved endless swapping of files on a thumb
drive between my laptop and a Windows 7 machine that still runs AE.

With some trepidation I followed the hint about a registry conflict and manually deleted it (per the 'bug'
thread) and subsequently my laptop now runs AE again. I was then able to have the Gcode file, the
probe data file and the visualisation data alongside each other and on the same screen that I could compare
entries and have some confidence in the framing to the questions above.

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

Re: Wild variations in Z

Post by daedelus »

Thanks for confirming the scripts work for Mach4 as per the mach4 forum thread, but with the issues you describe I am not convinced the scripts arent producing some error which is causing the problems. Perhaps you can email me this probe file (RPF) so that I can inspect and run it through the debugger and hopefully diagnose this?

The issue with the file opening seams to be happening a lot with a few people lately. Perhaps there should be some settings file to record the directory rather than relying on the registry. This has the disadvantage of not having a central and unchanging place to store settings (i.e. the registry) so settings are automatically carried over between versions. If AE is opened in the same folder as a settings file then your preferences will still be carried over though, so maybe not a big issue. When I get a chance, I think I will go down this route.
My first question: is there some numerical limit in Z variation that causes Autoleveller to go cranky?
No. No limit.
If two probe points are fractionally further apart than the max segment could it cause the wild variations I see?
No. As long as both the segment length and probe spacing are positive numbers, one will not affect the other.
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 »

Hi daedelus,
thanks for your reply.

When experimenting yesterday my laptop which is my machine controller at the moment, was not able to
run AE. What with transferring files back and forth such data as I have is hard fought. After the registry
patch I applied last night at least now will be able to collect, view and process data on one machine.

I, like you, was of the opinion that the probefile was the likely culprit and tried a number of format edits
to establish the case. I've tried comma separated triplets, space separated, tab separated with and without
the axis letters. None proved any better than another. Is there a preferred format, ie seperation, numerical precision,
with or without axes letters? Is there a preferred or required file extension?

AE has become an essential component of my work stream, I can't make SMT boards without it. Either way I WILL
be persevering until I have it working satisfactorily. When I do I will post the macros and other details for others to
take up. Having a 'tidy' and readable probfile format seems a good idea.

When visualising probedata does it get drawn from the triplet file or from the columns of data on the visulaisation
screen? The reason I ask is that on a number of occasions the visualisation reported 'invalid/missing RPF' despite
there being an apparently intact file. When I inspected closer I found the multiple entry problem I've described.
I also found that even a file which had modest errors, say 215 data triplets when there are 210 probe points, the
columns of data on the visualisation screen look perfect, ie that AE had filtered the data input to be consistent
with the required number of probe points.

If it proves that errors in the probedata triplet file are responsible for the consequent visualisation and/or levelling
errors then detection and notification of the fault may prevent disaster. One levelled file called for a Z correction
of 4300 mm Z+ followed by 1538 Z-! I'm glad I didn't commit the file to my machine, it would crash for sure!

Your reply re registry/directory debate leads me to ask one more question. When using regedit.exe to scan and find the
data related to AE I found a number of entries along the lines ...\controller\... and regedit informed me 'no data set'.
May I take it then that had appropriate data had been set that my copy of AE would preferentially offer Mach3 rather
than LinuxCNC as it does at the moment? Would be a handy customisation if that is the case.

I will experiment further today and report back including attached examples in due course. Apologies for my wordy posts,
the engineer in me refuses imprecision in language in matters technical.

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

Re: Wild variations in Z

Post by joeaverage »

Hi,
have been experimenting and still Autoleveller is producing cranky code.

Attached is the probe data from my latest experiment.

Couple of things that I need to point out however. Firstly that this data is gathered by Mach4 using an Ethertnet
SmoothStepper external motion controller. Both are new to me and I'm still trying to debug. One issue I'm having
is that Mach4 is recording at random more data points than probe events. At this stage still trying to work through
the various possibilities that could cause this behaviour.

The probe file attached is a carefully hand edited version of the raw take. As deadelus has suggested Autoleveller seems
fairly happy with the format of the file. What I suspect it is very intolerant of are the end-of-line and carriage return
characters. When editing the file I cant see the embedded characters and while careful may well have upset them, at
least I hope that is the case otherwise Autoleveller has gone real screwy!

Second is that the OGF is for a board made of heavy copper cladding, 420um thick. So when I wish to cut such great
depths its not a typo.

Hope you have better luck than I at sorting it out.

Craig
Attachments
probedata.txt
(5.02 KiB) Downloaded 405 times
daedelus
Site Admin
Posts: 387
Joined: Tue Oct 01, 2013 1:41 pm
Location: London, UK
Contact:

Re: Wild variations in Z

Post by daedelus »

hmmm, I see the problem. Loaded it up in AE to see the wild probe model as you describe even though the table of figures looks fine.

Opened the file with Notepad++ where you can show the end of line characters. All the carriage returns and line feeds seem present and correct.

I then tried changing the first 14 lines from a negative Y to just 0 (shouldnt make a difference but thought it would be worth a shot). When loading the changed file in AE it told me it was invalid and didnt show a model at all.

There are a lot of points in the text file which makes it difficult to diagnose, so what I would suggest is to generate a new file where the probe spacing is 50mm or more. It should make it easier for us to work with and hopefully see the problem then.
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
daedelus
Site Admin
Posts: 387
Joined: Tue Oct 01, 2013 1:41 pm
Location: London, UK
Contact:

Re: Wild variations in Z

Post by daedelus »

I just had another quick look as I had an idea that this problem might be an issue of intolerance as to the point values.

In my debugger, it reports that there are 7 points per row; when looking at your probe file, there should be 14 points per row. From this, I now think the problem is one of intolerance to the point values, i.e. Y8.056 is not the same as Y8.057 for example. Each value that should be the same, must be identical.

I know, in the latest original AL there was a lot of tolerance built in (not sure about AE at the minute) so I loaded your exact same probe file in AL and applied an example gcode script. The leveled gcode output looked perfectly fine to me so if you havnt already, try the original AL. Hopefully this should work fine until I can find a solution.

As to the solution, I dont like building tolerance into AE because this seems like a hacky way of getting round a slightly inaccurate CNC machine. Maybe it would be better to smooth a probe file as an external program before feeding back to AE.

Anyway, try and feed your probe file into AL for now, not AE.

hope this helps,
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 »

Hi deadelus,
thanks for looking at the file.

If I understand what you are saying is if a actual probe point as recorded in the probefile differs even
slightly from what AE determines is the correct location it fails. I have the file open beside me and for instance
the 14 entries with Y=19.143 and some Y=19.144. I presume that similar variations in X, though much harder to see
but are no doubt there cause a similar numeric instability.

I might try increasing the numeric precision to see if its a rounding problem.

The Mach4 probing works in the following way: Mach4 issues a programed move command to the motion controller,
when the motion controller detects the probe event it aborts the remainder of the move and reports its measured
position based on its knowledge of motor position. Its probable then that the programed move and the actual
position differ slightly depending on the accuracy/rigidity of the machine.

I downloaded the source code of AE last night. Its the first time I've ever seen java, very impressive. It looks like
it has some pretty powerful string handling functions built in. Given my infamilarity I could only get the sketchiest
of ideas who it works.

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

Re: Wild variations in Z

Post by daedelus »

If I understand what you are saying is if a actual probe point as recorded in the probefile differs even
slightly from what AE determines is the correct location it fails. I have the file open beside me and for instance
the 14 entries with Y=19.143 and some Y=19.144. I presume that similar variations in X, though much harder to see
but are no doubt there cause a similar numeric instability.
Absolutely. Its harder to see if the X's are correct. True.

If you log in to the members area though, you can download the original AL (v. 0.8.7 I believe). Add your probe file and OGF to that and generate the gcode output. Open the new levelled file in some viewer if you have one and check it looks OK. I remember adding some tolerance to this AL so I think it should work. Let me know if not.

Some people don't like Java because it is syntax heavy. I partly agree but I also like how explicit it is. There's not much confusion about what the bits of Java code could mean even if you have to spend a bit longer reading and sifting through.
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 »

Hi deadelus,
downloaded AL and it appears to work...but not quite. I've attached the probe file, all 210 points worth.
Note that I increased the format length to 5 places, all Mach4 does is fill the extras with zeros. Not sure whether
that is a limitation of the motion controller or Mach4 or whether its available as an adjustment.

Tried to apply the probe file to AE but it failed to recognise it.

Ran AL and it produced what looked like a good file but there is one section which is faulty attached as a fragment.
It appears that as the Y axis goes to its greatest and in this file negative extent and then AL fails and produces about
20 lines or so faulty code with the rest of the file apparently OK.

I didn't find out until the etch job had been running for several minutes with the usual consequences!

Craig
Attachments
Gcode fragment.txt
(1.72 KiB) Downloaded 366 times
ALprobedat.txt
(7.05 KiB) Downloaded 373 times
joeaverage
Posts: 34
Joined: Tue Aug 09, 2016 8:55 am

Re: Wild variations in Z

Post by joeaverage »

Hi deadelus,
as an addendum you did tell me to run the code thru a viewer, I didn't...
The first 100 or so lines looked good and I presumed... to my cost.

Downloaded Notepad++, where has it been all my life!

Craig
Post Reply