Auto leveling on smoothieboard not working

[modulab]

Hi there! 1st thing, thank you for making this software available. 2nd thing, i've been having some trouble with the auto leveling sequence. Actually it never worked. After the probe's first contact i get an error: "Probe triggered before move" .Sometimes i get to probe two locations on the grid but that's it. Same error and full stop. I'm running on a smoothieboard, up to date with firmware and bcnc on windows 10. I have tried everything electrically : cap, shielded wire, em choke. I suspect it has to do with the difference between native smoothieware auto leveling or bcnc.

Can you please offer me some advice? It bugs me for so long now. Thanks, Paul

[HomineLudens]

Hi @modulab , is that exactly the error you read in bCNC? Do you read that message in the terminal output? I can't test with smoothie but I can have a look to understand if is something due to bCNC or simply some electric noise.

[pda3k]

I echo the thanks for this great piece of software. It is my "goto" CNC controller software for the Smoothieboard. I also experienced the exact same issue/error with the exact same conditions. It has been a while since I looked so I don't remember if the message was in the terminal or not. I seem to remember it being in bCNC.

[HomineLudens]

Can you post the output from the terminal tab when the probe routine fail?

[pda3k]

Below is the output as requested. I am running version 0.9.6

G38.2Z-25F5 [PRB:123.262,-191.878,-10.310:1] ok G0Z3 ok G0X31.739Y-32.879 ok G38.2Z-25F5 error:ZProbe triggered before move, aborting command. Run ended 2016-09-25 14:21:06.963000 Current: 16 [17] Completed: 23% [7s Tot: 7s Rem: 0s]

ok

ok

ok

error:ZProbe triggered before move, aborting command.

ok

ok

ok

error:ZProbe triggered before move, aborting command.

ok

ok

ok

[HomineLudens]

@pda3k just for test, can you post the output using this settings?

Also from some doc in the web it seems like smoothie can be interrogated about probe status using the command M119. Try to use the terminal tab and ask smoothie about probe state, both when the contact is closed and when open.

[pda3k]

As per your request, I did the steps mentioned above and below are the results:

Open connection test:

min_x:0 min_y:0 Probe: 0 M119 ok $G [G0 G54 G17 G21 G90 G94 M0 M5 M9 T0 F2000.0000] ok

Closed connection test:

min_x:0 min_y:0 Probe: 1 M119 ok $G [G0 G54 G17 G21 G90 G94 M0 M5 M9 T0 F2000.0000] ok

Probe Test:

