speed/torque LUT for better max set current

  • Hi,
    I do not know if any of this might already be in the firmware so please educate me if you know better:

    This is about "speed independent torque" via taking the specific stepper-model into account!

    I just observed that it is really hard for e.g. in my case the moving-plate-z-axis to find the right current-reduction on my stepper to have it working realiable when moving, but slipping-through when "crashing"

    Because of course a stepper has decreasing torque with increasing speed, a Look-Up-Table for the specific curve of any stepper (most companys with a "name" have them in their data-sheets/data-sites) could simplify setup with a sweet-spot where your axis runs realiable, but if you would crash it into e.g. the endstop - independent of stalldetection and other stuff - the motor would just loose steps and slip through because it has not enough torque anymore

    Of course this could get complicated because current could temporarily even have to be increased to try to always have specific amount of torque, depending on Vin and all that.

    So it would boil down to some sort of speed-independent-software-stepper-slipthrough-clutch even with step loss, as a first setup before perfecting trinamic specific things like stall-detection or so that are of course even better because of not loosing steps!

    The downside of a feature like this would be step-loss, the benefit a speed-independent - independent of what the specific stepper can handle as max A - (trinamic-independent) crash-damage-reduction where you do not have to buy expensive disengagement clutches for a stepper to back up an unperfect stall-detection...

    The setup of a stepper would maybe be diffrent then:
    1st) define LUT with maybe six to 10 points(?)
    2nd) define needed moving torque (via "max/peak current) @ given/fixed/predefined feedrate (M906) -> SOFTWARE KNOWS TORQUE YOU SET because via LUT and given FEEDRATE 🙂

    After that:

    -> software can calc max speed itself, because e.g. a certain speed that is not within the torque any more is not possible any more...

    AFTER all of that, the specific nice to have trinamic/what-so-ever-company-in-the-future-features can be set by the user, because THEN I would always be confident to try out advanced things if in the background the torque-fence is active 🙂

    Maybe also have an optional min-torque then later down the road to be defined for stall detection to work reliable at all feedrates (usually of course slow feedrates to be able to break fast enough...)

Log in to reply