New firmware 1.21RC3 available
-
Me again, tried 1.21rc3 and found CoreXZ isnt moving along its "planes" anymore its as though ive left it in cartesian mode.
only change was updating from v1.20 to 1.21rc3 and changed my z movements with S2 parameter.Gav
-
You won't see any indications in DWC because it is a temporary suspension of heating. However, all the heater LEDs on the Duet will go off; and any heater LEDs on the hot end (e.g. Smart Effector) or bed heater will go off too.
-
Me again, tried 1.21rc3 and found CoreXZ isnt moving along its "planes" anymore its as though ive left it in cartesian mode.
only change was updating from v1.20 to 1.21rc3 and changed my z movements with S2 parameter.Gav
OK, I see the problem. S2 invokes direct motor movement; but on a CoreXZ printer, you need to move both the X and Z motors to move Z. Here are two possible workarounds:
1. As you don't have a Z endstop switch, make sure you say so in config.g (Z0 in the M574 command), then you can use S1 instead of S2 in that G1 Z command;
2. Instead of G1 S2 Znn use G1 S2 Xnn Znn to get the correct Z movement (one of them may need to be negative, I can't remember).
I have been considering introducing a new mode S4 for G1 commands. This would mean:
1. Movement is allowed regardless of whether axes have been homed (like S1, S2 and S3);
2. Axis mapping is not performed (like S1, S2 and S3);
3. Coordinates are always interpreted in Cartesian space;
4. On Delta and SCARA printers, X and Y movements using S4 are not allowed;
5. Coordinates are always interpreted as relative (not sure about this one, because absolute S4 movements might possibly be useful on CoreXYU and CoreXYUV machines). -
1. As you don't have a Z endstop switch, make sure you say so in config.g (Z0 in the M574 command), then you can use S1 instead of S2 in that G1 Z command;
so this has kind of worked, but having a bltouch probe thats defined as M574 Z2 right? whats the correct way to define a z probe but no endstop?
-
As long as you are using G30 to do Z homing in homez.g and homeall.g (not G1 S1 Znnn moves), M574 Z0 will work just fine. That says you have a Z probe and no endstop.
-
ended up using method 2, working as expected now
apart from the z not homed before z as in other thread, im almost there 
thanks again
-
I don't know if this was fixed in RC3 or not, but I just noticed the following issue in RC2:
…
In each of the above probes, the heater is turned off for the FIRST test in each location, but the heater is turned back on (and stays on) for the SECOND probe. (My probes are apparently within 0.03 of each other, as I don't see a third probe in any location.)I believe that was fixed in RC3 along with the other multi-touch issues, but please check.
I need to compile a new PanelDue firmware that sends S2 along with G1 movement commands before I can use RC3. (…and I haven't even begun the process of setting up a build environment for paneldue.) Hopefully, someone else will be able to verify on RC3 sooner.
-
Maybe there should be some kind of gcode command to enable safe movement protection
I'd think it could have a few parameters
S0 - disabled, no movement locks
S1 - enabled, no movement until homed
S2 - All moves have S1 enabled until homed
S3 - Z axis prevented from moving down until homedor something
-
I don't know if this was fixed in RC3 or not…
When setting up a z-probe with P5 (It's a BLtouch) A3 (probe each location up to 3 times) and B1 (turn off bed heater while probing), the heater gets turned off for the FIRST of multi-tap probes, but not subsequent multi-tap probes.
I believe that was fixed in RC3 along with the other multi-touch issues, but please check.
I can confirm that this IS fixed in RC3 for G30 probes (multi-tap or otherwise.) However, if the probe is used as an endstop (G1 S1), the heater is not turned off. (I'm still using my BLTouch as a "P5" instead of a "P9" if that matters.)
Given the following two gcode lines, the FIRST one does not turn off the heater. The second one DOES turn the heater off.
[[language]] G1 S1 Z-155 F6000 ; heater isn't turned off G30 ; heater IS turned off -
In regards to the new S2 requirement for unhomed G1 moves on non-Delta printers:
I was making code changes in PanelDue to force the S2 parameter to always be sent when I decided to read the duet gcode wiki and see what side effects it might have. There I found out that "G1 S2" has a completely different meaning on delta printers when compared to non-delta printers. Here's my understanding (and if I'm wrong, please correct me):
A normal "G1" on a cartesian printer moves the axis specified. So "G1 X" moves the X stepper motor, etc. Passing a "S" parameter (S1, S2, etc) doesn't change that.
On a delta, however, a normal "G1" actually often ends up moving THREE different stepper motors in order to make a straight horizontal or vertical move. So, it's actually more of a "virtual" move in that the duet board has to figure out which steppers have to move (and in which direction) to move the print head a given distance on a single line. (Making it really confusing, each stepper motor is labeled X, Y, or Z - but those labels have nothing to do with straight lines in the printed space.)
On those deltas, however, passing a "S" parameter completely changes the meaning of the G1 command. If S1, S2, or S3 is passed to G1 on a delta, the G1 command doesn't mean to move the print head a given distance on a given line, but instead means to move a specific stepper motor (remember that each motor has a X/Y/Z label?) a given distance. So, while "G1 X10" on a delta might move the print head 10mm to the right, "G1 S2 X10" will actually cause the print head to move in 3 dimensions (slightly down and either left or right depending on which stepper motor is labeled "X".)
Why does all this matter?
Because now I'm more opposed to this change as it's currently implemented in RC3. It means that the same VALID command on two different printers will have completely different end results. I realize that this situation already exists with "G1 S1", but at least in that case they both mean "detect endstop" and hopefully they're only used for that. In the case of "G1 S2", which is now valid for both printer types, one printer will "move in cartesian space" and the other will "move in… delta space?" (not sure what the proper term would be.)
If there's really some good reason to not allow un-homed moves (and please share it with those of us testing the changes), then at least add a new non-delta S parameter for moving when not homed on cartesian (and corexy) printers where X is always X, Y is always Y, and Z is always Z. Perhaps "S4." On delta's, the parameter would be completely ignored and treated as if no S parameter was passed.
One other reason: It makes it easier for me to add a parameter to the paneldue's "jog" buttons without wondering what kind of problems I'd introduce on a delta machine.
-
1. Thanks for confirming the the heater is turned off correctly when doing bed probes in RC3.
2. G1 S1 Z moves should only be done if you are using an endstop switch for homing Z. To home using a Z probe, use G30.
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.
-
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.
-
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!
-
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
-
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.
-
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.
-
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.
-
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.
-
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.
-
…...................................
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.
