New firmware 1.21RC4
-
I updated to RC4 over RC3, and can confirm that leaving the firmware filename as Duet2CombinedFirmware.bin on my computer when uploading via the Setting tab on DWC worked fine.
Basic web/DWC connectivity seems fine. Homing, heating, fans, and basic XYZ movement on my Kossel Mini delta were also fine. That is all I was able to accomplish today.
John
-
You don't need to add S2 to those moves…
I must have been tired when I updated my scripts, because I didn't think that worked the first time around on RC3. Yes, it's happy now without the S2. (Sorry for the trouble there.)
A couple other nonblocking odds and ends:
-
I noticed that I needed to add a recovery time to my M558 commands where previously I did not need it. My homing scripts switch between different probes (M558, G31, G30) and on RC4 now those G30 commands that were previously happy are now reporting "Z probe already triggered". Adding an R0.1 to the M558 resolved it.
-
On a fresh reboot, using the web console to jog around while unhomed looks to pop state while empty. Doesn't affect me really, but I suppose if someone had previously M120'd, this web console action might steal that stack slot rather than its own.
M120 G91 G1 X-10 F6000 M121 Error: G0/G1: insufficient axes homed Error: Pop(): stack underflow! -
-
Thanks for that report, I can see why the underflow message is appearing and I will deal with it.
I can see why a recovery time would be needed when switching probe types, it's because the averaging filters need to accumulate data for the new probe unless you are changing to type 8. Using G4 after M558 to put a small delay there should be another way of fixing it.
-
CoreXZ homing issue is sorted, thanks for that!
-
Great idea I'll try that. Thank you.
…
The other possible issue is if the machine has to be reset for some reason, the power does not restore so hotend cooling does not resume. Might it be worthy of consideration having a routine that checks the hotend temperature, and if it is above x deg C, initiates an M80 so the fan/water cooler can begin working again as soon as possible? I appreciate there are implication with thermal safety here. I'd propose 50 deg C for x, since that covers the glass transition temperature of PLA, the lowest of commonly printed materials.You could connect a small signal diode, cathode to your hot end FAN- pin and anode to PS_ON, so that when the hot end fan cuts in it will turn the power on automatically.
-
Or just include M80 in your config file, works for me
-
After updating to 1.21RC 4 my machine, again, has the issue of long pauses between executing commands. It seems that it is processing 2 commands at a time, pausing for 8 seconds or so, and then executing the next 2. This time, it did it at the beginning of a print though whereas before it did it at the end.
-
Just upgraded from 1.21 RC3 to RC4 with the latest Web Control as well, and when I press "Home X" (or Y or Z or all) in DWC, I get a [c]G0/G1: insufficient axes homed[/c] error.
I downgrade back to RC3 and it worked - am I missing something?
From the RC3 upgrade notes:
[[language]] 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.Thanks. I guess I didn't notice it because homing in RC3 works fine for me, and none of the changes in RC4 explained it.
-
Upgraded today and my coreXYUV is working correctly.
Thank you dc42 -
I can confirm that the laser mode with I1 now works as expected. Thanks!
-
After updating to 1.21RC 4 my machine, again, has the issue of long pauses between executing commands. It seems that it is processing 2 commands at a time, pausing for 8 seconds or so, and then executing the next 2. This time, it did it at the beginning of a print though whereas before it did it at the end.
Which Duet is this?
-
Working well on the RailCore - haven't had any issues.
-
After updating to 1.21RC 4 my machine, again, has the issue of long pauses between executing commands. It seems that it is processing 2 commands at a time, pausing for 8 seconds or so, and then executing the next 2. This time, it did it at the beginning of a print though whereas before it did it at the end.
Which Duet is this?
Ethernet with X5. Upon finishing the print, I cannot connect via DWC but inputs from the Panel Due are executed properly and it does not appear to have entered the slow state.
Right now it is doing it very consistently. The machine automatically homes at start up. Then I can start a print at which point the start.g is executed properly but it seems that when it switches back to the regular gcode file is when things get slow. Sometimes, I can get it to print without this happening but I just had about 8 tries in a row where it got slow.
-
So it's a problem with out-of-order execution. I think the fix I need to do is to make the M116 wait until there are no queued moves left before it checks whether there is anything to wait for. Meanwhile, if you insert a M400 command anywhere between the G1 command and the M116 command, that should work around the problem.
I can confirm that adding a M400 command as directed does seem to correct the problem. If changing M116 to wait for the queue, the same change should probably be made for any other commands (if needed) that wait for a temperature (such as M109, M190, M191, etc.)
Alternatively, why not queue G10 (and M140, M141) commands instead of instant execution? I'd hope that the "retract" form of G10 already is placed in the movement queue and not executed out of order (otherwise it could really mess up prints.)
Thank you
Gary -
G10, M140 and 141 are already queued - that's part of the problem.
-
Welp! I tried to update from RC3 to RC4, and it detects that its a firmware upgrade, goes through the process, but when it 'restarts' it just states that there was an invalid password, in which once the password is entered, the 'firmware version' is still at RC3
-
Doesn't update via USB for me either. Just does the disconnect sound, says that it could not read from printer, then can not write to printer, then that the device did not recognize the command (M997, M997 S0/S1).
Just stays stuck at RC3 lol
-
Try the following:
1. Upload Duet2CombinedFirmware.bin through Settings->General in DWC.
2. In DWC go to System Editor and delete the old DuetWiFiFirmware.bin file.
3. Rename Duet2CombinedFirmware.bin to DuetWiFiFirmware.bin.
4. Send M997. -
This is relevant to RC3 but I didn't got to report this before the thread were closed. However, no mention of this quirk in the bug fix list. After upgrade to RC3 on my Core XY the bed compensation macro misbehaves. After the probing it just stops and does the homing procedure, not the fast move back to 0,0.
When I checked, it seemed the system went into relative coordinate mode (G91) after the two bed probes. These probes serve to compensate for dual Z leadscrews (each has independent motor). I inserted G90 after the probe commands and all is fine again. Maybe this issue already has been covered as I have not read the entire RC3 thread.Please can you try RC4 without the extra G90 and see if the problem persists.
The issue seems to be resolved. Thanks.
-
Try the following:
1. Upload Duet2CombinedFirmware.bin through Settings->General in DWC.
2. In DWC go to System Editor and delete the old DuetWiFiFirmware.bin file.
3. Rename Duet2CombinedFirmware.bin to DuetWiFiFirmware.bin.
4. Send M997.I'll give this a shot once the current print is over. (in about 15 hours x-x). Currently in the process of overhauling the printer with new parts in a slightly more stable design, so trying to utilize all the time I've got when I'm at work and sleeping.