<Idle,MPos:295.4778,338.0000,4.7000,WPos:0.0000,0.0000,0.0000> <Idle,MPos:295.4778,338.0000,4.7000,WPos:0.0000,0.0000,0.0000> <Idle,MPos:295.4778,338.0000,4.7000,WPos:0.0000,0.0000,0.0000> <Idle,MPos:295.4778,338.0000,4.7000,WPos:0.0000,0.0000,0.0000> <Idle,MPos:295.4778,338.0000,4.7000,WPos:0.0000,0.0000,0.0000> <Idle,MPos:295.4778,338.0000,4.7000,WPos:0.0000,0.0000,0.0000> <Idle,MPos:295.4778,338.0000,4.7000,WPos:0.0000,0.0000,0.0000> <Idle,MPos:295.4778,338.0000,4.7000,WPos:0.0000,0.0000,0.0000> <Idle,MPos:295.4778,338.0000,4.7000,WPos:0.0000,0.0000,0.0000> <Idle,MPos:295.4778,338.0000,4.7000,WPos:0.0000,0.0000,0.0000> <Idle,MPos:295.4778,338.0000,4.7000,WPos:0.0000,0.0000,0.0000> <Idle,MPos:295.4778,338.0000,4.7000,WPos:0.0000,0.0000,0.0000> <Idle,MPos:295.4778,338.0000,4.7000,WPos:0.0000,0.0000,0.0000> <Idle,MPos:295.4778,338.0000,4.7000,WPos:0.0000,0.0000,0.0000> <Idle,MPos:295.4778,338.0000,4.7000,WPos:0.0000,0.0000,0.0000> <Idle,MPos:295.4778,338.0000,4.7000,WPos:0.0000,0.0000,0.0000> <Idle,MPos:295.4778,338.0000,4.7000,WPos:0.0000,0.0000,0.0000> <Idle,MPos:295.4778,338.0000,4.7000,WPos:0.0000,0.0000,0.0000> <Idle,MPos:295.4778,338.0000,4.7000,WPos:0.0000,0.0000,0.0000> <Idle,MPos:295.4778,338.0000,4.7000,WPos:0.0000,0.0000,0.0000> <Idle,MPos:295.4778,338.0000,4.7000,WPos:0.0000,0.0000,0.0000> <Idle,MPos:295.4778,338.0000,4.7000,WPos:0.0000,0.0000,0.0000> <Idle,MPos:295.4778,338.0000,4.7000,WPos:0.0000,0.0000,0.0000> <Idle,MPos:295.4778,338.0000,4.7000,WPos:0.0000,0.0000,0.0000> <Idle,MPos:295.4778,338.0000,4.7000,WPos:0.0000,0.0000,0.0000> <Idle,MPos:295.4778,338.0000,4.7000,WPos:0.0000,0.0000,0.0000> <Idle,MPos:295.4778,338.0000,4.7000,WPos:0.0000,0.0000,0.0000> <Idle,MPos:295.4778,338.0000,4.7000,WPos:0.0000,0.0000,0.0000> <Idle,MPos:295.4778,338.0000,4.7000,WPos:0.0000,0.0000,0.0000> <Idle,MPos:295.4778,338.0000,4.7000,WPos:0.0000,0.0000,0.0000> <Idle,MPos:295.4778,338.0000,4.7000,WPos:0.0000,0.0000,0.0000> <Idle,MPos:295.4778,338.0000,4.7000,WPos:0.0000,0.0000,0.0000> <Idle,MPos:295.4778,338.0000,4.7000,WPos:0.0000,0.0000,0.0000> <Idle,MPos:295.4778,338.0000,4.7000,WPos:0.0000,0.0000,0.0000> <Idle,MPos:295.4778,338.0000,4.7000,WPos:0.0000,0.0000,0.0000> <Idle,MPos:295.4778,338.0000,4.7000,WPos:0.0000,0.0000,0.0000> <Idle,MPos:295.4778,338.0000,4.7000,WPos:0.0000,0.0000,0.0000> <Idle,MPos:295.4778,338.0000,4.7000,WPos:0.0000,0.0000,0.0000> <Idle,MPos:295.4778,338.0000,4.7000,WPos:0.0000,0.0000,0.0000> <Idle,MPos:295.4778,338.0000,4.7000,WPos:0.0000,0.0000,0.0000> <Idle,MPos:295.4778,338.0000,4.7000,WPos:0.0000,0.0000,0.0000> <Idle,MPos:295.4778,338.0000,4.7000,WPos:0.0000,0.0000,0.0000> <Idle,MPos:295.4778,338.0000,4.7000,WPos:0.0000,0.0000,0.0000> <Idle,MPos:295.4778,338.0000,4.7000,WPos:0.0000,0.0000,0.0000> <Idle,MPos:295.4778,338.0000,4.7000,WPos:0.0000,0.0000,0.0000> <Idle,MPos:295.4778,338.0000,4.7000,WPos:0.0000,0.0000,0.0000> <Idle,MPos:295.4778,338.0000,4.7000,WPos:0.0000,0.0000,0.0000> <Idle,MPos:295.4778,338.0000,4.7000,WPos:0.0000,0.0000,0.0000> <Idle,MPos:295.4778,338.0000,4.7000,WPos:0.0000,0.0000,0.0000> <Idle,MPos:295.4778,338.0000,4.7000,WPos:0.0000,0.0000,0.0000> <Idle,MPos:295.4778,338.0000,4.7000,WPos:0.0000,0.0000,0.0000> <Idle,MPos:295.4778,338.0000,4.7000,WPos:0.0000,0.0000,0.0000> <Idle,MPos:295.4778,338.0000,4.7000,WPos:0.0000,0.0000,0.0000> <Idle,MPos:295.4778,338.0000,4.7000,WPos:0.0000,0.0000,0.0000> <Idle,MPos:295.4778,338.0000,4.7000,WPos:0.0000,0.0000,0.0000> $# ok G0Z3 ok G0X0Y0 ok G0Z30 ok <Run,MPos:295.4764,338.0011,4.9947,WPos:-0.0014,0.0011,0.2947> <Run,MPos:295.4764,338.0011,5.6604,WPos:-0.0014,0.0011,0.9604> <Run,MPos:295.4764,338.0011,6.3341,WPos:-0.0014,0.0011,1.6341> <Run,MPos:295.4764,338.0011,7.0334,WPos:-0.0014,0.0011,2.3334> <Run,MPos:295.4764,338.0011,7.5585,WPos:-0.0014,0.0011,2.8585> <Run,MPos:295.4764,338.0011,7.6932,WPos:-0.0014,0.0011,2.9932> <Run,MPos:295.4764,338.0011,7.7071,WPos:-0.0014,0.0011,3.0071> <Run,MPos:295.4764,338.0011,7.9745,WPos:-0.0014,0.0011,3.2745> <Run,MPos:295.4764,338.0011,8.6046,WPos:-0.0014,0.0011,3.9046> <Run,MPos:295.4764,338.0011,9.3059,WPos:-0.0014,0.0011,4.6059> <Run,MPos:295.4764,338.0011,10.0073,WPos:-0.0014,0.0011,5.3073> <Run,MPos:295.4764,338.0011,8.7670,WPos:-0.0014,0.0011,4.0670> <Run,MPos:295.4764,338.0011,8.1410,WPos:-0.0014,0.0011,3.4410> <Run,MPos:295.4764,338.0011,7.4416,WPos:-0.0014,0.0011,2.7416> G0X0Y0 [PRB:295.476,338.001,6.885:1] ok G38.2Z-30F5 ok G0Z30 ok G0X5.5556Y0 error:ZProbe triggered before move, aborting command. Run ended 2016-09-25 18:53:35.886000 Current: 17 [305] Completed: 1% [12s Tot: 3m43s Rem: 3m31s]

