Yet another Duet-to-HE280 accelerometer probe adapter

[CloudColorZack]

Just for anyone who hasn't already, make sure you add the TinyWire.m library to your Arduino libraries folder. I ran into that issue uploading the code to the Trinket.

Mhackney, you may want to add that to the instructions above.

[mhackney]

I'll add it to the source file header. Thanks for the catch.

[kraegar]

Working for me, using the 4 pin z-probe connector on a duet wifi.

I did have to comment out the

#define RESET_BEFORE_PROBE 1

line in order for probing to function at all.

Duet WiFi 1.17b firmware.

Edit, and thanks very much for the work and help on this, Michael - nice to have the accel probe working again!

[DodgeDerek]

Quick question if I could ask:

I have a Rostock V2 with a Prometheus V2 mounted in the 713Maker effector and the accelerometer board on top running on 12V.
I previously had everything running and then upgraded to the DuetWifi replacing the RAMBo in the base of the printer along with the Trinket.
I made clean wire runs with 22AWG for everything except for the hot end which uses 18AWG.

I'm seeing issues where it appears that the accelerometer board is not getting enough power and also does not detect taps.
Symptoms of the lack of power are the blue LEDs on the accelerometer and PEEK fan running while the hot end is off, but as soon as the heat is turned on, the fan stops and the LEDs go out.
The hot end comes up to temp just fine and the thermistor appears to be accurate.

Could this be a result of running the Duet in the base of the printer and the longer wire runs associated with it? Any input or things I can try would be greatly appreciated.

DodgeDerek

[earlynerd]

It would actually be pretty trivial to make a custom accelerometer board containing the IIS2DHTR accelerometer IC, and the ATtiny85. The schematics are published for the seemecnc board, and if the attiny and accel are both running at 3.3V you can skip all the bidirectional I2C logic level conversion stuff they have going on there. Plus it would be much simpler to use on any controller board which has a z sensor endstop input that way, not only the Duet. The simplest version could just be those two components and some decoupling, an LED to indicate when it senses the bed, an ICSP header for programming, and an optoisolated output to avoid the "hidden circuit" mentioned above, and avoid ground loops. It would be able to plug straight into the duet endstop port with only 3 wires and nowhere else, or be 12-24V+ input compatible to avoid the need to run an additional 3.3V wire down to the hot end. Theres a 3D STEP file for the seemecnc accel board, so mounting holes could all be made in the same locations for it to be a drop in replacement.

You could also make a version which brings together and connectorizes the hot end, thermistor/thermocouple/pt100, hot end fan, layer cooling fan, and 12-24V power similarly to the seemecnc board, but with endstop switch output instead of I2C interfac, and separate hot end and part fan control. Maybe even a pt100 or thermocouple amplifier if people would find that useful. I'm gonna draw something up really quick this morning for the "simple" version! I'd be happy to post up on git for everyone. I already bought a seemecnc board but it'd be nice not to have to have the trinket adapter.

[mhackney]

I've already done it. I was planning to release a product based on this but after literally 100s of hours of testing and tuning and I am not convinced that it can be made reliable and robust enough to work with a variety of surface materials, controllers, and printer conditions. So for now I've shelved the project.

[dc42]

Quick question if I could ask:

I have a Rostock V2 with a Prometheus V2 mounted in the 713Maker effector and the accelerometer board on top running on 12V.
I previously had everything running and then upgraded to the DuetWifi replacing the RAMBo in the base of the printer along with the Trinket.
I made clean wire runs with 22AWG for everything except for the hot end which uses 18AWG.

I'm seeing issues where it appears that the accelerometer board is not getting enough power and also does not detect taps.
Symptoms of the lack of power are the blue LEDs on the accelerometer and PEEK fan running while the hot end is off, but as soon as the heat is turned on, the fan stops and the LEDs go out.
The hot end comes up to temp just fine and the thermistor appears to be accurate.

Could this be a result of running the Duet in the base of the printer and the longer wire runs associated with it? Any input or things I can try would be greatly appreciated.

DodgeDerek

I don't have a Rostock so I know how that hot end is wired. But I'll hazard a guess that the hot end heater, one or more fans, the blue LEDs and the voltage regulator that feds the LEDs share the positive supply wire. Is that the case? If so, reversing the heater connections at the Duet would fix it. But please don't try this without understanding the wiring first.

[earlynerd]

