-
Autoleveler not working
I'm using the autoleveler from https://www.autoleveller.co.uk/.
Currently I'm using the Autoleveller AE (Advanced Editor)
I loaded the test pcb file that they have on their website and generated a probe file(gcode) from Autoleveller.
Then I load the probe file into Mach3 and run it.
But it just moves in a straight line in Y pauses and again moves on.
Is doesn't do any Z movement. Although there is a G31 Z-1 command in the file.
If I do a G31 Z-1 F100 through the MDI it does it correctly.
I'm now on the verge of pulling my hair out.
Is there any tutorial on how to setup Mach3 with the Autoleveller?
Does any Safe Z setting have to be turned on or off in Mach3. Because I get messages regarding the same.
Any help would be highly appreciated.
-
Re: Autoleveler not working
Please post your file(s) here, we will try to figure out what the problem is. A screenshot of Autoleveller settings would help too.
You do not have to change anything in Mach3, but you do need to select "Mach3" in Autoleveller setup. Not sure about SafeZ, I don't think I ever changed it from the factory defaults.
-
2 Attachment(s)
Re: Autoleveler not working
Quote:
Originally Posted by
CitizenOfDreams
Please post your file(s) here, we will try to figure out what the problem is. A screenshot of Autoleveller settings would help too.
You do not have to change anything in Mach3, but you do need to select "Mach3" in Autoleveller setup. Not sure about SafeZ, I don't think I ever changed it from the factory defaults.
Thanks for the info, its good to hear that he problem is some minor issue.
Files attached.
There may be some difference in setting in the generated NC file vs the attached screen shot, since I was playing around with the settings a lot.
-
Re: Autoleveler not working
In the gcode you attached, Probe Depth is a bit excessive (-20mm), but that should not be a problem. It also has the Safe Height of 0, which should not be a problem either if you zero the Z axis slightly above the stock. Other than that, it looks like a perfectly working probing program (mine looks identical except for the X-Y-Z values).
So at what point do you get the SafeZ messages? What exactly happens when you run the program? Here is the sequence you should see:
- "Attach probe wires" message
- move to safe height, move to bottom left corner, move to Z2
- probe down at high speed
- probe down at a slower speed
- ask for the probe file name
- move around the board and probe 80 points
- "Detach probe wires" message.
-
Re: Autoleveler not working
Quote:
Originally Posted by
CitizenOfDreams
In the gcode you attached, Probe Depth is a bit excessive (-20mm), but that should not be a problem. It also has the Safe Height of 0, which should not be a problem either if you zero the Z axis slightly above the stock. Other than that, it looks like a perfectly working probing program (mine looks identical except for the X-Y-Z values).
So at what point do you get the SafeZ messages? What exactly happens when you run the program? Here is the sequence you should see:
- "Attach probe wires" message
- move to safe height, move to bottom left corner, move to Z2
- probe down at high speed
- probe down at a slower speed
- ask for the probe file name
- move around the board and probe 80 points
- "Detach probe wires" message.
BTW. Where should I be checking for the messages?
-
Re: Autoleveler not working
Quote:
Originally Posted by
ZeroBacklash
BTW. Where should I be checking for the messages?
The messages are displayed in Mach3 status line (below the Reset button on the default Mach3 screen).
-
Re: Autoleveler not working
Quote:
Originally Posted by
CitizenOfDreams
The messages are displayed in Mach3 status line (below the Reset button on the default Mach3 screen).
Ok! so I tried several things more.
First I downloaded the older version of Autoleveler (the standard one).
Then I generated the probe file.
Then on running the first time it gets stuck at some point saying
"Probe ignore activated at call for probe"
If I rewind the code now and run it again.
It retracts to 20mm then moves now say 5mm above the pcb.
And then it moves and pauses only in the y axis at the pauses it should have moved in the Z direction for probing. Instead it stays at the current Z and just moves in the y direction.
I'm trying to single step now, to find the issue however the single steppiing also doesn't work, instead the "Single BLK" LED blinks when I click the "Single BLK" button.
" "
-
Re: Autoleveler not working
Quote:
Originally Posted by
ZeroBacklash
Then on running the first time it gets stuck at some point saying
"Probe ignore activated at call for probe"
Is your probe working correctly? This error suggests that the probe is already touching at the moment the G31 command is called.
Look at the Digitize signal on the Diagnostic screen. The green light should turn on when the probe is touching the stock.
-
Re: Autoleveler not working
Quote:
Originally Posted by
CitizenOfDreams
Is your probe working correctly? This error suggests that the probe is already touching at the moment the G31 command is called.
Look at the Digitize signal on the Diagnostic screen. The green light should turn on when the probe is touching the stock.
I did the and the Digitize led does light up when the probe touches.
Also I added M0 statements after each line so that it pauses and I can debug the code. And it did do the first 10 steps correctly.
But after the first 10 steps when I run it from there it tends to go awry. It doesn't seem to honour the G31 Z-5 step instead it just darts in a straight line.
Could it be noise at the probe input that makes it act this way?
-
Re: Autoleveler not working
Quote:
Originally Posted by
ZeroBacklash
Could it be noise at the probe input that makes it act this way?
It is a good possibility. What does your input circuit for the probe look like?
-
1 Attachment(s)
Re: Autoleveler not working
Quote:
Originally Posted by
CitizenOfDreams
It is a good possibility. What does your input circuit for the probe look like?
I will open the controller box and see what it looks like.
In the meanwhile this is the controller that I'm currently using.
-
Re: Autoleveler not working
I checked and the inputs seem to be opto isolated, so that some what minimizes the possibility of noise. I'm running out of ideas now.
-
Re: Autoleveler not working
It seems that some USB boards have issues with probing. Here is a thread about a similar problem:
G31 Probe SOMETIMES works (Mach3 USB) (SOLVED) - AutoLeveller
-
Re: Autoleveler not working
Quote:
Originally Posted by
CitizenOfDreams
Thanks for the link, the OP in that post seemed to have solved his problem with another version of Mach3. So I don't know how much it has to do with a USB controller. I have a chinese controller though.
-
[SOLVED] Re: Autoleveler not working
Quote:
Originally Posted by
CitizenOfDreams
OK, to anyone who has this problem.
CitizensOfDream was right it seems to be a problem related to certain USB controllers.
So the solution is in this thread
Aircuts on Mach3 USB NcUsbPod - AutoLeveller
There are a number of solutions presented over there.
By "steamer" however I directly tried the solution posted by user "Renato" where he added a dwell time before the G31 probing command
like this
G4 P1
G31 Z-5 F100
So following this I just did a find and replace of the probing lines.
In addition I changed the probing depth from -1 to -5 as shown. so instead of G31 Z-1 F100 I used G31 Z-5 F100
Hope this helps.
Many thanks "CitizenOfDream" for your advice its highly appreciated.
-
Re: Autoleveler not working
You are welcome, glad you solved the problem.
Instead of manually searching/replacing, you can open Autoleveller settings and change the Probe Word field to "G4 P1 G31".
-
Re: Autoleveler not working
Quote:
Originally Posted by
CitizenOfDreams
You are welcome, glad you solved the problem.
Instead of manually searching/replacing, you can open Autoleveller settings and change the Probe Word field to "G4 P1 G31".
I had tried the Custom Option settings in Autoleveller but somehow nothing was being generated in the output file. I've put in a question at the Autoleveller forum.
Please see my post over here
Custom options not being generated in output nc file - AutoLeveller
-
Re: Autoleveler not working
Quote:
Originally Posted by
ZeroBacklash
I had tried the Custom Option settings in Autoleveller but somehow nothing was being generated in the output file.
The file you attached there includes "G4 P1" as it should.
As for #2002 and #500 variables, those are only used in files that combine probing and cutting. PFG files do not need them.
-
Re: Autoleveler not working
Quote:
Originally Posted by
CitizenOfDreams
The file you attached there includes "G4 P1" as it should.
As for #2002 and #500 variables, those are only used in files that combine probing and cutting. PFG files do not need them.
OK, I get it now, the #2002 and #500 are only used to store the corrected Z values into memory. so that the subsequent routing process can use these.
Where as in PFG these are directly logged to a file and do not need to be held in memory.
Many thanks for clearing these issues!!
-
Re: Autoleveler not working
Quote:
Originally Posted by
ZeroBacklash
OK, I get it now, the #2002 and #500 are only used to store the corrected Z values into memory. so that the subsequent routing process can use these.
Where as in PFG these are directly logged to a file and do not need to be held in memory.
That is correct. I personally prefer using PFG and probe files. That way you can restart the program if needed (to adjust Z or to change a broken tool).
-
Re: Autoleveler not working
Quote:
Originally Posted by
CitizenOfDreams
That is correct. I personally prefer using PFG and probe files. That way you can restart the program if needed (to adjust Z or to change a broken tool).
Ok, so I'm hitting some roadblocks again. I have detailed it here G92 codes not being generated in PFG file - AutoLeveller
1. The PFG file that is generated by Autoleveller does not contain the G92 statements. Is this by design?
2. THe output log file that contain the final X,Y,Z triplets are showing the same values for all probe touches, even though I can see the machine move and probe all the points.
Any suggestion would be greatly appreciated.
-
Re: Autoleveler not working
Quote:
Originally Posted by
ZeroBacklash
1. The PFG file that is generated by Autoleveller does not contain the G92 statements. Is this by design?
It contains one G92 statement just like it should. It only needs to be done once.
As for identical values for all probing points, did you actually create your M2002 macro? What does it look like?
-
Re: Autoleveler not working
Quote:
Originally Posted by
CitizenOfDreams
It contains one G92 statement just like it should. It only needs to be done once.
As for identical values for all probing points, did you actually create your M2002 macro? What does it look like?
I made a file M2002.m1s in the profile dir that I'm using and pasted this
Code:
SetVar(2002,getoemdro(802))
inside it
-
2 Attachment(s)
Re: Autoleveler not working
I did some more tests,
Where I deleted the M2002 from the .NC because I thought there may be something wrong with that.
But still no results.
I have attached the triplet log file and the PFG file.
I would be interested to know how Mach3 handles the logging how does it know when to log and what to log?
Because nothing is being told to it.
-
Re: Autoleveler not working
I'm afraid M2002 will not help you for the PFG file. "SetVar(2002,getoemdro(802))" just copies the current Z coordinate to variable number 2002.
Here is how logging works: every time a G31 command finishes, Mach3 writes current X-Y-Z values into the file that was previously opened with M40 command. I don't know all the gory details, but apparently, some USB boards just do not get along with Mach3 in that respect.
-
Re: Autoleveler not working
Quote:
Originally Posted by
CitizenOfDreams
I'm afraid M2002 will not help you for the PFG file. "SetVar(2002,getoemdro(802))" just copies the current Z coordinate to variable number 2002.
Here is how logging works: every time a G31 command finishes, Mach3 writes current X-Y-Z values into the file that was previously opened with M40 command. I don't know all the gory details, but apparently, some USB boards just do not get along with Mach3 in that respect.
Okay, but isn't M40 a Mach3 specific command, I mean as soon as M40 is encountered in the gcode Mach has to write the values of X, Y, Z to disk.
Ok so it seems I may have to move to a Parallel port controller and search for a PC with a parallel port.
-
Re: Autoleveler not working
Hi,
I've used Autoleveller for several years, starting with Mach3 and parallel port.
Nowadays using Mach4 and an Ethernet SmoothStepper.
With a suitable external motion controller saving probe data to a file works fine. There is a catch though, an external motion controller will report
its X,Y,Z position as a result of a G31 call. Autoleveller can and does go very cranky if the actual X,Y,Z differs (to the fourth decimal place) from the
Autoleveller generated probe position X,Y.
I have posted in the Autoleveller Forum exactly how and why that occurs and two Lua macros to simulate M40 and M41 and a corrective procedure
to ensure that the actual probe points are exactly coincident with the Autoleveller generated probe points.
Craig
-
Re: Autoleveler not working
Hi CitizenOfDreams,
Quote:
I don't know all the gory details, but apparently, some USB boards just do not get along with Mach3 in that respect.
The gory details go like this:
Autoleveller will produce Gcode to probe the PCB blank in a rectangular pattern, lets take a small section:
x=40.45 y=30.66
x=40.45 y=40.66
x=40.45 y=50.66 etc.
If you were using a parallel port and recording the probe positions to a probe file you would end up with this sort of data:
40.45 30.66 0.020
40.45 40.66 0.015
40.45 50.66 0.010 etc
Note that the recorded X,Y data points are EXACTLY the X,Y point specified by Auotleveller with the addition of the Z axis probe point.
When using an external controller the controller will report the X,Y,Z position at the end of the G31 move. It will report the actual positions
however and they may differ slightly from the Autoleveller intended probe positions:
40.45 30.65 0.020
40.44 40.65 0.015
40.46 50.67 0.010 say.
The modest numerical differences are sufficient for Autoleveller to screw up. It can/will happen if the variance occurs in up to the fourth decimal place,
so is very sensitive.
There is a good explanation as why that is the case by James Hawthorne, the guy who wrote Autoleveller on the Autoleveller forum.
It is for this reason that I wrote some code to detect and correct that discrepancy, that code is available for free download on the
Autoleveller Forum.
Craig
-
Re: Autoleveler not working
Quote:
Originally Posted by
joeavaerage
Hi CitizenOfDreams,
The gory details go like this:
Autoleveller will produce Gcode to probe the PCB blank in a rectangular pattern, lets take a small section:
x=40.45 y=30.66
x=40.45 y=40.66
x=40.45 y=50.66 etc.
If you were using a parallel port and recording the probe positions to a probe file you would end up with this sort of data:
40.45 30.66 0.020
40.45 40.66 0.015
40.45 50.66 0.010 etc
Note that the recorded X,Y data points are EXACTLY the X,Y point specified by Auotleveller with the addition of the Z axis probe point.
When using an external controller the controller will report the X,Y,Z position at the end of the G31 move. It will report the actual positions
however and they may differ slightly from the Autoleveller intended probe positions:
40.45 30.65 0.020
40.44 40.65 0.015
40.46 50.67 0.010 say.
The modest numerical differences are sufficient for Autoleveller to screw up. It can/will happen if the variance occurs in up to the fourth decimal place,
so is very sensitive.
There is a good explanation as why that is the case by James Hawthorne, the guy who wrote Autoleveller on the Autoleveller forum.
It is for this reason that I wrote some code to detect and correct that discrepancy, that code is available for free download on the
Autoleveller Forum.
Craig
This is some amazing information,
After struggling with my USB controller for days, I finally gave up yesterday and switched ot a UC400ETH Ethernet controller and I got results of probing file instantly.
I was under the impression that the problem was most probably with Mach3's incompatibilities with USB controllers.
Is this an issue solely due to the decimanl point differences between Autoleveler and the external motion controller?
I tried serveral workarounds described on the Autoleveller forum like adding a G4 P1 dwell, using a macro M2002 to capture the DRO Z value.
And they worked except to the point where logging to file wasn't working as expected and I was getting same co-ordinates on all lines in the logged file.
Could you kindly post the link of the corrected code that you posted on the Autoleveller forum?
A few questions
1. Does this issue also effect Mach3?
2. When does this issue manifest itself, is it during probing or during using this PFG file to autolevel the original gcode or during the actual routing?
-
Re: Autoleveler not working
It is good to know that there is a solution for those USB boards and that the UC400ETH controller works fine with Autoleveller. I am still using the parallel port, but it is getting pretty long in the tooth, so my next controller will probably be UC400.
-
Re: Autoleveler not working
Hi,
Quote:
I was under the impression that the problem was most probably with Mach3's incompatibilities with USB controllers.
Is this an issue solely due to the decimanl point differences between Autoleveler and the external motion controller?
It may be that the particular USB controller you were using was incompatible with Mach3/Autoleveller. Chinese USB controllers are
notorious for not doing probing properly (the Mach3 way) and that would no doubt screw up Autleveller as well.
Depending on how your controller reports its probe position back to Mach (and therefore your probe data file) a subtle difference in numeric
values of X and Y will cause Autoleveller to fail. If your controller just reports the X and Y cords it is supposed to be at for the G31 probe move
then everything will work OK. If your controller is like my Ethernet SmoothStepper which reports the actual position and potentially slighty different
to what Autoleveller expected you can/will have trouble.
Without knowing the internal programming of your controller I cannot tell. It rather sounds though that your original USB controller handled probing
incorrectly whereas your UC400ETH is doing it properly.
The thing to realize is that it may not be evident that Autoleveller has failed UNTIL you try to run the code. You will note the thread called 'Wild Variations
in Z' in the Autoleveller forum. That thread, started by me explains what can happen. The best diagnostic for establishing whether Autoleveller has got
good data is to use the PCB visualization feature of AuotlevellerAE. If it generates a reasonable visualization without any great peaks or valleys
its probably OK. The sure fire test is to use a good Gcode visualization software on the Autolevelled code.
Wild variations in Z - AutoLeveller
When I first started using Mach4 I had also changed to using an Ethernet SmoothStepper. As it turns out there was an ocassional glitch in the
ESS plugin that allowed a few repeated probe events. Certainly if Autoleveller is expecting 210 dat points but there is 215 in the file IT WILL SCREW UP.
Fortunately that ocassional glitch was detected and reported by another ESS user and as of ESS plugin release 216 the problem has gone away.
The numerical discrepancy causing numerically unstable Autolevelled Gcode still applies. The code I have written is in Lua and it suitable for Mach4 only.
Mach4 works with cautions - AutoLeveller
Quote:
1. Does this issue also effect Mach3?
2. When does this issue manifest itself, is it during probing or during using this PFG file to autolevel the original gcode or during the actual routing?
1) I don't know, it didn't with Mach3 and parallel port but I suspect it would happen with certain controllers and Mach3.
2) The fault manifests itself when Autoleveller goes to produce corrected code. As I said above the PCB visualization feature of AutolevellerAE is useful
but better still is a good Gcode simulation package. When it does fail it can be quite dramatic but in a very specific area of the board and even close visual
inspection of the code it is not likely to show up....until your machine crashes!
Craig
-
Re: Autoleveler not working
Quote:
Originally Posted by
CitizenOfDreams
It is good to know that there is a solution for those USB boards and that the UC400ETH controller works fine with Autoleveller. I am still using the parallel port, but it is getting pretty long in the tooth, so my next controller will probably be UC400.
Hi, it would be too early for me to say if the UC400ETH works 100% ok, I was just very happy to see the log file generated, with certain different values of X, Y and Z althought the values looked correct. I have not verified it.
And I have yet to complete the autolevelling and routing process.
-
Re: Autoleveler not working
Quote:
Originally Posted by
joeavaerage
1) I don't know, it didn't with Mach3 and parallel port but I suspect it would happen with certain controllers and Mach3.
2) The fault manifests itself when Autoleveller goes to produce corrected code. As I said above the PCB visualization feature of AutolevellerAE is useful
but better still is a good Gcode simulation package. When it does fail it can be quite dramatic but in a very specific area of the board and even close visual
inspection of the code it is not likely to show up....until your machine crashes!
Craig
Thanks for the updates,
So the problem is that Autoleveler might generates some spikes or valleys in the final g-code. And this would be visible in the 3D view of Autoleveler, correct?
Secondly I did not understand why would extra points be generated in the log file when probing is being done at a predetermined number of points?
-
Re: Autoleveler not working
Hi,
Quote:
So the problem is that Autoleveler might generates some spikes or valleys in the final g-code
correct, but the peaks and valleys can be ten or hundreds of mm's. They'll crash your machine for sure.
Quote:
And this would be visible in the 3D view of Autoleveler, correct?
Incorrect, Autoleveller AE has a visualization of the PCB blank based on the probe data alone. It is useful, if the recorded data is screwy then the visualization
will probably be also. The visualization does not show the corrected code just the PCB blank.
The only way to be sure about the corrected code is to use a Gcode simulator.
Quote:
Secondly I did not understand why would extra points be generated in the log file when probing is being done at a predetermined number of points?
Neither did I. I thought it may have been electrical noise or something. At the time I was working on a board that had 210 probe points but the probe data file
would record 215-220 points. As it turns out the problem was a very subtle fault of the ESS probing routine. It was captured and analysed by another user on what
seemed like an unrelated issue. As a result of the painstaking analysis Andy at Warp9 was able to capture the fault and devise a solution. Since that time (approx.
one year ago) my machine has never recorded an unintentional extra data point. None the less the code I have written checks the number of data points to the
number of probe points as specified by Autoleveller.
In addition it ensures that the recorded X,Y points are the same as the Autoleveller X,Y probe points. If there is a deviation of greater than 0.02 units (mm in my case)
the macro will alert you. Should there be duplicate data points, as used to happen with the ESS, it will remove them and inform you that it has done so. If there are
fewer data points the Autoleveller probe points it will alert you and stop, there can be no corrective action if data points are missing.
The code is open source so you can read it for yourself.
Craig
-
Re: Autoleveler not working
Quote:
Originally Posted by
joeavaerage
Hi,
The only way to be sure about the corrected code is to use a Gcode simulator.
Craig
Would you mind sharing what Gcode simulator you use or alternatively a usable Gcode simulator, I ran a search and ended up with https://camotics.org/
along with a few other browser based ones.
But I would prefer a desktop version that would work offline as well.
-
Re: Autoleveler not working
Hi,
I have used Camotics and it worked well.
This is one that I have used for several years and am now quite comfortable with it.
https://www.cncedit.com/basicviewer/...nInfo=1.0.0.43
Craig
-
Re: Autoleveler not working
Quote:
Originally Posted by
joeavaerage
Thanks, Thanks and Many Thanks, I tried the Basic Viewer and its awesome.
-
Re: Autoleveler not working
Hi,
you can try DigitizeGcode, a multi-level leveling gcode adpater:
https://www.youtube.com/watch?v=zipZiqnzRZg
Bye
-
Re: Autoleveler not working