ok

ok

ok

error:ZProbe triggered before move, aborting command.

ok

ok

ok

error:ZProbe triggered before move, aborting command.

ok

ok

ok <Run,MPos:295.4764,338.0011,7.5704,WPos:-0.0014,0.0011,2.8704> <Run,MPos:295.4764,338.0011,8.6640,WPos:-0.0014,0.0011,3.9640> <Run,MPos:295.4764,338.0011,9.7537,WPos:-0.0014,0.0011,5.0537> <Run,MPos:295.4764,338.0011,10.8454,WPos:-0.0014,0.0011,6.1454> <Run,MPos:317.7008,338.0011,7.9924,WPos:22.2231,0.0011,3.2924> <Run,MPos:317.7008,338.0011,6.9027,WPos:22.2231,0.0011,2.2027>

[PRB:317.701,338.001,6.730:1] ok

ok

ok <Run,MPos:317.7008,338.0011,7.9567,WPos:22.2231,0.0011,3.2567> <Run,MPos:317.7008,338.0011,9.0484,WPos:22.2231,0.0011,4.3484> <Run,MPos:317.7008,338.0011,10.1381,WPos:22.2231,0.0011,5.4381>

[pda3k]

Also, I use the below Gcode (as a macro) to do a simple probe to test and set the Z axis to zero with a touch plate. The touch plate is 9.6mm thick. Once it makes contact, it raises the tool to 19mm. This has always worked very reliably.

G30 Z9.6 G10 L20 P1 Z9.6 G0 Z19

[HomineLudens]

Be patient @pda3k , I'm testing to blind. Do you try using the G38.3 mode instead of G38.2? You can select it from here:

