Accelerometer Probe Demo

[U.S. Water Rockets]

I have not seen this posted here before, so I thought I would just leave this here.

[youtube]http://www.youtube.com/watch?v=dM--z7qAZ60[/youtube]

[Tincho85]

I want one

[mhackney]

I've talked to the guys about this since last fall. Got me interested enough that I found an interesting accelerometer with "tap" and a mini arduino to build a test. I have it all up and running now but it just requires too much "tap" to give a reliable/repeatable signal. The accelerometer I got is very sensitive and I can tune it down to measure a very slight tap but then the problem is it triggers as the printer does the probe. I'm working on some software to see if I can distinguish between probe movement and actual touch but it's been slow going. I wonder if SeeMeCNC guys ran into the same or similar issue.

[Jimustanguitar]

I know it's been one of the hangups on the Eris. They want to make sure that they get it just right before they unleash it on all of us

Is there a way to enable and disable endstops with GCode? Could you send the probing routine up front and then disable that sensor before the actual print begins in the start script?

[U.S. Water Rockets]

I want one

I want this as well to the point where I briefly considered making my own. I hesitate to do so because I really want to support the SeeMeCNC effort, and want them to get all the credit for the idea.

But I am not sure to what extent they are fleshing out this idea. It would be very easy to make a small PCB that connected to an unused endstop input and mimics a contact closure when the bed is touched. I'd be more inclined to fully implement communications to the accelerometer and explore using it to detect unpredicted positioning of the effector as well. To some extent you could use this to tell if a magnetic ball arm fell off and the print could be halted. Stuff like that would be easily possible.

I would love to see even a basic bed calibration using a simple endstop closure for sale soon. If there were a way to assist them, I would be all ears!

Of course I want an Eris ASAP too!

[mhackney]

There are ways to ignore it depending on firmware. But the issue - at least with my implementation - is the movement downward to probe triggers the accelerometer as it descends. By increasing the tap threshold, I eliminate that but then it takes so much "umph" to trigger when the probe hits the bed. You can also hear this in the video above, that's a lot of tapping force.

Now that I think of it, I do have FSRs installed on my test printer so it is sub-optimal from a rigidity perspective. I need to securely fastest the bed so it is completely rigid. I suspect that might improve repeatability considerably. It pays to think out loud!

[mhackney]

The idea has been around for awhile just google it. But no one has got it to work yet. This could be a consequence of lack of firmware support at the time (almost 2 years ago) but with RepRapFirmware now, delta auto calibration just works.

My implementation uses one of the AdaFruit Trinket ATtiny85 and an MMA8452 accelerometer. It looks like a standard endstop switch to the controller board so it would work with RAMBo, Duet, Smoothieboard, etc. This accelerometer has some very interesting capabilities and puts out a digital output, the version SeeMeCNC is using has an analog output. In my case, 2 chips, 2 resistors and you have all the electronics you need. It could be made into a 1cm x 1.5cm package easily. Here's the mount:

The arduino is disconnected in this photo.

[U.S. Water Rockets]

The problem I suspect is that you're not measuring a "tap". What is likely happening is that the accelerometer is really not moving an a smooth analog motion. If you slow it down, you're actually moving in "steps" (Stepper motor), so the accelerometer you use, being a digital version is sampling the output of the accelerometer asynchronously with the stepping of the motors, and this probably confuses the tap detection algorithm, because sometimes it looks at the sensor and it's at rest. Other times it looks at it and it's moving, depending on where in a "step" it happens.

Perhaps the use of an analog accelerometer allows a different detection algorithm that filters the stepping action or is sampling synchronously with the stepping of the motors?

I think if you were to synchronize reading the accelerometer with the stepping you could do this:
1. Step Motors
2. Read Accelerometer
3. If effector moved down, go to 1 for new step.
4. If effector remained stationary, stop. Plate contacted.

I bet that would help.

[mhackney]

This particular accelerometer has an explicit tap mode so it is actually measuring a tap. It also has optional filters to apply to eliminate spurious signals. I've tried it all.

You can't just sneak up on a stationary object with an accelerometer, there has to be a sudden decrease in acceleration for it to detect. The slower you go, the more sensitive the detection must be. That is the battle I'm fighting now. Sure, if I speed up probing I get a good TAP but I also slam into the bed with too much force. I've been talking to the engineers that developed the accelerometer so they might have some ideas. I can isolate taps in Z, Y or Z (or any combination) but that does not seem to help.

