Unsolved Duet 3 stall detection and hardware customization and testing
-
Waiting on my Duet 3 this weekend after giving up on developing my own 3d printer control board using TMC 5160's even though I know some of the functionality is not going to be there such as being able to add encoders to the stepper motors.
Then as I was reading the firmware configuration limits and seeing that stall detection of the extruder was not functioning with G1 H1 and H moves. This got me a bit curious as to what issues the firmware was having with the extruder stall detection. Is it not detecting a stall or is it falsely detecting them?
Then my personal question, is there connectivity available to connect stepper encoders to the trinamics drivers? or would I have to add my own code to read encoder positions over SPI / I2C or whatever communication?
-
@Psylenceo said in Duet 3 stall detection and hardware customization and testing:
Then as I was reading the firmware configuration limits and seeing that stall detection of the extruder was not functioning with G1 H1 and H moves. This got me a bit curious as to what issues the firmware was having with the extruder stall detection. Is it not detecting a stall or is it falsely detecting them?
DC42 will have to answer for sure... but I believe there are no "problems", this just hasn't been added to V3 yet because it is very low priority.
Stall detect for homing is fun to play with, but is really a bit of a gimmick. It is not very accurate (and can never be because of the way it works). This lack of repeatable accuracy is more-or-less OK on X and Y on most printers, and it totally unacceptable on Z.
Anyway, limit switches are cheap, reliable, fairly repeatable, and so forth. With limited time for development, this just seems like a very low priority (to me, anyway).
-
@Psylenceo said in Duet 3 stall detection and hardware customization and testing:
Then my personal question, is there connectivity available to connect stepper encoders to the trinamics drivers?
The encoder pin inputs are not connected to any traces on the board. You'd have to VERY carefully connect something to those pins on the chip, and then have a way to wire to something. And, you'd have to modify the DuetRepRap firmware to initialize the proper registers in the TMC chip, and then respond to "events" as shown in other registers.
Having said all of that, the encoder basically provides a way to get a register flag (and/or interrupt, but I'm not sure if those pins are hooked up either) if the encoder deviates (a configurable amount) from where the TMC expects the motor to be. In other words, if a step skip occured in the physical world.
That's really it.
Not really clear to me what use that is on a 3D printer controller.
or would I have to add my own code to read encoder positions over SPI / I2C or whatever communication?
You could certainly do that. Given microstep interpolation, and the "scheduler" built in to the move planner in Duet/RepRap firmware, doing anything with those positions could become very interesting.
-
I don't consider sensorless homing as a gimmick. The way I've had to test it while testing trinamic drivers it was not very accurate due to the function in the library not actually sending the correct command nor receiving the correct info to set it properly. So I had to poll the motor load register and compare it to a set min that related to a stop, then send the stop position command. All of which added several us of delay. But, otherwise gave very usable homing positions and measuring, at least until a step was skipped of course. I really like this function because the Z -end stop on my Maker Gear M2 is a pain in the but to install, set, and it always moved. Since the sensor had to be clamped on a smooth rod.
I had a feeling they didn't add traces for the encoder IO, would have been really nice though. Guess I'll have to do encoders with an Arduino or other micro to send position data to the duet. The only concern is data bandwidth, timing, reaction time, and program timing. Whereas if the encoder IO was accessible the driver could handle skipped steps and stop/send interrupts.
The other issue with stall guard / trinamics skipped step detection is that they use the amperage and back emf from the motor, but the back emf I dependant on motor specs and velocity, along with the sense resistor value.
-
@Psylenceo said in Duet 3 stall detection and hardware customization and testing:
I don't consider sensorless homing as a gimmick.
I understand and respect your opinion. In fact, I find sensorless homing 'elegant' in a parsimonious engineering sense.
At the same time, given fixed development resources on the firmware, I'd put it somewhere below fundamental things like movement, or properly handling M999 (which V3 does not at this time), or similar.
Anyway, I do understand, and appreciate, the different perspective.
I'm going to guess that another place where our opinions differ is skipped step detection. I believe (opinion only, free and worth every penny) that a properly engineered 3D printer should never be anywhere near skipping a step. I further believe that if one skipped step does occur because of something out of kilter, like a jammed pulley, or whatever, that a lot of them are going to occur.
To me, it is not worthwhile to spend enormous time and energy making an "open loop" system into a hybridized solution. Not when true servos and controllers designed to use them already exist.
Again, if sensing a stepper in open loop were the only option, my opinion might be different.
Having said all of that... were I motivated to skip-detect, I believe I'd put the position sensing, and counting/matching/detection all local to the motor. And feedback only "OK" or "Not OK" to the main controller. Mostly because I'd find that elegant as well... and partially because that feedback could be connected to a general IO pin and dealt with as a "Stop" via configuration, no changes to the firmware itself.
Anyway, that's all just thinking out loud. Whatever you decide to do, keep us posted!
