Duet WiFi firmware new feature priorities
-
Yes I will be supporting 2, 3 and 4 independent Z motors.
-
Yes I will be supporting 2, 3 and 4 independent Z motors.
Hi David…We talked on the RepRap forum about using 2 Z motors and multiple belts to sync the 4 corners of the XY carriage on my fixed bed (non-adjustable) Core XY build. You confirmed that Duet will soon have ability to independently control and sync multiple Z motors. Since I have 4 lead screws supporting the XY carriage in Z motion, will it be feasible to do away with the belts and run separate motors on each screw to level the XY carriage to the frame mounted bed? I'm at a stage where I can add two additional Z motors to the build for little cost. If you see this as a practical scenario I'd like to make that change now and be ready when the firmware upgrades are in place. Thanks...TP.
-
Yes you can do that. You will need a DueX5 expansion board so as to have enough drivers. Until the new firmware is ready, be prepared for the motors to get slightly out of sync when you power cycle the printer.
-
So then I assume a thumb knob at the top of each shaft would allow one to manually adjust the four corner back to level after power up. Will we eventually be able to probe the four corners through a program routine to level the XY carriage to a fixed bed?
-
Yes, that's correct. You might want to temporarily reduce the Z motor currents using M913 while doing the adjustment.
-
Not a very useful feature for most people, however I would love to see support for the Z-endstop being a safety for the Z-Probe homing. I've crashed the nozzle into the bed sooo many times while messing around with Z-Probes of different natures all while that mechanical Z endstop switch is triggered but doing nothing. I know, not many people would care. I guess I could wire that in to kill the machine if it's triggered somehow. So I guess my request would be for support for mechanical Z endstop while using a Z-probe for homing.
Jeff
-
@(In)Sanity:
Not a very useful feature for most people, however I would love to see support for the Z-endstop being a safety for the Z-Probe homing. I've crashed the nozzle into the bed sooo many times while messing around with Z-Probes of different natures all while that mechanical Z endstop switch is triggered but doing nothing. I know, not many people would care. I guess I could wire that in to kill the machine if it's triggered somehow. So I guess my request would be for support for mechanical Z endstop while using a Z-probe for homing.
Jeff
You can do that already (I have). Just wire the mechanical switch to a spare end stop (say E1) then use M581 - something like this M581 E1 S1 T0 C0.
-
I'm going to expand on my request to say, if any endstop is triggered stop trying to move in that direction. It's crazy you can get the printer in a state where it hits the endstops but just keeps on grinding away. It seams like some kind of Sanity check would be useful.
Thanks,
Jeff
-
@(In)Sanity:
Not a very useful feature for most people, however I would love to see support for the Z-endstop being a safety for the Z-Probe homing. I've crashed the nozzle into the bed sooo many times while messing around with Z-Probes of different natures all while that mechanical Z endstop switch is triggered but doing nothing. I know, not many people would care. I guess I could wire that in to kill the machine if it's triggered somehow. So I guess my request would be for support for mechanical Z endstop while using a Z-probe for homing.
Jeff
You can do that already (I have). Just wire the mechanical switch to a spare end stop (say E1) then use M581 - something like this M581 E1 S1 T0 C0.
Ok, I just moved my Z-Endstop over to E1 and did as you suggested just changing S1 to S0 due to makerbot style endstops. Works like a charm, if I dig the nozzle in even a little bit past normal calibration it just shuts down….love it!! So now I guess I need double trigger endstops to do this on the X and Y also. Easier in software.
Thanks,
Jeff
-
There's nothing to stop you having the shutdown trigger if the X and Y endstops are activated too. Just change the command to:
M581 X1 Y1 E1 S1 T0 C0
but you will have to disable this during homing, obviously!
-
There's nothing to stop you having the shutdown trigger if the X and Y endstops are activated too. Just change the command to:
M581 X1 Y1 E1 S1 T0 C0
but you will have to disable this during homing, obviously!
That is a fantastic idea. Thank you!
Jeff
-
Something else I did was to install switches on all the axes maxima, wired together in series and connected to yet another spare E stop. Then if I do something stupid like send an axis beyond it's maximum position before I've homed it, then it'll trigger an emergency stop before the frame gets mangled. I also have a physical emergency stop button wired the same way to yet another spare. It isn't a true emergency stop in that it doesn't cut all power - if I want to do that, I just press the button on the RCD I use to kill everything.
-
Something else I did was to install switches on all the axes maxima, wired together in series and connected to yet another spare E stop. Then if I do something stupid like send an axis beyond it's maximum position before I've homed it, then it'll trigger an emergency stop before the frame gets mangled. I also have a physical emergency stop button wired the same way to yet another spare. It isn't a true emergency stop in that it doesn't cut all power - if I want to do that, I just press the button on the RCD I use to kill everything.
That's a good idea. It would be kind of neat if the firmware had the option to Not travel in a direction opposite of the end stops if you've not already homed. That way it would prevent some stupidity on the users end (myself). I've implemented the X Y and Z endstops triggering trigger2.g which I then just put an M112 in the file. Why did I go with the file…IDK...seamed like a good idea. It shuts off during homing moves except for homing the Z axis which is for really bad situations.
Thinking about it the option to prevent Non Homing moves if not homed would be good. Pretty much if your not seeking a home during a move and your not already homed prevent the move. Just a thought.
Jeff
-
@(In)Sanity:
It would be kind of neat if the firmware had the option to Not travel in a direction opposite of the end stops if you've not already homed.
This is incredibly common in industrial motion controllers. I also think this is a fabulous idea.
-
@(In)Sanity:
It would be kind of neat if the firmware had the option to Not travel in a direction opposite of the end stops if you've not already homed.
This is incredibly common in industrial motion controllers. I also think this is a fabulous idea.
I can think of a couple of scenarios where that might not be such a good idea. For a example, if you finish a print and turn the machine off, then when you next turn on the machine, you need to move the Z axis out of the way in order to remove the print that's still stuck to the bed. If it's screw driven, it could be a pain to move it by hand and if your only option is to move Z towards home you'd be a bit stuck. It'd also be a pain during commissioning, when you are trying to sort out motor wiring and rotation directions.
-
@(In)Sanity:
It would be kind of neat if the firmware had the option to Not travel in a direction opposite of the end stops if you've not already homed.
This is incredibly common in industrial motion controllers. I also think this is a fabulous idea.
I can think of a couple of scenarios where that might not be such a good idea. For a example, if you finish a print and turn the machine off, then when you next turn on the machine, you need to move the Z axis out of the way in order to remove the print that's still stuck to the bed. If it's screw driven, it could be a pain to move it by hand and if your only option is to move Z towards home you'd be a bit stuck. It'd also be a pain during commissioning, when you are trying to sort out motor wiring and rotation directions.
It could be a flag that's normally checked so you just uncheck it to confirm that you know what you are doing if it's needed. Or it could pop a confirm box when you try to move a axis away from home so you had to click OK to allow the movement. I have done this mistake with my printer a couple of times and even if I know it will happen I do forget it sometimes.. A notification saying "don't do anything stupid" would help
-
Personally I just have g-code at the end of my prints that clears the bed so I don't have to worry about dealing with moving anything around. I've never had to go back in and move anything to get a print off the bed.
Edit: A check box on the web interface or panel that says "Override Safeties" might do the trick for failed print removal.
Also I think restrictive safeties should be a flag so we can turn them off if we feel like it. I've had to re-tension belts too many times now because of my own stupidity, so personally I would love to see the machine try to protect itself 99% of the time. I have to say the old Mightboard I was running before did a better job at not grinding motors and belts. Yep that was a bit of a dig..sorry.
Jeff
-
I can think of other little items that would make sense, such as the printer is just turned on, both the X and Y end stop switches are currently triggered, why would the printer not have a clue where X and Y currently are ? Another one is…hey you told me to move and I hit an end stop so I'm going to stop now because I know where I am. This is certainly not a new concept. That's not to say a homing process wouldn't still be best for more accuracy, the printer however should have a clue. Sailfish won't for example try to move Past it's end stops no matter how much you tell it to do so. Now if you have the end stops reconfigured that's on you, not the software.
So items I would love to see:
- Don't move in a direction opposite of the end stops if that axis has an unknown position.
- If an end stop is hit stop what your doing and record where you are.
Thanks,
Jeff
-
@(In)Sanity:
I can think of other little items that would make sense, such as the printer is just turned on, both the X and Y end stop switches are currently triggered, why would the printer not have a clue where X and Y currently are ?
An industrial motion system is different than our machines but I'd never program a system to automatically detect the switches on startup. Here's a few reasons why.
1. Accuracy of position (as already mentioned)
2. Homing is a very specific code path. By bypassing this, code that is harder to debug and maintain must be created.
3. Defective limit switches would be problematic.
4. At best it gains a few seconds of time on occasion.I see little harm in having the system require home before movement in all cases where that option is enabled. Obviously, it needs to be an option that can be disabled for maintenance/oddball mechanical configuration reasons.
-
RRF already doesn't allow movement before homing on delta printers, except for homing moves (G1 S1) and individual motor moves (G1 S2). I could extend this to Cartesian and CoreXY printers, if most users would prefer that.
