Duet WiFi firmware new feature priorities
-
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.
-
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.
Yes please
Thanks,
Jeff
-
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.
Ok, so I can certainly live without that functionality. I'm still kind of thinking the option to just stop moving if the motor hits a limit switch wouldn't be all that bad. Perhaps allowing a new command to fire off via triggerxx.g when the endstop is hit to say kill the current to the stepper motors. I already tried doing this however it doesn't actually reduce the current until After the move is completed. So a M112 like command to actually stop the move would be nice.
Thanks,
Jeff
-
@(In)Sanity:
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.
Yes please
Thanks,
Jeff
Sorry but no thank you.
-
Given my understanding of the upcoming firmware revision for multi-motor Z axis machines, the power up cycle would initiate Z homing for all motors in order to sync the Z motors to a common starting step position. I assume Z home would be at the top stop location. I'm new to this so please indulge my ignorance. Thanks…
-
Given my understanding of the upcoming firmware revision for multi-motor Z axis machines, the power up cycle would initiate Z homing for all motors in order to sync the Z motors to a common starting step position. I assume Z home would be at the top stop location. I'm new to this so please indulge my ignorance. Thanks…
Auto homing on power up wouldn't be a good idea IMO - thinking trapped fingers and so forth. Also when you start commissioning and want to check that motors are running on the right direction etc. Or if something goes horribly wrong with a print and you have to abort and turn off the machine to fix it. Then you find you have a horrible mess of what was molten plastic around the hot end but it's solidified. You want to heat the hot end to clean up the mess but can't because as soon as you turn the printer on it's going to auto home and crash into the bed.
Axis homing can be either min or max as long as the printer knows where to move to at the start of a print, you can configure it either way. It is normal to home Z such that the bed is closest to the nozzle though.
-
Most Duet users with Cartesian or CoreXY printers use the Z probe to home. So you would first home X and Y, then move the head to bed centre and home Z driving all 4 motors. Then use the Z probe in the corners to make fine adjustments. Whether it's best to adjust each motor individually (4-point levelling) or treat 2 of them as a single motor and do 3-point levelling depends on the size and rigidity of the bed or gantry (whichever one moves in your design).
-
Q. Better web interface security, including logon IDs and passwords that are not sent over WiFi in clear text even when using an unsecured WiFi network, and passwords that cannot be retrieved from the printer via the web interface. IMO this is essential if you want to expose your printer to the internet by opening a port on your router, or you want to use the Duet WiFi on an unsecured wireless network.
Not a beta tester and haven't received my board yet, so I'm just going off what you've described in this point.
Security is critical and often overlooked - Even when "secured" behind a private network, sending passwords in the clear is not acceptable. Security is also important for scenarios where printers are used in large networks, such as workplaces and places of education.
In my opinion there is only really one solution to this: Use SSL on all pages within the web interface.
I'd also suggest considering allowing OpenID Connect for external authentication providers, such as Google. (https://developers.google.com/identity/protocols/OpenIDConnect)
This has the following benefits:
- Allows the offloading of securely storing credentials and allows for much greater hash complexity
- Allows you to take advantage of any additional protections provided by the authentication provider, such as multi-factor authentication
- Allows identity IDs to be consistent across multiple printers, for example if you have a farm of them
- Allows for single sign-on, which is great for workplaces and the like (This could also be used for federation with an active directory system, for example)
- Ensures that the credentials that are passed around are just time-limited signed tokens, unlike passwords which may not expire
Please note that switching to OpenID Connect does not remove the requirement for SSL - An access token must be seen as a time-limited credential.
As an aside, credentials (Passwords, secret keys and tokens) should never be passed around as GET parameters, they should either be posted or sent via an "Authorization" HTTP header: https://github.com/chrishamm/DuetWebControl/blob/master/core/js/comm.js#L100
… and unless I'm missing something, the password between the Javascript font-end and the back-end web service does nothing anyway, as the other Ajax calls don't seem to be authenticated: https://github.com/chrishamm/DuetWebControl/blob/master/core/js/comm.js#L236
-
Hi,
To me, the most important fundamental quality of any 3D printer is how it prints. I don't care much about "convenience" features. They are nice to have, but of little value until my printer always knows exactly where the nozzle is in relationship to the bed so that I have the most accurate layers possible, and (not sure what this would be included under) so that if I change nozzles and the nozzles are of different lengths, it still "just works" (I assume height compensation is different than bed leveling – I am not sure if it can already be done).
Given that, of the available choices, these are easily the priorities:
H. Grid-base bed leveling
R. Support to compensate for axis hysteresis in the motion control.If auto height compensation cannot be done, that would be in between H and R.
Thanks,
James -
On the topic of "anything else":
S) The software figuring out the printer geometry automatically.
For a Delta, there are so many factors here, and they can be hard to measure accurately. Arm length and inter-arm variation. Taper (my arms have a 50mm separation at the frame and a 40mm separation at the effector – I read that's not OK, but that's the way a lot of deltas are designed, so what do I do?). Radius (it's not easy to measure that to fractions of a millimeter -- at least with the arms that's more easily done with a caliper). Is the frame perfectly square? I don't even know how to address that, and I don't think the software does.
The bottom line is that there are many, many concerns if you want to achieve all the precision that a given system can potentially provide.
I realize that some of these things might appear as bed variations (even though they are really not, that doesn't matter as long as they are compensated for), and so perhaps grid-based bed mapping already addresses them. But, to the extent that grid-based bed mapping cannot account for some things, I think automatic calibration of as many parameters as possible would be beneficial to everyone in terms of ease of setup and print quality.
Thanks,
James
