AutoLevel not working with G2core system

#1

This one is a bit weird. First the system:
G2core running on a Due, modified so probing works. Shield of my own design plugged into Due. Motors etc work perfectly, problem is with probing. The switch inputs do not connect directly to the Due GPIO pins, they go through a logic level opto-isolator which has push-pull outputs so the Due input is always being driven hard (20 ohm in either high or low). Hooked scope probe up to the Due input, there is never any noise on the input, it is perfectly quite until the contact is made (there is contact bounce but that is not the problem).

First tried with the touch plate widget, it works perfectly. So it seems like the input circuit is doing what it is supposed to be doing. I can run twenty probes in a row, they all work perfectly.

Then I close TouchPlate and try AutoLevel. It starts working fine, but on the eighth point I get an already tripped message. If I restsrt the AutoLevel from then on it always gives the already tripped message. The only way to clear this is kill the browser and SPJS and re-start, then the AutoLevel starts working and gives the already tripped message on the eighth point.

I’ve tried this many times and it is always on the eighth point.

I tried this on the little CNC router which has a grbl controller, using jpadie workspace, and AutoLevel works fine.

The fact that it always goes wacko on the eighth point seems to point to a software issue rather than random noise or some such. I suppose it could be either G2core or AutoLevel, but given that TouchPlate works 20 times in a row without the error message, it sort of points to G2core working all right with the probing. I haven’t looked into whether TouchPlate and AutoLevel use exactly the same probe commend so there might be a difference there.

At this point I’m stumped, I don’t know what else to look at.

Thanks,

John S.

#2

This sounds like the TinyG doing something whacky. I did find that sometimes you’d get a max down value on the probe, which is a setting on TinyG, and it goes into an error state. If you turn off the filter icon in the serial port console, you can see all the JSON coming back from TinyG and my guess is you’re seeing an error come back that ChiliPeppr just doesn’t have code for detecting and showing you a modal. It would be cool to have better error checking in CP to pop up indicators like that.

#3

I finally figured out what is actually going on. First off this is in G2core not TinyG so it might be a little different. When a probe starts it does not actually read the voltage on the input pin, it reads a value out of a structure. This structure is filled by an interrupt routine that is supposed to implement a debounce on the input. The interrupt is called whenever the pin value changes.

The problem here is that this debounce code is leaving the leaving the state of the pin in an incorrect value after dealing with the bounce when the probe lifts up off the board.

What seems to be happening is that if the exact area being probed is not rigidly glued down, when the probe lifts up the board starts mechanically oscillating at high frequencies, creating a long series of contacts with the probe. The standard resistor capacitor input circuit does not seem to help with this. I think the conventional wisdom is that contact bounce only happens when the probe is coming down but does not happen when it lifts off. The code seems to be able to handle the small amount of bounce when coming down, but the much longer series of “bounces” when lifting off seems to confuse it.

This seems to explain why I was having the issue at a specific location on the board, that location must not have been glued down so it was allowed to oscillate when the probe lifted up.

I’ve tried a number of simple RC network type circuits and they are not working well. I think I’m going to try using a Maxim MAX6816 debounce chip, it is specifically designed to deal with debouncing rising and falling edges in a simple to use chip.

But in order to try this I need to make a little test board and need auto leveling to work to mill the board! Back to the grbl controller to make that board.

So I don’t think this has anything to do with chilipeppr, just a weird interaction between the mechanics of PCB probing and the G2core code.

BTW it works fine when doing a TouchPlate probe, since that is just using the first contact and ignoring the after probe value.

John S.

#4

Wow. Fascinating. Totally makes sense though.

#5

You might want to have a look at the Issues list at https://github.com/synthetos/g2/issues
I have seen discussion of probe related improvements being added, but not always clear in what build they are implemented. You might have to try one of the edge builds and buld it for Due yourself. If you are running release 101.03, that might not be the most current probe code.
You are most likely to get a developer’s attention on that list.

#6

I finally have this working. I added a MAX6816 debouncing chip to the board and it took care of the problem. Perfect edges, but there is a downside, the chip waits 40mili-seconds to make sure the bounces have died out. This lets the tool continue pushing down into the board for 40ms. With the auto level default of 25mm/min this can be a problem, at 5mm/min it seems to be all right, there seems to be enough “squish” to the board to deal with this.

I’m happy now, auto level is working fine, board milling is doing great. I know there is probably a software solution for this, but the hardware solution was much easier.

John S.

1 Like