I've already done it. I was planning to release a product based on this but after literally 100s of hours of testing and tuning and I am not convinced that it can be made reliable and robust enough to work with a variety of surface materials, controllers, and printer conditions. So for now I've shelved the project.

Yeah I hadn't completely read through your top level post before I commented, and didn't see you had already mentioned the possibility... Is it just that setting the threshold for the deceleration which triggers the interrupt is very sensitive to bed surface or Z axis vibrations? SeemeCNC seems to be able to do it well with their newest printer revisions, but maybe they just tune that threshold to always expect a glass surface, or customize the tuning for individual printer models. I haven't read too many complaints regarding their auto-calibration on with the HE280, but I haven't really been looking.

I also noticed you're using polling rather than a hardware interrupt, would that help the situation at all? I want to avoid having to do manual bed leveling adjustments on my Rostock Max V2 and the accelerometer seemed like a pretty good way to go in my mind, but if there's a better way to accomplish that then i'd like to hear your thoughts on it. Looks like you've done some work with using FSRs?

I'm not asking for an in-depth analysis on the project or anything, but what exactly seemed to be holding it back? I've got most of a schematic already done but I wont waste any more time on it if it sounds like its not worth pursuing. Thanks for sharing your experience!

[mhackney]

It's actually more complex than just the threshold. There is an interaction between probe speed, probe acceleration, threshold, various parameters that affect the sensitivity and "scale" of the accelerometer.

The code you are looking at is multiple generations old. I have not posted any of the updates that I've been working on. In addition, I was working with trash80 and his version and code. We got things pretty far advanced by I just can't live with the inconsistencies I experienced. I have multiple delta printers with FSR probing systems that are always precise, robust and reliable. I was not able to achieve that level with the V3's accelerometer or the external accelerometer I was developing. But I do have requirements that are beyond what most normal users have. I am not saying the accelerometer probe is bad, I'm just saying that it isn't for me.

Yes, I have "some experience" with FSR probing and I have implemented nearly every probing system including David Crocker's IR probe and various proximity sensors, switches, etc. They all have tradeoffs. For me, the FSRs with the JohnSL board works with all print surfaces, has excellent reproducibility, accuracy and is extremely reliable. I do a full 6 point calibration in the gcode of every part I print. I need perfect first layers - especially for parts like the white mesh part in my avatar. Even a small error in first layer thickness will result in ugly parts or parts that don't stick.

The ONLY thing holding it back is lack of reliability and consistency. Even minor printer changes (like changing the radius of the probing points for instance) resulted in false probing or no probing. We were planning on open sourcing this probe so I am not adverse to sharing it. We were using a much more capable processor - the EEM8BB by ST, a really nice processor and prototyping board for projects like this. It is very possible that accelerometer probing can be made to work reliably with a variety of print surfaces, etc but based on the amount of effort I put into it, I am no longer willing to brute force it any longer when I have a perfectly functional alternative.

[earlynerd]

Fair enough, and thanks for the detailed reply. I'll play with the accelerometer board I've ordered when it arrives and start looking into FSR bed leveling. Those two appeal to me the most since bed surface material makes less of a difference compared to optical, inductive, etc...

Yes the EFM8BB2 series are definitely much better than ATtiny Same ones are used in electronic speed controllers running BlHeli_s these days, as you're likely already aware. 32-bit probably doesn't offer much benefit for something like this I suppose. Very probably already considered it, but perhaps the accelerometer combined with some type of distance ranging sensor (VL6180 time-of-flight sensors look interesting) could help detect the bed approaching and decelerate smoothly to a suitable speed to tap the bed? Possibly something clever could be implemented on FPGA, maybe one of those tiny Lattice ones, but that could just complicate things even more.

As you say there's little point to diving that deep into it when a much simpler solution with proven results already exists. Thanks for the info, seems like you've certainly got plenty of expertise in this area and I appreciate being pointed in the right direction!

[mhackney]

Actually, accelerometers are very sensitive to changes in bed surface hardness and rigidity, FSRs much less so.