[Polygonhell]

The accelerometer idea was first proposed a long time ago, but as mhackney says as far as I'm aware no one has managed to produce a reliable solution using it.
It's unfortunate, it's a potentially very good solution, from something mounted on the platform (makes it good for a retrofit) you get probing with the hotend being the actual probe.
I actually ordered a couple of accelerometers to experiment with this, but watching other peoples work on it, I came to the conclusion it's just way to complicated a solution to a simple problem.
FSR's were just starting to come into vogue at about the same time, and those seem to have become the dominant probe mechanism.

[U.S. Water Rockets]

This particular accelerometer has an explicit tap mode so it is actually measuring a tap. It also has optional filters to apply to eliminate spurious signals. I've tried it all.

You can't just sneak up on a stationary object with an accelerometer, there has to be a sudden decrease in acceleration for it to detect. The slower you go, the more sensitive the detection must be. That is the battle I'm fighting now. Sure, if I speed up probing I get a good TAP but I also slam into the bed with too much force. I've been talking to the engineers that developed the accelerometer so they might have some ideas. I can isolate taps in Z, Y or Z (or any combination) but that does not seem to help.

The thing with the accelerometer is that I don't think there is a way they can detect an impact. The "tap" mode is something that it does internally with a CPU or some logic that looks for a sudden acceleration change with a certain profile or curve. It just sets a threshold of sensitivity and registers it and calls it a tap.

What I am suggesting is that it would be better to have a sensor that could be read at a very high sample rate by an external microcontroller. Each time the steppers motors step, a discrete movement would happen for each step. That movement would be a downward acceleration with a known profile or curve. With a really high sampling rate, you could detect and characterize each discrete step and identify a downward step by comparing it to an expected characteristic curve. When contact with the build plate happens, the current step would generate a truncated or distorted characteristic curve, instead of the expected known good step's curve. If the build plate just happens to be lined up perfectly so that the head is just barely touching after one step, then the following step would be totally distorted and you could know the head contacted at exactly the last step.

I bet if you had a fast enough sampling rate, you could infer the contact point within a particular step, based on where in the curve the shape changed.

If you use an analog accelerometer, you are only limited by the speed of your ADC, and you can get cheap microcontrollers with 14-bit ADCs that read 1 million samples per second. That would be enough to read a nice curve for each discrete step of the effector.

I think detecting a tap for this purpose is probably asking too much of the accelerometer you have, and you really need to do the detection yourself in software. I just don't think that this is the kind of tap it is meant to sense, and you can't change how it detects taps.

[mhackney]

Ah, yes, I agree their is signal processing going on in the chip. That's what attracted me to it - simplicity. It might be that it is optimized for a different application than this one. It was easy enough to try! I'm not prepared to invest a lot more in research at this point. I'm quite happy with my FSRs but a simple non-mechanical solution that's easy to retrofit would be well received.

[KAS]

So just an off the wall question.

What's the long term effect of "tapping" a brass nozzle against the glass do?

[lightninjay]

So just an off the wall question.

What's the long term effect of "tapping" a brass nozzle against the glass do?

From my understanding, since brass is one of the softer metals, you will eventually deform the orifice of your nozzle.

This could lead to oval orifices, or in worst case (failure of the probe, nozzle crashing into bed) a closed orifice.

[mhackney]

A LOT people have slammed nozzles into glass over the years way before auto calibration and very few have had an issue with the nozzle afterwards.I'm tapping against PEI. But, as long as the tapping force is low, I wouldn't expect any issue with brass distortion. If that's an issue, get a SS nozzle and that won't distort.

[TheIrishScion]

It seems to me like a nylon nozzle cover would solve the 'uncomfortably hard tap' problem. It doesn't have to actually attach to the nozzle itself either, just be centered where the nozzle is centered, and be of a very specific thickness. If SeeMeCNC or E3D wanted to, they could actually turn a clip ring and stop at a very specific height off the nozzle tip to which the nylon probe/cover could be clipped. Then subtracting the guard's thickness becomes a purely software exercise and you can thump the build surface as hard as you like (within the elastic limit of the nylon obviously)