Their Bug, Our Bug or Just Is What It Is



  • Hi,

    I've been putting together a rather nice little (210x210x230) printer kit out of China.

    I purchased it because it used a motion system that I had not worked with before - the kind that has the extruder assembly mounted on a pair of crossed rods that move in X and Y.

    Just for fun I decided to try these little closed loop steppers...

    BigTreeTech S42B Closed Loop Stepper

    They have been working just fine with one exception and I don't know if it is a bug in their firmware, a bug in the Duet firmware or just the nature of the beast.

    Below is a tiny bit of my config.g file - the part that I think is relevant:

    M569 P0 S1        ; drive 0 - normal   - ZL
    M569 P1 S1        ; drive 1 - normal   - ZR
    M569 P2 S1        ; drive 2 - normal   - E0
    M569 P3 S1        ; drive 3 - normal   - spare
    M569 P4 S1        ; drive 4 - normal   - spare
    M569 P5 S1        ; drive 5 - normal   - X external 
    M569 P6 S0        ; drive 6 - reverse  - Y external
    
    ; motor assignment
    
    M584 X5 Y6 Z0:1 E2 ; set what motors do what
    

    The S42Bs are connected to 5 and 6 - notice the external comment.

    Notice also that Y is reversed - which may be related to what is happening.

    For testing I used M564 to allow jogging before homing.

    On power up the X stepper works fine - it moves in the appropriate directions when jogged.

    However the Y stepper is behaving oddly.

    • If I first jog it in the +Y direction it moves in the -Y direction.
    • If I then jog it in the -Y direction it also moves in the -Y direction.
    • If I again jog it in the +Y direction it now moves in the +Y direction.

    And from then on it works fine - always moving in the appropriate direction when commanded.

    Thus my question - is it:

    • a bug in their firmware
    • a bug in the Duet firmware (Duet 3 Mini 5 running v3.2.0)
    • just the nature of a external driver marked in M596 as reversed
    • the 3D printer gods having a chuckle at my expense

    Thanks.

    Frederick



  • do you not need to set stepper timing for this?



  • @Veti said in Their Bug, Our Bug or Just Is What It Is:

    do you not need to set stepper timing for this?

    I think you may be correct. I do recall seeing that discussed and I completely forgot to see how it applied to my setup.

    Frederick


  • administrators

    External stepper drivers almost always need extended step timings.



  • @dc42 said in Their Bug, Our Bug or Just Is What It Is:

    External stepper drivers almost always need extended step timings.

    Thanks for the feedback.

    My external device has connections for:

    • power (two connections - 12 to 24 VDC for the stepper and 3.3 or 5 VDC for the electronics)
    • ground
    • enable (logic level can be set - defaults to active low)
    • direction (logic level can be set)
    • step

    I don't have a lot of specs for the device:

    • max speed 1000 rpm
    • max current 1650 mA
    • operating current - defaults to 800 mA - can be adjusted
    • steps per 360 degrees - 512, 1024, 2048, 4096, 8192 - selectable

    Reading the firmware docs it seems that only these M569 parameters apply for me:

    -- Pnnn Motor driver number
    -- Snnn Direction of movement
    -- Rnnn Driver enable polarity
    -- Taa:bb:cc:dd step pulse width and interval, direction setup time and hold time

    Are these the correct parameters for me to work with?

    Thanks.

    Frederick



  • you need to set the t paramter

    i would start the with a4950 datasheet

    https://www.digchip.com/datasheets/parts/datasheet/029/A4950-pdf.php



  • @Veti said in Their Bug, Our Bug or Just Is What It Is:

    you need to set the t paramter

    i would start the with a4950 datasheet

    https://www.digchip.com/datasheets/parts/datasheet/029/A4950-pdf.php

    Thank you.

    I will see what I can make of that information.

    This morning as a test I changed the Y driver setting from reverse to normal in the config.g file.

    It didn't appear to affect the normal operation of the stepper, it still went in the correct directions, but it did eliminate the movement in wrong direction after power up.

    Perhaps that setting does not apply to external drivers like these but was causing the problem in some manner I do not fathom.

    Frederick


  • administrators

    You need to find the correct M569 T parameters for that controller. BigTreeTech should publish the following:

    Minimum step high time (step pulse width)
    Minimum step low time (step pulse interval)
    Minimum direction-to-step setup time
    Minimum step-to-direction hold time

    Those values in microseconds should be used for the M569 T parameter.

    If you can't find them, try something like 2:2:10:10.



  • @dc42 said in Their Bug, Our Bug or Just Is What It Is:

    You need to find the correct M569 T parameters for that controller.

    Thank you for that information.

    I have the chip datasheet and will be studying it.

    Oddly enough it seems to be working fine with what ever the default T values are.

    At least "working fine" in the sense that simple test prints come out fine with no sign of strange stepper behavior.

    Thanks again.

    Frederick


  • administrators

    For microcontroller-based controllers like that, it is usually the last T parameter (direction hold time) if any that causes the problem. The symptom if you get it too small is very small layer shifts.



  • @dc42 said in Their Bug, Our Bug or Just Is What It Is:

    For microcontroller-based controllers like that, it is usually the last T parameter (direction hold time) if any that causes the problem. The symptom if you get it too small is very small layer shifts.

    Thanks again.

    I haven't had a chance to examine the datasheet but I will.


    It's rather early to tell but the movement in XY for any given speed is very quiet compared to my other printers which are using typical steppers driven directly from the duet board.

    I don't know if it is the driver, the nature of the "cross rods" XY motion system or just the smaller size of the printer (build area roughly 200x200x200 compared to 300x300x300) but I am rather impressed with this little printer.

    Frederick


Log in to reply