Also, the dc42 firmware has some excellent features that allowed me to tune approaches, etc. In fact, David even implemented a feature on the probe connector to "arm" the probe right before contact so you can position near the take off point without fear of a false trigger. Thats in 1.17 version. You can also control the microsteps and accelerations with gcode in the probing script. Interestingly, increasing microstepping from 16 to 256 SIGNIFICANTLY improves things. We improved the sensitivity of the probe by using 2 or 4gs for full scale rather than the 16g full scale that the Repetier version uses. At this more sensitive scaling you can actually "see" the pulsing in the motor movements with 16 to 64 microsteps, and not at 128 or 256. It was fascinating and I'm spending more time looking at acceleration data, not for probing but for studying delta kinematics like jerk and the effect of mass on the effector. Oh, I forgot to mention that - changing the hot end from the HE280 to say an E3D V6 or even removing 1 or more part cooling fans changes things enough that the probe needs to be "recalibrated" (threshold, probe accelerations, probe speed).

[DeltaCon]

Sounds like really complex. Makes me wonder why SeeMe chose this probe concept in the first place, over the much cheaper, well-functioning fsr that has been around for so long and proven to work so well. Would it have been so much more difficult to implement that in repetier? Besides, the choice for repetier seems to be discussable also. But of course they have a lot of work in their branch already and will not give that up easily I suppose.

The acceleration data in your hands must have excellent outcome and insight sooner or later Keep up the good work Michael!

[Polygonhell]

Interestingly the accelerometer thing was tried a long time before SeeMe, I think I remember reading a thread on the Delta Google group, but it could have been the RepRap forum.
The people who tried it couldn't get it to work reliably.
It's a really attractive solution if you can get it to work reliably, it can be attached to any point on the tool head and it measures directly at the nozzle.

Personally I'm still not sold on attached probes at all, you calibrate machines so infrequently, a simple uSwitch that clips on such that it sits directly under the nozzle with a known offset seems like a better solution to me, and a whole lot less complicated.
On Cartesian machines where the offset isn't critical, I can see a better argument for attached probes.

[mhackney]

Yes, it has been tried, I think it was the RepRapWiki where I first saw it. It is attractive. The Grail for probes is one that works with any print surface, is precise, is fast, triggers from the nozzle tip, can operate with the bed and hot end being actively heated, is easy to mount, is very reliable, and affordable.

Effector mounted probes like accelerometers offer the potential for all of these. However, a simple bed mounted probe like maybe an acoustic or something similar would be easier to mount and run wiring. I don't know if that will be feasible without some sort of bed mount system - which is basically what FSRs provide. There are a couple of other ideas out there for probes that could be mounted on the effector that meet the other criteria - things like strain gauges or even the simple "3 point" contact probes that are used on CNC mills could be incorporated into the effector design.

I actually calibrate my deltas on every print. It is probably overkill, I probably really only need Z height adjustment. But it is so fast that I just do it. Those open mesh sideplates on my reels require perfect 1st layer thickness. Too thin and the plastic smooshes and the design looks like crap, too thick and there is not enough surface area to hold the part on the bed. So with calibration before every run, I get 100% yield of perfect parts so it's worth the 25 seconds.

[Polygonhell]

I recalibrate mine if I remove the buildplate or the hotend, or change the firmware, which might be once every couple of months or so.
But even then the only real adjustment I end up making is Z Height.

[dc42]

There has been some work recently on piezo-based probes built into the hot end mounting. There are threads about this on the duet3d and reprap forums. I have co-designed (with T3P3) a PCB effector with the piezo built in, and we hope to have prototypes to test within a couple of weeks.

The main challenge with the piezo-based probe appears to be mounting the hot end in such a way that the piezo flexes sufficiently to trigger when the nozzle contacts the bed, but without the nozzle being wobbly during printing.

[mhackney]

Send one my way David and I'll "test the heck"™ out of it!

[DeltaCon]

Besides the scientific curiosity you obviously have , what would you expect a piezo (or any other new probe) to have that an fsr doesn't? Reading your list of "requirements" a probe should have, I believe fsr fulfills all of those? Always good to have alternatives of course but it is hard to imagine anything be as rigid and simple as fsr's. I am still very glad I followed your blog-advise on these, and the duet

[mhackney]

An argument could be made:

