Question about Auto-Level. Is this slight delay between probes normal and by design,

Question about Auto-Level. Is this slight delay between probes normal and by design, or is my setup just acting oddly? Seems to me it could complete an Auto-Level job a lot faster if it spent more time moving and less time not moving.

Sound’s normal for me, the machine move to the next point and i think the widget analyze the updated position before he call the probe command, this needs max 250ms or more.

If you are referring to how slow it probes down, that’s all about getting an accurate read. The up move and the move to next position can be fast.

No I mean the delay after it probes, goes up, moves to next probing location, then it waits a bit before beginning to move down again. It just seems to me that it could start moving down right away instead of waiting a couple seconds. If this is normal, then I guess its normal. I was merely observing the behavior and was curious why it spends so much time pausing between operations. The slow downward probing speed is completely understandable.

It’s really hard to tell from your video but the sound sorta helps. Are you running Grbl given that’s a Shapeoko?

My setup is
TinyG v8 firmware 440.20
SPJS 1.92
Chrome v.53.0.2785.116 m

Whoa. Wait…Chilipeppr has auto level? I’ve used the z probe setting, but that was just for setting the work piece top.

Oh my yes. Definitely a must if you’re going to mill 0.1mm down into copper board on a Sahpeoko2 in my case since the base is not 100% flat and never will be.

One trick I learned in case anyone runs into it, at least for me… If you use EagleBRD, I have to import the board, setup the settings, render and send the gcode to the workspace. Then I must refresh the entire browser page and let CP load the cached version before I can run Auto-Level. If I go right from EagleBRD import to Auto-Level without a browser refresh in between, it always stops after the first probe.

1rst: I love ChilliPpre and auto-leveling.
2nd: I also noticed this lag behaviour: there is a lag time between each probe, and this lag time gets longer and longer as the probing goes. On a large PCB this can easily become 1 - 2 seconds between probes. I guess it needs to do things like re-sorting the array of probes data, and that operation is longer and longer as the array becomes larger… (just a blind guess here). Does anyone knows if I can do something to shorten this lag? Changing software/hardware versions? (I have grbl 0.9i on straight and original arduino uno and gSheild 5b)

How many probe points do you do? The grbl version of auto-level is different than tinyg version. I’ve not experienced this myself but have not directly used the grbl version, only tinyg. There is code in auto-level that tries to unallocate all of the memory for the 3d plane that is about to get rewritten to show the new warpage. It’s possible it’s in that unallocation it gets slow. Would you be up for rejiggering the code?

Thanks john. I’m far from my CNC, I’ll check if the software allows me to just turn of the 3d plane GUi rendering while it’s probing. The board was a 150 by 40mm board with points every 5mm. That makes us 240 points if my coffee was strong enough. And yes, I would love to contribute, although I’m not familiar (I’m an old windows-C++ programmer) with the deveolpment tools’d I need. I made a couple of js-php-mysql-json-bootstrap things but know nothing about github and whatever other tols I’d need. If someone could just tell me a bit about the typical envirionement you guys use I would give it a try.

One of the best places to start is to watch the 3 videos on the homepage. It gives you a good feel for navigating the code. Then you can just fork the auto-level widget on it’s own and play around with it. You end up, typically, in a cloud9 IDE that let’s you edit the code just on the widget to play around with changes in a full editor. It’s a pretty sweet editing process since each widget is built on it’s own.

Thanks John. I’ll put an eye into this. The hint you gave me about graphic rendering leads me to this question: Would it be faster if I had a proper grafic card? ( I have no graphic card, it’s just the stock chipset on the motherboard of my win7 pc). I just measured 10 seconds between each probes toward the end (± 75%) of a 150*90mm board. And II’d rather pay some $ if it solves the problem. Sounds like it’s worse on my system.

I doubt it’s your video card. The deallocation of memory would be in your main RAM. The Grbl version does truly have a different algorithm on that because Jarrett Luft, who built it, did do a different technique on the deallocation.

Thanks John. Does that mean that changing to something else than grbl would fix tthis? What do you know that works well and is cost friendly? TinyG? What version/config if this question applies?

Hi john (and to anyone with knowledge on how to update chillipeppr)
I found the bug, I think it in the autoleleve widjet.js line 1313 to 1320
Like you suggested, I stopped the 3d rendering during probing.

The problem is: I don’t know how to use github/fiddle and after a couple hours trying, I know I won’t be able to make it in a short period of time. Would any knowledgeable people would make this usable by us? I would do if I had the time but I can’t.
lines 1313 to 1320 in “widget.js” should be replaced with this:

// update matrix to show results
/* This bit of code commented-out by Jocelyn Bouchard, 22-08-2017
if (!this.isMatrixShowing)

            // Replaced with this to help the autolevel go faster (I hope!)
            if (this.isMatrixShowing) {

Now if you choose to hide the probe matrix, it won’t reverse that choice and redraw without your consent.

here is a link to the modified file:

Thanks all. That will save me from going crazy trying to learn a new programing environement!