Autoleveler not working - Page 3

Page 3 of 4 FirstFirst 1234 LastLast
Results 25 to 36 of 37

Thread: Autoleveler not working

  1. #25
    Registered CitizenOfDreams's Avatar
    Join Date
    Nov 2012
    Location
    USA
    Posts
    684
    Downloads
    4
    Uploads
    0

    Default 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.



  2. #26
    Registered
    Join Date
    Mar 2012
    Location
    UK
    Posts
    147
    Downloads
    0
    Uploads
    0

    Default 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.



  3. #27
    Registered
    Join Date
    Nov 2013
    Posts
    256
    Downloads
    0
    Uploads
    0

    Default 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



  4. #28
    Registered
    Join Date
    Nov 2013
    Posts
    256
    Downloads
    0
    Uploads
    0

    Default 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



  5. #29
    Registered
    Join Date
    Mar 2012
    Location
    UK
    Posts
    147
    Downloads
    0
    Uploads
    0

    Default 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?

    Last edited by ZeroBacklash; 02-10-2019 at 03:14 PM.


  6. #30
    Registered CitizenOfDreams's Avatar
    Join Date
    Nov 2012
    Location
    USA
    Posts
    684
    Downloads
    4
    Uploads
    0

    Default 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.



  7. #31
    Registered
    Join Date
    Nov 2013
    Posts
    256
    Downloads
    0
    Uploads
    0

    Default 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



  8. #32
    Registered
    Join Date
    Mar 2012
    Location
    UK
    Posts
    147
    Downloads
    0
    Uploads
    0

    Default 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.



  9. #33
    Registered
    Join Date
    Mar 2012
    Location
    UK
    Posts
    147
    Downloads
    0
    Uploads
    0

    Default 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?



  10. #34
    Registered
    Join Date
    Nov 2013
    Posts
    256
    Downloads
    0
    Uploads
    0

    Default 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



  11. #35
    Registered
    Join Date
    Mar 2012
    Location
    UK
    Posts
    147
    Downloads
    0
    Uploads
    0

    Default 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.



  12. #36
    Registered
    Join Date
    Nov 2013
    Posts
    256
    Downloads
    0
    Uploads
    0

    Default 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



Page 3 of 4 FirstFirst 1234 LastLast

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
  •  


About CNCzone.com

    We are the largest and most active discussion forum for manufacturing industry. The site is 100% free to join and use, so join today!

Follow us on


Our Brands

Autoleveler not working

Autoleveler not working