An effector mounted probe may be perceived as easier to install (if it doesn't have to be positioned and placed in a certain way).

An FSR probing system reduces overall Z by 10-15mm but this could be corrected if the design was taken into account with the printer itself. For instance, the FSR mounting system on the D300VS doesn't really reduce Z at all.

The bed for an FSR system has to be very rigid. Many people build their printers with a simple borosilicate glass plate with a Kapton heater stuck to the back. That is not rigid enough In fairness, any contact probe will require a stiff bed.

And the biggie - a "perfect" probing system would not require contact at all. I don't know if this is possible while meeting the other criteria though.

I'm always on the prowl for the next great new thing. But FSRs with a Duet and dc42 firmware are at the top of the heap for dependability, precision, print quality, speed, simplicity, convenience, and a whole lot of other factors.

[DeltaCon]

Noted!
I almost forgot there are other printer designs then "just" a Rostock Delta

[DjDemonD]

Hi guys, just thought I'd chime in here with what we've been doing with piezo electric sensors. Basically we've designed a stable mounting system that allows one (with a hole in the centre) to be mounted above an e3d v6 hotend. The nozzle is firm, the sensor is not affected by heat, there is no offset, its reproducible and accurate to around 0.01mm. It needs a signal conditioning board for which we have a working surface mount PCB design in use. All open source.

So far I have not encountered any drawbacks. I've tested it on Marlin/Smoothie/RRF.

One other thing has become apparent that it allows for "auto first layer calibration" in that you can home, calibrate, grid level (if applicable) then use G30 (RRF) or G30 Z0 (Smoothie) to set the nozzle to exactly z=0, as the probe is sensitive enough to do this, then print your first layer at exactly the first layer height you sliced, no more paper tests/babystepping/offsets etc.. temperature and surface are unimportant as the gap is set by precise nozzle contact each and every time.

Most of the original work is by Leadinglights and Moriquendi on reprap, DC42, Dougal1957 have contributed and Lykle has designed some complete magnetic rod effectors to work with this system. Next steps are to try smaller piezos for a smaller/neater unit and work on making the system fail safe.
http://forums.reprap.org/read.php?1,635075,page=1 - from original work with piezo under-bed system to current iteration
https://www.duet3d.com/forum/thread.php?id=752&p=1 - more duet RRF focused discussion
http://www.thingiverse.com/thing:2069480 my version superseded by-
http://www.thingiverse.com/thing:2117069 - Lykles version

Hope this is of some interest. I have read through your accelerometer work here and its a shame it isn't as simple to implement, but for now I think we have a probe to beat IR's, FSR's, inductives. If anyone makes one please feedback to us on how you got on, its early days but looking very promising.
Simon/DjDemonD

[mhackney]

Yes, I've been following closely. Haven't made one yet. I spent sooooo much time trying to get the accelerometer probe to work that I put off dozens of projects. I'll wait a bit and see how this works longer term but I do like the idea and it does seem like it will have the reliability of FSRs with a simpler integrated effector mount.

[leadinglights]

I have only just found this thread and have been reading it with some fascination as it is possible that accelerometers probes may be a way of solving the sensitivity to mechanical noise that piezoelectric disk sensors suffer from.
One thing that does concern me though is that a probe speed of F1800 is mentioned in several places. Do you really use 1800mm/min approach speed? Have I misunderstood the significance of the F1800. On the piezometer sensors that I use in two of my printers I use probe approach speed of 1mm/sec.

Mike

[mhackney]

Have you looked at FSRs? They are an excellent solution that work under a wide variety of conditions, reliably. There is no reason why an effector/carriage couldn't be designed with an FSR rather than a piezoelectric sensor.

But, on to your question, yes F1800 and that is at the low end. The stock SeeMeCNC configuration for probe speed is much higher. My assertion (and verified through many experiments) was that high impact speed with an accelerometer probe can cause "distortion" in the mechanism. And, I have videos to prove that is indeed the case. The effector actually tilts slightly when it hits the bed surface. The slower you can probe, the less pronounced this is. But with accelerometers, you are measuring the rate of change of speed. If the speed is very low, the system just "pushes" and the probe does not trigger. If you start with a high speed, the contact can be detected.

We worked on making the accelerometer more sensitive by using its 2g full range rather than the 16g the SeeMeCNC code configures. We also changed the firmware acceleration settings (Duet) dynamically at probe time to remove the actual probing movement accelerations, and David Crocker implemented a special firmware feature to allow us to arm the probe when it was positioned and ready probe. THere were quite a few other optimizations I configured and tested too. At the end of the day, bed surface, effector mass, and lots of variables that I wasn't able to characterize affect the accelerometer triggering sensitivity.

[WZ9V]

Is this still being worked on or has it been abandoned?