Hi I'm new to chilipeppr and cnc milling in general.


I’m new to chilipeppr and cnc milling in general.
I’m using a gShield with version 0.9.0 of grbl loaded. SJPS 1.93 on a mac. Tested on both safari and chrome.

In trying to run an auto level on a pcb I am persistently getting an alarm probe failure or just a ‘stop’ on the first test point. However the first test point works (the z stops at the board and well before the max negative z). running a test probe works fine too.

Any thoughts on what can be causing this?

The board’s copper layer is connected to the ground of the gShield and the probe is connected to pin A5 of the Uno. the milling bit I am using to carry the probe is normally conductive and, as said, the test probe works fine (i.e. it stops on reaching the board but it does not then retreat to a safety height).

thanks in advance


confirmed the same behaviour on edge on a win 10 platform connected via SJPS 1.88

as an aside, the test point grid also disappears after the first point is probed.

in case it is useful this is a copy/paste of the last few entries from the SJPS widget


Somebody from the Grbl community would have to weigh in. Grbl’s probing is different from TinyG’s and this feels like a Grbl nuance. I have heard Grbl folks having success probing though, so could be a setting on your device or firmware version.

hmm. I think I read a post earlier that recounted an almost identical issue (Rick Obel). I will try again this evening.

Rick mentioned having to press pause twice for each test point. that would be painful. If this behaviour is the same, would this be more likely to be a grbl issue or a widget issue?

hmm. started working well(ish) for 30 minutes. then i refreshed the chilipeppr page and back to the old behaviour.

I wonder whether anyone was pushing edits to the grbl workspace in the last hour? any way to tell?

No, I don’t think anybody has.

Just look at the Github project. It shows you when updates occurred. ChiliPeppr just loads right from Github (albeit via a ChiliPeppr cache in case Github is down).

that’s annoying then. very difficult to debug an issue with software when the same steps don’t provide the same result.

and interesting that the code in github is peppered with console.logs but yet nothing appears in the js console other than lots of output from the serial port widget and uncaught errors every few seconds.

I am also getting some random y-axis drifts now where chilipeppr suddenly thinks it is 10mm further down the y axis than it is. only happens when the auto-levelling code bugs out. so there is probably more than a coincidental linkage there.

nothing interesting in the serial monitor.

there are too many elements here for me to debug in ignorance of the chilipeppr code base and the grbl code base. Hopefully some one else will chime in.

I think you’d have to post a video of the problem to help folks understand. BTW, ChiliPeppr turns off all debug Javascript console output in the main workspace for speed. In the upper right menu of the browser window you can turn debug back on. Not sure if that’s the console you’re talking about. Also, if you are seeing lots of errors, that’s a bad sign. You should not get any errors in the Javascript console output.

I was talking about the normal js console accessible in dev tools. not sure how that can be turned off in chilipeppr unless you have interrupted the calls to the native console object.

i’m getting lots of output to the available js console so I assume it is not disabled anyway. But nothing from the auto-level widget. Most odd. it does make me wonder whether i am actually pulling in from the github version. i will have a look at the source code when this job finishes.

examples of the errors below. I am also getting a deprecation warning about THREE.linepieces for every rendering change.


job finished. the probing bugged out again after half the board. a probe fail this time. no reason for it at all - oddly z is reading 0.5 but the probe is actually on the board.


as per @jlauer 's request I took a video of chilipeppr + gShield bugging out during autolevelling.

the probe works during a probe test, and alarms on running the first live probe. obviously no change between the two except as shown.

is this a chilipeppr bug or do I have to unpick the problem inside grbl? (v09.j)? I don’t think that chilipeppr’s grbl workspace yet supports v1.1 but if that is not correct please let me know.
missing/deleted image from Google+

That alarm probe fail is a Grbl error. There’s no reason it should be saying there’s an error, so not sure why it’s doing that to you, but that’s Grbl, not ChiliPeppr.

i thought as much. I’ve looked at the grbl code (1.9j) and there is no debouncing at all on the alarm probe. this may be because their cycle timing sucks. But even then, at low feed rates, I’d expect there to be several hundred ISR ticks every milli second. you’d think that debouncing by two or three events might be an idea; if only to deal with noise and to allow the pin state to settle. I wonder why they haven’t done so.

If you have an Arduino Due handy, you could swap over to TinyG G2 and yet keep using your Gshield from your Grbl device. I do think there’s still a learning curve to G2, but it is an alternative idea. Or you could try other firmware versions of Grbl. It could also be a config like soft limits throwing you off.

possibly config but that wouldn’t explain why it does half the board sometimes, and doesn’t start the next. i need to go back and see where the alarm code is raised.

I don’t buy my idea of noise as that would just cause a ‘high’ point on the map. it shouldn’t case the whole thing to bug out. but nevertheless i do think debouncing would have been sensible.

unfortunately no dues about. twenty or so mega 2560s (a few on board but mostly chip only), a few unos and a dozen nanos but I have never needed a due.

i tried the 1.1 branch but it seems that chilipeppr does not support that.