C axis sensorless homing works

Discussion in 'Motion System' started by orcinus, Aug 20, 2019.

  1. orcinus

    orcinus Well-Known Member

    Joined:
    Oct 20, 2015
    Messages:
    336
    Likes Received:
    113
    Yeah, i did, no changes in any of the axes, at least as far as i can tell manually.
    The problem is that when this happens, it happens once or twice, then it's fine again, so it's extremely hard to repro / debug.

    The S1 sensitivity setup i had going was on the very edge of repeatability, so i guess it's very easy for pretty much anything to throw it "over the edge".
     
  2. orcinus

    orcinus Well-Known Member

    Joined:
    Oct 20, 2015
    Messages:
    336
    Likes Received:
    113
    I mean... S2 works fine too, and is still a bit gentler than the default setup from the github repo.
    it's just not "float like a butterfly" gentle when homing, and i'm oddly obsessive about stupid things like that.

    The C axis homing, however, still works beautifully.
    Which is ironic, considering that was the original objective of this post and my whole venture of experimenting with the sensorless homing settings :)
     
  3. Spoon Unit

    Spoon Unit Well-Known Member

    Joined:
    Sep 6, 2015
    Messages:
    1,560
    Likes Received:
    483
    It's a good thing. That said, the whole stall-method of sensing seems bound to have issues compared to a good solid microswitch.
     
    orcinus likes this.
  4. Greg Holloway

    Greg Holloway Administrator
    Staff Member

    Joined:
    Sep 4, 2015
    Messages:
    1,028
    Likes Received:
    632
    try changing the filtering type.

    In worse case the error in stall detection I think is 0.1mm, which is more than acceptable for toolchanges.
     
  5. Greg Holloway

    Greg Holloway Administrator
    Staff Member

    Joined:
    Sep 4, 2015
    Messages:
    1,028
    Likes Received:
    632
    try slowing things down too. edit the max acceleration and speed of the whole system in the config file.
     
  6. orcinus

    orcinus Well-Known Member

    Joined:
    Oct 20, 2015
    Messages:
    336
    Likes Received:
    113
    Rechecked.
    Homing axes individually yields the same result - i.e. when X starts to get false positives on stall detection (i.e. doesn't start to move, or starts and immediately stops), then homing X individually does the same. When Y does it, then homing just Y will do the same.

    If you then leave the machine on for a minute and try again, it will suddenly start working.
    That's where my theory of it being temperature dependent comes from.

    The whole notion of detecting load from back EMF is *heavily* dependent on both, ambient temperature and the coil temperature.
    It's inherently unreliable.

    Yes, it might have repeatability in terms of mm or microns, but we're not talking about that here, but the perpetually moving threshold of what's detected as stall, and what's ignored/filtered.

    I've tried with filtering, but that unfortunately just makes it never detect the stall at all at my current acceleration and current settings.

    I'll poke around some more when i find the time, there has to be a sweet spot of some kind.
    For what its worth, i've got the X axis homing reliably now, but now Y is misbehaving when cold.
     
  7. Greg Holloway

    Greg Holloway Administrator
    Staff Member

    Joined:
    Sep 4, 2015
    Messages:
    1,028
    Likes Received:
    632
    I will keep tracking of how stall detection is working as a whole. I personally have not had issues and find it works reliably enough for me.

    If the problem persists I will see what can be done about adding x/y endstops. I already have an idea on how and what to do......
     
    orcinus likes this.
  8. orcinus

    orcinus Well-Known Member

    Joined:
    Oct 20, 2015
    Messages:
    336
    Likes Received:
    113
    I've just had another really nasty crash caused by Y axis failing to home/stall detect on a cold machine.
    And this time i didn't even have sensitivity too high or anything. I gave up on "gentle" homing until i have time to play with it and tweak it safely.

    It failed to return the tool to dock due to Y offset, then proceeded to do a G30 (Z0 datum probe) with the tool still semi-attached.
    Failing to trigger the Z endstop and forcing the tool up against the T-bar.

    Looked and sounded pretty nasty, hope there was no permanent damage/bends/misalignment.
    Bed mesh shows the same sag it always had, so i'm guessing not, at least as far as the carriage is concerned.
    T-bar still rotates freely, so it doesn't seem like it's bent.
     
  9. Greg Holloway

    Greg Holloway Administrator
    Staff Member

    Joined:
    Sep 4, 2015
    Messages:
    1,028
    Likes Received:
    632
    Can I suggest a reset of all your scripts to the default ones?
     
    orcinus likes this.
  10. orcinus

    orcinus Well-Known Member

    Joined:
    Oct 20, 2015
    Messages:
    336
    Likes Received:
    113
    That's just the thing.
    They *were* reset to the default ones.

    I've bumped the sensitivity down to S4 now (down from default S3) for fear of it happening again.

    Could this just be a matter of grease getting too viscous?
    I think i now have a solid sample of it happening only (and i mean truly only) when the machine is freshly started, completely cold, and has been under the AC (set to 23C) whole night.
     
  11. Krayn

    Krayn Well-Known Member

    Joined:
    Aug 11, 2019
    Messages:
    49
    Likes Received:
    14
    This just happened to me last night. I was turning on the machine, immediately homed all, the y axis didn't seem to home properly, the machine then tried to home the z and slammed the carriage to the front, and then raised the z until the bed hit the actual toolchanger body and stalled the motor. I turned off the power as quickly as I could. I inspected the machine for damage, luckily there did not seem to be any. I turned the machine back on and homed each axis individually and it worked fine this time. I did another home all thinking that the homeall script might have been broken somehow and it worked fine as well. I'll check later to see if I had done any changes to my homing scripts, but I believe i have only updated my system gcode with changes from the github.
     
  12. Spoon Unit

    Spoon Unit Well-Known Member

    Joined:
    Sep 6, 2015
    Messages:
    1,560
    Likes Received:
    483
    I've had a few too. I think it's probably worth any new user being EXTREMELY cautious while getting familiar with the machine. Never run a print without homing. Never home without being there. Preferably have your finger ready on the Emergency Stop button. Actually, from the first moment I ran homing and saw the speed of the machine I realised it could probably make some scary crashed.

    One crash I've had twice though is completely my fault. Quite funny really. The traffic cone prints, by default right in the center. Somehow I hit homing without looking at the bed. Twice. Basically the bed jams the print up into the toolhead, and rather beautifully, the center of the cone slips right over the Z stop. Thus is just keeps pushing. Z does not such thing as stall detect (yet), so you just hear straining and feel panic. If you do run into the same thing, a simply re-home of Y after the restart is enough to lift the Z stop out of the print, so you can remove.

    Another thing that's going to be relatively frequent I suspect during the learning process is the emergency stop for various other reasons. Print adhesion for example. So you have a reset, and you still have a tool attached. During X homing, if not observed, the tool will drop straight onto the bed. Hard metal pointy object onto whatever you have below. Various outcomes possibly, few of them happy. Simply hold onto the tool during C homing, and when it detaches, redock it by hand. You can't simply use docking macros as the system is not homed and has no idea where it is.

    Another warning I would make is to be wary of pushing Z to it's limit. I've reset the machine's limit to 285 for now. I could not get to 300 without horrible straining sounds. I'm thinking even 285 might be a touch too far given that homing has no interest in where the bed is until it does Z homing, so if you're at 285, and the homing system pushes to 295, by my reckoning it won't make it. I hope Z isn't damaged, but I suspect it's very resilient and constrained with some serious comforting overkill given the combination of Z scre to drive, and hiwin rail to constrain. I wondered if the POM nut was actually free to move ...

    I've had the Z crash into the back as a result of Y insta-stall, followed by X home, followed by Z home attempt. I hit emergency stop before the bed came up. I'm seriously considering a proper industrial stop button in a fairly forward location. Given the unpredictability of wifi I don't want to be panicking waiting for the WebUI come up. No PanelDue here, as the web interface has always been sufficient. Perhaps I should have gone with the wired option despite the lower throughput for gcode uploads I've experienced.

    At present I'm back to the stock homing system and I'm not likely to touch it again. Two clunks beats the scary training sound. But nonetheless, I've seen Y insta fail a couple of times and instantly hit the off-switch.

    That said, it's still a wonder to behold. Once the print starts, it's all good, once you've got your tuning sorted.
     
  13. orcinus

    orcinus Well-Known Member

    Joined:
    Oct 20, 2015
    Messages:
    336
    Likes Received:
    113
    Even with paneldue, coming to the front and then hitting that little red button in the corner while the bed is crashing and you're panicking isn't quite a breeze. A hardware E-stop button would be a good idea.
     
  14. orcinus

    orcinus Well-Known Member

    Joined:
    Oct 20, 2015
    Messages:
    336
    Likes Received:
    113
    It might also make sense to figure out and configure stall detection for X, Y and Z. Not endstop stall detection, but full time stall detection. Less potential for damage that way. Even if it's not 100% reliable at detecting a crash, it's better than nothing.
     
    Greg Holloway likes this.
  15. orcinus

    orcinus Well-Known Member

    Joined:
    Oct 20, 2015
    Messages:
    336
    Likes Received:
    113
    For what its worth, had 0 crashes these past 2 days.

    Another potential crash/disaster source i've found is this scenario:
    - you leave the tool on the head (e.g. from a cancelled or e-stopped job)
    - you turn the printer off (optional)
    - you hit home all without thinking

    Result:
    - C homes with the tool on the TC head, causing it to unlock
    - homing crashes the tool against the T-bar, or
    - homing acceleration just knocks the tool off the head, and it ends up on the bed, or falls off the bed on the bottom

    That tool presence switch would be super useful for detecting this scenario.
    If it'd be possible to run a conditional macro of some sort, the idea is that if you start the homeall macro, and the switch is on, homing is immediately interrupted and an error message pops up. There's realistically nothing else that can be done beyond that, as you can't return the tool to the dock without homing first, but that's enough to prevent damage.
     
    Digi2life likes this.
  16. Amr

    Amr Well-Known Member

    Joined:
    Jun 2, 2019
    Messages:
    130
    Likes Received:
    31
    Had this happen to me a couple of times now
     
  17. orcinus

    orcinus Well-Known Member

    Joined:
    Oct 20, 2015
    Messages:
    336
    Likes Received:
    113
    Did some free extrusion (no hotend) measurements on the problematic Titan on tool 0 to confirm if there's some kind of slipping or something. Results are... not very useful, and a bit odd.

    2mm/s - 50mm requested, 50.575mm pulled in
    5mm/s - 50mm requested, 50.95mm pulled in
    10mm/s - 50mm requested, 51.25mm pulled in
    20mm/s - 50mm requested, 51.45mm pulled in
    50mm/s - 50mm requested, 51.00mm pulled in

    I've been scratching my head for the past 15 minutes trying to figure out how this is possible... The non-linearity should be *opposite*. The faster it extrudes, the shorter the pulled in length should be, due to slipping and other effects, not longer. Something is very very off here.
     
  18. Krayn

    Krayn Well-Known Member

    Joined:
    Aug 11, 2019
    Messages:
    49
    Likes Received:
    14
    That's odd. Do your other extruders behave more predictably and uniformly? You didn't accidentally put the gears on the wrong way around like this guy?
     
  19. orcinus

    orcinus Well-Known Member

    Joined:
    Oct 20, 2015
    Messages:
    336
    Likes Received:
    113
    Nope, i even tore it down and rebuilt it just in case.
    It's bizarre. Even more bizarre - to confirm there's no random slipping, i've retracted the filament in the same order i've extruded - it ended up precisely on the very first mark, so it's very repeatable.

    As soon as i'm done with work, i'll tear down and rebuild the hotend as well.
    It has no bearing on the weird extruder non-linearity (i had it decoupled while testing), but i do still need to fix the original issue of screwy sloppy extrusion...
     
  20. orcinus

    orcinus Well-Known Member

    Joined:
    Oct 20, 2015
    Messages:
    336
    Likes Received:
    113
    After rebuilding the hotend, and doing a cold-pull just in case there's something in the nozzle, it's suddenly printing fine.
    Go figure.

    [​IMG]

    [​IMG]

    Ignore the stringing, had retract and linear advance off while debugging.
     
    mhe and Greg Holloway like this.

Share This Page