New firmware 1.21RC5 available
-
It's slightly more complicated than normal, because the name of the main firmware binary for the Duet WiFi and Duet Ethernet has changed.
To update a Duet WiFi or Duet Ethernet from RC2 to RC5, rename Duet2CombinedFirmware.bin to either DuetWiFiFirmware.bin or DuetEthernetFirmware.bin according to what your existing firmware and DWC expect. Then upload that file through the Settings->General tab of DWC. …....
I renamed the file Duet2CombinedFirmware.bin to DuetWiFiFirmware.bin when I try to upload from setting page I get an error
-
Is there already a DuetWiFiFirmware.bin file in /sys? if so, try deleting it first.
-
Thanks that was the problem.
David did you get the livestream to work?
-
I've upgraded to 1.21 RC5 firmware and 1.21 RC4 webcontrol
When I press the home all button, i get the following error
G28
Error: G0/G1: Insufficient axes homedI've never gotten this before and the setup as not changed from v1.20. Any idea what's causing this?
Most likely this.
From the release note for RC 3 we have:
"New features:On Cartesian and CoreXY printers, normal movement commands are no longer permitted until the corresponding axes have been homed"
Then we have:
"On Cartesian and CoreXY printers, normal G0 and G1 moves are no longer allowed before the corresponding axes have been homed. In particular, if your homex.g, homey.g and homeall.g files raise Z a little at the start and lower it at the end, you will need to add the S2 parameter to those G1 Z moves. Otherwise the G1 Z move will be refused unless Z has already been homed and the homing macro will be terminated."….
I had this problem after update and like I saw here I added S2 in homex.g, homey,g and homeall.g I was the abe to home X and Y.
When i tried homeimg Z i gato the error Insufficient axes homed so -i added the S2 in homez.g it did home except that while before when it reached the correct height it would stay there while now it raise the head. I
this is my homez.y
G91 ; relative positioning
G1 Z5 F6000 S2 ; lift Z relative to current position
G90 ; absolute positioning
G1 X219 Y190 F6000 ; go to first probe point
G30 ; home Z by probing the bed
any idea as to why its adding a G1 Z12 (that the distance is raises the bed.)Thanks
-
G30 now raises the head to the dive height after probing.
-
In this RC5 i test:
M569 T5 (old config) work perfect,
M569 T2.5:2.5:5:0 (new config) wrong (is supposed than this must work well)
M569 T5:5:5:0 (new config) seem well -
@FBG:
In this RC5 i test:
M569 T5 (old config) work perfect,
M569 T2.5:2.5:5:0 (new config) wrong (is supposed than this must work well)
M569 T5:5:5:0 (new config) seem wellWhat is the specification of your stepper drivers?
-
https://duet3d.com/forum/thread.php?id=4831 -
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?
-
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?
-
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.
-
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.
