New firmware 1.21RC5 available



  • https://duet3d.com/forum/thread.php?id=4831
    

  • administrators

    That diagram doesn't specify the minimum interval between step pulses. What does the datasheet say the maximum step rate is?



  • I've found that when I have tool 0 at say 220 degrees in the Web Control > Tools section and I then use Control All > Turn everything off I cannot turn the hot end heater back on by say entering a new target temperature.

    Is that expected behaviour?


  • administrators

    It's not expected behaviour, at least not by me! I've found that sending a T0 command turns its heater on again.



  • .

    But we also have:

    "Added M564 H0 command to allow axis movement before homing on Cartesian/CoreXY printers"

    So I'd guess that adding that M564 H0 to your config.g will restore the printer back to it's previous behaviour.

    Where do I add this in my config.g file?


  • administrators

    Anywhere you like; but then you run the risk that if you start a print without homing the printer, the head will crash into the endstops. That's why we recommend adding the S2 parameter where needed instead.



  • @dc42:

    It's not expected behaviour, at least not by me! I've found that sending a T0 command turns its heater on again.

    I guess it could just be a web app issue then.


  • administrators

    Looks like it's an interaction between DWC and the firmware. I have it on my list to investigate.



  • @dc42:

    PS - @DougJones, please can you try the version at https://www.dropbox.com/s/iq9pzfaugyfei7x/Duet2CombinedFirmware-even.bin?dl=0. This is an experimental build that tries to maintain regular step pulse interval at high speeds, so it may play better with servo drivers. The maximum step rate is reduced by about one third.

    I've tested this build with my motor separated from the machine to isolate any mechanical problem. I've marker a location on both the shaft and the motor, after a print, with the same coord as I drew the marks, the marks does not line up.
    Here is some properties for my machine:
    step per mm: 400
    max speed: 80mm/s
    acceleration: 1000mm/s^2
    jerk: 4mm/s
    M569 P5 S1 R1 T2.5:2.5:5:5



  • I've just tried M569 P5 S1 R1 T5:5:10:10, the marks still doesn't line up, but it's at a different position from when I used T2.5:2.5:5:5.


  • administrators

    RepRapFirmware doesn't expect drives to need an enable setup time. So it's likely that the first few steps after the drive is first enabled will be missed. This won't normally matter because they will be homing steps.

    I suggest you install the 1.21 final release (which includes the change to modify the step pulse timing) and re-run your test; but this time, command the motor to move a little (so that the firmware enables the driver; and only then mark the position so that you can compare it at the end. Also make sure that you don't have a M84 or similar command in your end GCode, because that will disable the drivers.



  • @dc42:

    RepRapFirmware doesn't expect drives to need an enable setup time. So it's likely that the first few steps after the drive is first enabled will be missed. This won't normally matter because they will be homing steps.

    I suggest you install the 1.21 final release (which includes the change to modify the step pulse timing) and re-run your test; but this time, command the motor to move a little (so that the firmware enables the driver; and only then mark the position so that you can compare it at the end. Also make sure that you don't have a M84 or similar command in your end GCode, because that will disable the drivers.

    I've just re-ran the test with the 1.21 final release, and the problem persists. My driver is enabled before I mark the position on both this test and my previous tests, there is no homing or M84 or any other command that would affect the shaft position in the gcode. I'm actually not only comparing the marks at the end, but also during the test, I pause the print, issue G1 X100(where i draw the mark), and compare the marks, they don't match up, it also drifts slightly between pauses.



  • I've tested with the special "even" firmware you suggested. I put the closed-loop stepper back on the x-axis.

    Running the 3DBenchy again, I get the same results (still getting the layer shifting). I am using the following settings for signal generation:

    M569 P6 S1 R1 T10:10:7:2

    I am printing at 40mm/sec with 80 pulses per mm, so that's about 3200 pulses pulses/second or 3.2kHz (that's a GT2 belt with 20 teeth - one rev per 40 mm - drive is set to 3200 p/rev). That's not fast at all. So, unless I am missing something. I don't think I'm anywhere near the 25kHz. For information, the drives say they are good to a max of 200kHz.

    The same 80 pulses/mm correspondes to 16x microstepping and when I use the builtin stepper driver with these speeds/settings the parts produced look pretty good with no layer shifting.



  • FYI, my external drives are always enabled. I do not use the enable signals. So I don't think that I am seeing an issue related to enable signal timing.


  • administrators

    It sounds to me that your closed loop drives are missing steps under some situations. Do they have an alarm output that you can monitor, to see if they know that they have missed steps?



  • I have my alarm connected to a end stop and set a trigger to emergency stop. It never triggers during a print. To me it doesn't look like missing steps, my steppers are over powered for my print, and the pattern of shifting seems consistent and gradual, it's not shifting by a entire step each time, rather it's shifting by steps.



  • The alarm signal never triggers


Log in to reply