New firmware 1.21RC5 available
-
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.
-
Looks like it's an interaction between DWC and the firmware. I have it on my list to investigate.
-
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.
-
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.
-
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.
-
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