Maybe I can change the probe command in another branch using G30 instead, as you report it work.

[pda3k]

No worries. I'm glad I can be your "eyes". I tried what you asked and got the same results. When I executed the G38.3 command by itself, it worked perfectly. I decided to do each Z probe step manually via the command line and see if I got the error. When I did this, I got no errors. When running the AutoIevel routine, did notice that the error is generated immediately after the G38.3 code touches the plate for the first time. Once it is touched, the error is displayed and the probe then retracts. Do you think that somehow the probe retracts before the G38.3 code completes? I did lookup the below code in the Smoothie firmware. This is where the error message appears to originate from. Let me know if you want me to try something else.

else if(gcode->has_g && gcode->g == 38 ) { // G38.2 Straight Probe with error, G38.3 straight probe without error // linuxcnc/grbl style probe http://www.linuxcnc.org/docs/2.5/html/gcode/gcode.html#sec:G38-probe if(gcode->subcode != 2 && gcode->subcode != 3) { gcode->stream->printf("error:Only G38.2 and G38.3 are supported\n"); return; }

    // make sure the probe is defined and not already triggered before moving motors
    if(!this->pin.connected()) {
        gcode->stream->printf("error:ZProbe not connected.\n");
        return;
    }

    if(this->pin.get()) {
        gcode->stream->printf("error:ZProbe triggered before move, aborting command.\n");
        return;
    }

[HomineLudens]

That's strange. I saw the same code yesterday from smoothie's gitHub, maybe there's some issue in the planner with G38.2/3 . Anyway, here are 2 files, once is the standard result from the probe routine and the other a slighting modified version that add a G4 1 after each probe. At least in grbl, G4 should empty the buffer so maybe it could make the trick. Please try to run them and give some feedback.

probes.zip

[pda3k]

I tried both sets of G code. The "wait" code still had the error after the first probe. I tried replacing the G38.3 code with G30 and ran the same file. Everything worked perfect all the way to the end. The Z height came back with each probe. There must be an issue in the smoothie firmware that triggers this error when you try to feed it via a stream of data. Will the G30 code work as an alternate to the G38.2/3? The only drawback in using the G30 code is it uses the defaults for plunge & retract rate. It does allow you to override the retract rate by using Fxxx.

[HomineLudens]

Good job @pda3k . If really there's a bug we should ask to smoothieware team (maybe @wolfmanjm ) if they can check it. If it can't be fixed we could use another command for smoothieware but it will mess up the code. If possibile it should be avoided.

[wolfmanjm]

This is not a bug in smoothie G38.2 or .3 work perfectly for me (although I never tried it with BCNC). You should not use G30 that does not do what you think it does.

What maybe happening is you are getting noise on your probe causing it to trigger too early. Or the probe is triggered before the probe is issued (which is actually what is being reported). It also looks to me like bCNC is not waitin gfor the probe to finish before issuing move commands, from the output it looks like there are commands being sent while the probe is still active. This would be a bCNC bug, as it MUST wait for OK from any command and NEVER send anything until it gets an ok from the previous command.

FWIW Smoothie has autolevel built in I suggest you use that instead.

[HomineLudens]

Hi @wolfmanjm, thanks for your clarification. Probably the point is exactly the different way commands are streamed to the controllers. In grbl is suggested to fill the small RX buffer with most commands as possible (keeping count of sent characters). In this way the planer can calculate correctly the acceleration ramp. I'm not sure bCNC is doing something different for smoothie, not even waiting for the OK. Am I wrong @vlachoudis ?

[vlachoudis]

@effer correct bcnc is always filling the buffer with command unless of there is an explicit %wait. Which in autoloading with grbl is not needed since it will record the probe data asynchronously when ever they will be returned by the controller. @wolfmanjm If this is needed with smothie I could add an explicit waiting after a probing command

[wolfmanjm]

smoothie only sends ok when the probe is finished, so long as you ping pong comms with smoothie it should work. sending ANY command without waiting for prior ok will cause issues.

[pda3k]

Vlachoudis - I am happy to test any changes made. Just let me know. Thanks all for such wonderful hardware and software.

Phil

On Sep 29, 2016, at 5:52 PM, Jim Morris notifications@github.com wrote:

smoothie only sends ok when the probe is finished, so long as you ping pong comms with smoothie it should work. sending ANY command without waiting for prior ok will cause issues.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[HomineLudens]

From the grbl wiki the send/wait ok handshake seems now the preferred way to comunicate. Should we evaluate to use that protocol instead of filling buffer?

[pda3k]

Is there a test module/code I can try out?

[HomineLudens]

Hi @pda3k , just another test until something about the handshake with smoothie is defined. If you want to test: probeWait2.zip

[pda3k]

Thanks. I'll give it a try!

Phil

On Oct 18, 2016, at 1:33 PM, Filippo notifications@github.com<mailto:notifications@github.com> wrote:

Hi @pda3khttps://github.com/pda3k , just another test until something about the handshake with smoothie is defined. If you want to test: probeWait2.ziphttps://github.com/vlachoudis/bCNC/files/536944/probeWait2.zip

You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/vlachoudis/bCNC/issues/419#issuecomment-254581113, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ATjeiuhuO6r5MfzC9HrrFZovuUv76ITFks5q1QLkgaJpZM4J233e.

[pda3k]

It seemed to work - almost. It started out fine. Each probe would be executed and then it would pause for about 10 seconds. It went down the first row and then came back to X=0. It then got the "probe triggered before move" error.

I tried repeating the same steps again but this time, it seemed to execute faster between pauses (<1 second) but threw the error after about 4 probe cycles.

---

From: Filippo notifications@github.com Sent: Tuesday, October 18, 2016 1:33 PM To: vlachoudis/bCNC Cc: pda3k; Mention Subject: Re: [vlachoudis/bCNC] Auto leveling on smoothieboard not working (#419)

Hi @pda3khttps://github.com/pda3k , just another test until something about the handshake with smoothie is defined. If you want to test: probeWait2.ziphttps://github.com/vlachoudis/bCNC/files/536944/probeWait2.zip

You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/vlachoudis/bCNC/issues/419#issuecomment-254581113, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ATjeiuhuO6r5MfzC9HrrFZovuUv76ITFks5q1QLkgaJpZM4J233e.

[yoch2015]

Hello. I thinking because auto leveling does not work on smoothieboard. When observing the operation well, it was found that an error occurred immediately after the touch plate, and an error occurred even just before G38 was executed. It is said that handshake with smoothie ware is not defined,and by inserting '%wait' which was in comment of vlachoudis into the G-code at the time of scan execution, auto leveling was no error completed. There is no basis for '%wait' insert position. Thank you. modified file name : cnc.py

[PRZDLRD]

Just started using bCNC with a smoothie board. Excellent project, thank you. The autoleveling routine gave me the same errors as noted above. And the feedrate change was not responsive as in issue #466 https://github.com/vlachoudis/bCNC/issues/466 Using the example by yoch2015, thank you, I make my first attempt at python coding. This gcode sequence ran with out error and had expected feed rates before any code changes. G00 Z5 G00 X1 Y1 G00 F1 G04 P1 G38.3 Z-10 G00 F4000 G00 Z5 G00 X100 Y1 G00 F1 G04 P1 G38.3Z-10 G00 F4000 G00 Z5 G00 X100 Y100 G00 F1 G04 P1 G38.3Z-10 G00 F4000 G00 Z5 G00 X0 Y100 G00 F1 G04 P1 G38.3Z-10 G00 F4000 G04 P1 G00 Z5 G00 X0 Y0

Autolevel 'seems' to work for me with the following changes to cnc.py. I submit my feeble coding attempt to the masters of coding here.

G00 to prbfeed (G38 seems to grab the first feedrate and locks it in, needs a reset to change) G04 dwell for 1ms (doing this before each G38 cleared my error) Then issue G38 (prbrate here didn't appear to do anything) G00 to 4000 return to normal feed (don't know the variable so I had to hard code) Not sure how GRBL will handle this sequence.

---

#----------------------------------------------------------------------
# Return the code needed to scan for autoleveling
#----------------------------------------------------------------------
def scan(self):
    self.clear()
    self.start = True
    self.makeMatrix()
    x = self.xmin
    xstep = self._xstep
    lines = ["G0Z%.4f"%(CNC.vars["safe"]),
         "G0X%.4fY%.4f"%(self.xmin, self.ymin)]
    for j in range(self.yn):
        y = self.ymin + self._ystep*j
        for i in range(self.xn):
            lines.append("G0Z%.4f"%(self.zmax))
            lines.append("G0X%.4fY%.4f"%(x,y))
            lines.append("G0F%g"%(CNC.vars["prbfeed"]))
            lines.append("G04P1")
            lines.append("%sZ%.4f"%(CNC.vars["prbcmd"], self.zmin))
            lines.append("G0F4000")
            x += xstep
        x -= xstep
        xstep = -xstep
    lines.append("G0Z%.4f"%(self.zmax))
    lines.append("G0X%.4fY%.4f"%(self.xmin,self.ymin))
    return lines

---

[vlachoudis]

In Grbl the G0 doesn't use the F##, so there is no variable containing the feed rate of the G0 since this is in the setup of grbl. I can put a patch that for Smoothie to add a dwell of 1s before the probe, but I don't know what feed rate to put in the g0.

[wolfmanjm]

Please note that to match Smoothie the G4 Pxxx has been changed in smoothie to be in floating seconds not milliseconds, BUT only if smoothie is in grbl compatibility mode (ie the firmware-cnc build) which people would be using anyway for BCNC. Unfortunately for whatever reason reprap/Marlin decided to define the P as milliseconds. We do have an G4 Sxxx which is always seconds regardless of the build.

[wolfmanjm]

FYI G0 in smoothie uses the last feedrate specified for a G0 move if Fxxx is not specified on the G0 line. I was not aware the GRBL does not allow Fxxx on a G0 line, that would be very odd IMO.

[chamnit]

@wolfmanjm : G0 is considered a rapid motion. This means it always runs at the maximum rated speed of the machine. This is a defined property for G0, as shown here. Any feed rate sent with G0 doesn't effect how it runs. It'll only alter the feed rate mode for the next feed motion.

[wolfmanjm]

@chamnit well that is one way to interpret it :) I use linuxcnc and G0 Fxxx does indeed affect the speed at which that G0 runs. The "NIST spec" is not at all clear in that respect :) Also we need to support reprap/3d which of course has a totally different interpretation. Additionally we do not change how G0 works vs G1, I am aware that G0 allows you to not move along a linear trajectory, but again that seems a little unclear, and most firmwares seem to still plan the trajectory as it does for G1.

[chamnit]

@wolfmanjm : That's incorrect. LinuxCNC does not change rapid rate with a F word. I even took the time to check by downloading the current LinuxCNC 2.7 live and ran a few tests to verify.

If an F word is sent while in a G0 motion mode, it only alters the F feed rate stored and isn't used by G0, as described in the LinuxCNC G0 g-code description I linked to. Feed and rapids are and should be treated as two separate rates, otherwise what's the point of having both? FWIW, LinuxCNC does allow you to limit rapids, but this is a setting, not a g-code word.

I agree the NIST standard isn't very clear, but they do call G0 rapids as "traverse" rates, rather than "feed" rates. It doesn't say how traverse rates are set explicitly though.

I also agree that G0 can "dogleg", rather be a linear motion, to try to minimize motion time, but this is generally only seen on older machines/controllers. It can lead to unexpected crashes because the "dogleg" can move in unexpected ways depending on where are you in the machine and the target location. Linear motions are the preferred way to move because of this.

[wolfmanjm]

well maybe I have an old version or something. FWIW smoothie keeps separate modal feedrates for G0 and G1. and there is a default feedrate for G0 in Case F has never been specified for G0.