584,805 active members*
4,987 visitors online*
Register for free
Login
IndustryArena Forum > Other Machines > PCB milling > Autoleveler not working
Page 2 of 2 12
Results 21 to 39 of 39
  1. #21
    Join Date
    Mar 2012
    Posts
    150

    Re: Autoleveler not working

    Quote Originally Posted by CitizenOfDreams View Post
    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.

  2. #22
    Join Date
    Nov 2012
    Posts
    1267

    Re: Autoleveler not working

    Quote Originally Posted by ZeroBacklash View Post
    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?

  3. #23
    Join Date
    Mar 2012
    Posts
    150

    Re: Autoleveler not working

    Quote Originally Posted by CitizenOfDreams View Post
    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

  4. #24
    Join Date
    Mar 2012
    Posts
    150

    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.
    Attached Files Attached Files

  5. #25
    Join Date
    Nov 2012
    Posts
    1267

    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.

  6. #26
    Join Date
    Mar 2012
    Posts
    150

    Re: Autoleveler not working

    Quote Originally Posted by CitizenOfDreams View Post
    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.

  7. #27
    Join Date
    Nov 2013
    Posts
    4280

    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

  8. #28
    Join Date
    Nov 2013
    Posts
    4280

    Re: Autoleveler not working

    Hi CitizenOfDreams,

    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

  9. #29
    Join Date
    Mar 2012
    Posts
    150

    Re: Autoleveler not working

    Quote Originally Posted by joeavaerage View Post
    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?

  10. #30
    Join Date
    Nov 2012
    Posts
    1267

    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.

  11. #31
    Join Date
    Nov 2013
    Posts
    4280

    Re: Autoleveler not working

    Hi,

    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

    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

  12. #32
    Join Date
    Mar 2012
    Posts
    150

    Re: Autoleveler not working

    Quote Originally Posted by CitizenOfDreams View Post
    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.

  13. #33
    Join Date
    Mar 2012
    Posts
    150

    Re: Autoleveler not working

    Quote Originally Posted by joeavaerage View Post

    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?

  14. #34
    Join Date
    Nov 2013
    Posts
    4280

    Re: Autoleveler not working

    Hi,

    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.

    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.

    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

  15. #35
    Join Date
    Mar 2012
    Posts
    150

    Re: Autoleveler not working

    Quote Originally Posted by joeavaerage View Post
    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.

  16. #36
    Join Date
    Nov 2013
    Posts
    4280

    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

  17. #37
    Join Date
    Mar 2012
    Posts
    150

    Re: Autoleveler not working

    Quote Originally Posted by joeavaerage View Post
    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
    Thanks, Thanks and Many Thanks, I tried the Basic Viewer and its awesome.

  18. #38
    Join Date
    Nov 2021
    Posts
    2

    Re: Autoleveler not working

    Hi,

    you can try DigitizeGcode, a multi-level leveling gcode adpater:

    https://www.youtube.com/watch?v=zipZiqnzRZg

    Bye

  19. #39
    Join Date
    Jul 2014
    Posts
    1

    Re: Autoleveler not working

    Test usb stb5100

    https://youtu.be/2u_ktpzj0Cs

Page 2 of 2 12

Similar Threads

  1. PCB Autoleveler Plugin for UCCNC
    By cahit in forum UCCNC Control Software
    Replies: 106
    Last Post: 11-22-2019, 01:41 PM
  2. Setting drills, ID tools and back working/end working tools
    By jonathan2jones in forum CNC Swiss Screw Machines
    Replies: 5
    Last Post: 04-22-2017, 01:11 AM
  3. What is the difference between wood working and metal working routers?
    By LaughingJaguar in forum Joes CNC Model 2006
    Replies: 9
    Last Post: 10-17-2016, 07:29 PM
  4. Switch view between machine working enveloppe and job not working?
    By skillalot in forum Screen Layouts, Post Processors & Misc
    Replies: 0
    Last Post: 08-10-2015, 03:55 PM
  5. it's not working!
    By mattstiger in forum Hobby Discussion
    Replies: 1
    Last Post: 04-25-2012, 05:31 PM

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •