New firmware 1.21RC3 available

dc42

Please can those of you running 1.21RC4 on a Duet WiFi try upgrading DuetWiFiServer to 1.21RC4. I need feedback on this version asap because a deadline is approaching.

resam

DC42:

Again, in case of failure or emergency there is no way to quickly move an axis after a reset.
I was stuck twice now since the new RC3 with a hot nozzle in either my bed or a printed part.
Immediate reaction is to hit the reset button to stop all further movements.
Now all axis are unhomed, the nozzle is melting away my part and bed surface - AND I CAN'T MOVE AWAY!

What would you recommend in such a way?

Please provide an override, aka "Allow unhomed moves" M-code, and provide a button/checkbox on DWC + PanelDue to allow unhomed moves!

okercho

@dc42:

Please can those of you running 1.21RC4 on a Duet WiFi try upgrading DuetWiFiServer to 1.21RC4. I need feedback on this version asap because a deadline is approaching.

I've updated the wifi server in my home printer from my office and it never came back, so I'm assuming the issue with my AP is still there. I can restart it (it's connected to a wifi plug) but I won't so I can check the error message in the PanelDue, but I assume is the usual "incorrect password" message.

Regards

deckingman

@resam:

What would you recommend in such a way?

Please provide an override, aka "Allow unhomed moves" M-code, and provide a button/checkbox on DWC + PanelDue to allow unhomed moves!

I haven't upgraded yet but I agree it's a bit of a pain. I can also see why some people might want to have that feature though. Ideally having the ability to enable or disable the "no moving until homed" feature, say in config.g would be good. Otherwise, I guess all we can do is create a macro to move Z using S2. Something like G91, G1 Z10 S2 Fnnn, G90 and call it say "Emergency Z move" or some such.

dc42

@deckingman:

@resam:

What would you recommend in such a way?

Please provide an override, aka "Allow unhomed moves" M-code, and provide a button/checkbox on DWC + PanelDue to allow unhomed moves!

I haven't upgraded yet but I agree it's a bit of a pain. I can also see why some people might want to have that feature though. Ideally having the ability to enable or disable the "no moving until homed" feature, say in config.g would be good. Otherwise, I guess all we can do is create a macro to move Z using S2. Something like G91, G1 Z10 S2 Fnnn, G90 and call it say "Emergency Z move" or some such.

That's what I would do, have a macro to raise Z by 5mm or so. The latest PanelDue firmware allows you to show 4 macros on the main screen, so running one of them is quicker than pressing Move and then a movement button.

I have been considering making M564 S0 allow movements before the printer is homed.

kraegar

Yep, I made a quick macro to raise Z by 5mm and also reset my bltouch. I need to get the paneldue upgraded so it's quicky available at the printer, but it's been the best solution for cases where I power on and the bltouch is too close to the bed to reset.

garyd9

@dc42:

3. Please explain why you consider it such a problem that you can no longer use the Move buttons in DWC/PanelDue before the corresponding axes have been homed. This has always been the case for Delta and SCARA printers, is the default for some other firmwares already, and is the only sensible default for a CNC machine.

I'll get the easy part out of the way first: "This has always been the case for Delta and SCARA printers," I don't know anything about SCARA printers, but am I correct that the "home" position for a delta is all three carriages at the TOP of the towers? In other words, "home" would move the print head as far as possible from the build plate? In contrast, "home" on most cartesian printers is at Z-min: The print head is up against the build plate.

Why does this matter in regards to this change? Because if the only valid "movement" for an unhomed printer is to home it, then there's no conflict whatsoever for a delta printer regardless of if something is on the build plate, or if the build plate even exists. On the other hand, with a cartesian printer, "homing" the printer might even be impossible with something on the build plate.

On a delta, "home" reduces any conflict between the print nozzle and a printed object. "Home" as part of completing a print makes sense.

On most cartesians, "home" will almost always create conflict (to the point of being impossible) between the print nozzle and a printed object. "Home" as part of completing a print is usually impossible – so much so that many cartesian printers will max Z and turn off the X and Y motors just to try and reduce conflict between the newly printed object and the print nozzle. In doing so, they become unhomed.

"...is the default for some other firmwares already..."

I've only used Marlin (I think it was marlin) on an i3 clone, Sailfish on a flashforge creator pro (makerbot clone), and RRF. So far, up until today, I've never seen this restriction on a cartesian printer. In both non-RRF cases mentioned, the default configuration of the printer/software would leave the printer in an un-homed state at all times unless it was printing, yet still had jog controls that functioned. Usually, manually moving the print carriage/head on an un-powered motor is discouraged as it creates voltage sent back to the circuitry.

As for why I consider it a problem:

I partially addressed this above. Others have also addressed it and given many reasons. In addition to those, I'll give one more: Manually leveling a build plate on a cartesian printer requires moving the print nozzle around. Homing the machine first usually isn't a good idea (as the build plate isn't leveled yet, so the nozzle might crash.) Manually moving the nozzle/carriage (by hand) isn't a good idea (for the reasons mentioned above about the steppers sending voltage back.) The best option is to use jog type controls to move the nozzle around a little at a time and start slipping a piece of paper underneath and turning screws. Using a macro for this can be cumbersome, as often times I just want to move a couple of cm in one direction or another to try and make the best of an imperfect carriage rod.

In fact, a cartesian printer spends nearly all non-printing time in a non-homed state. To use your own words, this is how other firmwares do it. This is out of necessity. By making DWC and PanelDue jog controls useless in this state, you are effectively reducing the value of the entire Duet system for non-Delta users. If the printer is only homed when printing, and the jog controls only worked when homed, what purpose do those controls have at all?

Please... PLEASE keep in mind that MANY duet and paneldue users don't have delta printers. This change doesn't add any value for them whatsoever. Taking functionality away from cartesian users just because delta users never had it makes no sense. That reasoning would result in enforcing a max print speed of 60mm/sec on delta printers because most cartesians can't print (cleanly) at higher speeds.

garyd9

Just a point to add to my previous post:

The change wouldn't be as bad if the parameter to G1 that allowed unhomed moves didn't directly conflict with delta printers. While it would be simple to add the S2 parameter to the DWC and PanelDue jog controls, doing so would break those controls for use with Delta printers (because of how S2 changes the meaning of G1 commands on delta printers.) So, as mentioned earlier, adding an "S4" to allow unhomed moves (assuming S4 is ignored on Deltas) would be a viable (if undesirable) work-around.

Adding the "M564 S0" you mentioned above would also allow DWC/PanelDue to override the restriction - it'd just be one more command that would be sent before the G1 (similar to how G91 is sent before the G1 now.) This actually makes more sense than adding another S parameter to G1. However, it's extending the meaning of an existing command which can be a slippery slope. (Example: G10)

In either case, however, I still believe that the "no normal unhomed moves" restriction doesn't make sense on cartesian printers to begin with. I've yet to see a good reason for that change.

deckingman

@dc42:

…...................................
I have been considering making M564 S0 allow movements before the printer is homed.

How would that work David? Currently M564 S0 will allow movement outside axis limits will it not? The default being S1 which constrains movement within axis limits. It would be great on a CoreXY (or Cartesian) to be able to allow movement before an axis has been homed (for reasons which others have so eloquently stated) but not at the expense of losing the constraint on axis limits after it has been homed.

resam

I fully agree with garyd9. Count me as a second vote to everything just outlined in this post.

dc42

@garyd9, thanks for explaining your position.

First, I will not be generating S2 or anything similar as standard by default in PanelDue when the movement buttons are used, because doing so would be dangerous for CNC machines. We are getting an increasing number of people using Duets to control CNCs and I must ensure that safety is the default. That's one of the main drivers for making this change. The other is that we have had a few complaints from users who have damaged their machines because movement was allowed when the printer was not homed, in one case accompanies by "my old firmware didn't let me do that". Therefore, whatever else we do, the default will be not to allow movement of an axis before it is homed.

The point that you can't home a typical Cartesian printer with a print on the plate is a good one, and suggests that a simple means to raise the nozzle/lower the bed is useful. This could be a macro or a dedicated button.

The point about moving the head to level the bed manually appears somewhat spurious to me, even ignoring the fact that RRF provides a manual bed levelling assistant, which can be used without a Z probe. For rare operations such as that, I don't see it as unreasonable to expect the user to have to do something to override the usual safety restrictions. Once you home X and Y, you can move the head in the XY plane. You may then want to jog Z to measure the height above the bed. For that, I can see that an option to allow you to jog an un-homed Z axis could be useful - although personally I would just home Z first, or use G92 to pretend it is homed.

Btw I do have a Cartesian printer, and I have been using it with this additional safety feature in the firmware for more than a week.

Coming back to M564, currently we have:

S0 - allow movement outside limits
S1 (in practice, Sn for n >= 1) - don't allow movement outside limits

I could add another parameter:

H0 - allow movement before the axis has been homed (not for Delta or Scara printers)
H1 - don't allow movement before the printer has been homed (default)

Would you be satisfied with that? After M564 H0 should movement to absolute positions be allowed, or only relative movement?

garyd9

@dc42:

First, I will not be generating S2 or anything similar as standard by default in PanelDue when the movement buttons are used, because doing so would be dangerous for CNC machines.

Understandable (but please see comments IRT paneldue later in this post.)

@dc42:

We are getting an increasing number of people using Duets to control CNCs and I must ensure that safety is the default. That's one of the main drivers for making this change.

SAFETY is a good reason.

@dc42:

Would you be satisfied with that? After M564 H0 should movement to absolute positions be allowed, or only relative movement?

Yes, that would be reasonable. It should only allow relative movements (as absolute movements make no sense when you aren't homed. How can you move to 0,0,0 absolute when you don't know where 0,0,0 is?)

~~Back to PanelDue:~~

Would you accept a pull request for PanelDueFirmware that added an option in settings, defaulting to OFF, that enabled sending "M564 H0" before any jog command? By default, unhomed jogs wouldn't work, but by enabling this setting, they would (at least on printers where M564 H0 allowed unhomed moves.)

(The code change involves adding a uint32 to FlashData, an extern function to PanelDue to access the bitflags, and the obvious change in UserInterface.cpp to set H0 before the G1 and H1 after the move.)

~~I'd also suggest the same/similar toggle be added for DWC, but I'm much more fluent with C++ … and useless with javascript.~~

Edit: No need for messing with paneldue/DWC as mentioned later in this thread.

whosrdaddy

+1 for M564 H0
@Garyd9, adding M564 H0 to config.g would be enough, no need to add an option to PanelDue/DWC.

deckingman

@dc42:

…..........................................
Coming back to M564, currently we have:

S0 - allow movement outside limits
S1 (in practice, Sn for n >= 1) - don't allow movement outside limits

I could add another parameter:

H0 - allow movement before the axis has been homed (not for Delta or Scara printers)
H1 - don't allow movement before the printer has been homed (default)

....................................

Personally, I'd be happy with that. If it just means putting M564 H1 into my config.g file which will easier than having to edit my homing files and also save me the hassle of creating a macro and more importantly, remember that I have to use it.
I appreciate the safety concern but over the years, I've become accustomed to doing things a certain way. As well as the scenarios that others have put forward, I often just want to drop the bed 100mm or so to get it out of the way when I want to change hot ends, remove the glass for cleaning, apply a coat of 3d lac without getting it on the hot end or otherwise work on the printer. So having to home it first when I don't even want to print anything would be a bit of a PITA.

garyd9

@whosrdaddy:

+1 for M564 H0
@Garyd9, adding M564 H0 to config.g would be enough, no need to add an option to PanelDue/DWC.

For some reason, I completely overlooked that M564 H0 could be left permanently enabled (via config.g.)

resam

Yes, M564 H0 would be acceptable. I probably also put it in my config.g.
Thanks!

If you really want to make me happy, please add a button in the PanelDue jog window - so this override is accessible when needed.

Catalin_RO

Regarding homing for CNC machines, I think that the truth is somewhere in the middle. For rather simple machines, with no slave axis and no extra features (like touch probes for the tool length or tool changers), homing is not needed at all. One just jogs the spindle to the desired position, based on the already positioned raw material, zeros the coordinates and starts the job. With GRBL the homing can be disabled completely and a freshly started machine, although it reports it needs homing, can be software reset and unlocked and homing is no longer needed no matter what.

Realistically now, with CNC homing is really necessary for machines with slave axis that can get out of sync (independent motors as the solution with mechanical link between the master and slave axis is much simpler for the controller) and when there are various tools installed at well defined machine coordinates.

Looking differently at it, for 3D printing it might be more important than for simple CNC machines. With 3D printing you have to print an item of a certain size and you need to know that the object won't get beyond the printable area if the origin of the print is not correctly set. With CNC you already have a big lump of raw material, at least as large as the final item, and if you know the area that the machine can "process", it is practically impossible to go beyond that (misplacing the raw material or going for a smaller piece is not considered here!).

As for the dangers of homing, the CNC world has its own! It is not unheard of using a tool longer than what is safe in the machine setup, based on the fact that one can manually jog through the obstacles to the location where the machining has to be done. Homing in such situations, although the Z-axis is almost always the first one, doesn't guarantee that the tool doesn't touch an obstacle. Allowing manual jogging without homing first would be very useful in these situations as well! (been there myself, luckily with rather inexpensive tools in the spindle!)

In conclusion, there should be a rather easy solution for jogging without homing, especially because the emergency situations are really critical! By default it should not be allowed, but a manual override solution would be great. User defined macros are acceptable from my point of view….

garyd9

@Catalin_RO:

In conclusion, there should be a rather easy solution for jogging without homing, especially because the emergency situations are really critical! By default it should not be allowed, but a manual override solution would be great. User defined macros are acceptable from my point of view….

Most (all?) of the points for movement when not homed are in non-printing situations. They occur either before a print is started (with the understanding that homing must occur before a print can start) or after a print is finished or aborted. Remember also that this is all in relation to manual movements such as jog controls, and not to any type of automated or unattended movement. The act of pressing one of the jog control buttons is always a "manual override."

garyd9

RC3 issue: Unable to simulate printing due to printer not being homed. (The irony here is that one of the first commands the gcode file is G28)

From my gcode console log:

[[language]]
6:35:45 PM    M37 P"ABS - L/Car_Ears2.gcode"
                      Simulating print of file ABS - L/Car_Ears2.gcode
                      Error: G0/G1: insufficient axes homed

Here are the first instructions in my gcode file (skipping comments) up to the G28:

[[language]]
G90
M83
M106 S0
; S3D starting gcode for LEFT extruders
;
M140 S105  ; start heating the bed (no wait) while homing
G28                       ; homeall

Additional info: The above all occurred via DWC. When I went to the physical location of the printer, I found that PanelDue was reporting that the printer was in a "simulating" status (and ended up doing an "emergency stop" via the paneldue to get control.)

CRPerryJr

Unable to upgrade Duet 0.85 to 1.21RC3 from 1.19.2 using RepRapFirmware.bin. I tried utilizing DWC firmware update method first, and it appeared to transfer successfully and reboot, but it failed come back up. I tried erasing and utilizing the Bossac method. The new firmware transfers successfully via Bossac, but causes the Duet to reboot itself after 30 seconds or so repeatedly. (I can tell because the USB drops and reconnects about every 30 seconds.) Erased and Reflashed the firmware using Bossac back to 1.19.2 and the Duet is operating normally again.