Duet WiFi firmware new feature priorities
-
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 -
Hi,
…......................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)........................
James
I guess the only way that could be achieved is if the nozzle itself is the probe and is used to actuate a sensor. With any other sort of Z probe or switch, there is no way that the firmware could determine the relationship between the position of the sensor and the tip of the nozzle (other than "telling it").
-
@yngndrw, thanks for your suggestions. I am well aware that security needs to be improved, especially when the printer is used on a corporate network. The WiFi firmware is due for a complete rewrite, which will probably happen with main firmware release 1.19. I will look into supporting SSL at the same time. What I don't yet know is what impact on file upload speeds there will be from using SSL. If we make SSL optional then we will implement HTML digest authentication or better for passwords when SSL is disabled, and recommend that this configuration is used on private networks only.
RRF does check that incoming requests are from IP addresses that have logged on with the correct password, but I wouldn't like to guarantee that this is is done in a way that is resistant to hacking.
@James, grid-based bed levelling is supported from version 1.17. I think you are the first person to ask for axis hysteresis compensation. On my delta the hysteresis is less than 1 microstep (i.e. less than 6.125um), but I am aware that Cartesian printers can have much larger hysteresis values.
Regarding delta printer geometry, in addition to the 9 variables that RRF attempts to calibrate already if you let it, there are at least another 17 variables involved if you want to correct for all geometrical errors that can occur - and that assumes that the joints have no play, behave as perfect spherical joints, and that any springs between the arms have negligible effect (and I already have evidence that they do have an effect). I had wondered whether it might be possible to upload the probe heights to a program running on a PC to analyse them and determine the geometrical errors, but with so many variables I suspect it is impossible. So instead we're looking at how to bring the number of variables down by making precise construction easy. To this end the team that brought you the Duet WiFi is working on a PCB effector and matching PCB carriage adaptors. Together with the rods with magball joints manufactured by Haydn Huntley, these should eliminate 9 of the variables from the system.
-
@dc42: I'm always happy to review software security. I fully appreciate the concern for performance with SSL on this hardware - While SSL doesn't have a measurable impact on full servers, I've done some digging and it looks like you only have the resources to have a single concurrent TLS session on the ESP8266: https://github.com/esp8266/Arduino/issues/2733#issuecomment-264710234
Having the limitation of a single concurrent SSL connection might not be an issue as it could always be put behind a reverse HTTP proxy which would allow re-use of that connection, if required. (For example, if you had a public read-only status page or something like that - Maybe a workplace scenario)
It could be an option to use SSL for the main API and generate very short-lived single-use tokens for upload usage if there's a serious impact on upload performance, but I'd have no idea if that would resolve the issue or if there would even be an upload issue on this hardware without trying it. In this scheme you would generate a new token for each chunk of uploaded data and reject the whole upload if a token was re-used during the process, which would guard against a stolen token. You'd also have to verify the uploaded data with a checksum.
While tying sessions to IPs is better than nothing and almost free from a resources point of view, it is not ideal for security purposes. Remote IPs are not guaranteed to be unique (Multiple users could be behind a single IP thanks to NAT, for example from a public Wifi access point) and can be spoofed in some cases. A more secure solution might be to provide a token of sorts with each request - This could be a session cookie (Set as HTTP Only and, if SSL is enabled, Secure) or the HTTP digest mechanism that you mention could be a nice solution to prevent re-use of a compromised session token.
If might be worth mentioning that browsers will start making non-HTTPS sites as insecure in the not-so distant future, so a hardware recommendation would be to include a processor with resources geared to cryptography in a future version.
I'd be happy to review the new firmware for you when it's available.
closed Is there any support for HTTPS (SSL) in esp8266? #2733
-
Hi,
…......................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)........................
James
I guess the only way that could be achieved is if the nozzle itself is the probe and is used to actuate a sensor. With any other sort of Z probe or switch, there is no way that the firmware could determine the relationship between the position of the sensor and the tip of the nozzle (other than "telling it").
Maybe I am misunderstanding something, but doesn't all bed leveling assume a sensor that could do this? It seems that if I know when I hit the bed, I know how long my nozzle is.
Thanks,
James -
@dc42: Another 17 variables! Wow. I guess a lot of research has been done into this, so I'll shut up and let the experts work on it lol.
With respect to hysteresis, I only listed it because I assumed, being on your list, that the effects were significant. I have no data of my own to indicate that it is a problem. Overall, I don't care if it's hysteresis, geometry, thermal expansion, etc., my thought is just that making a printer as accurate as reasonably possible is more important than, e.g., faster file uploads or most "convenience" items. Maybe we are already there, or almost there, and bumping into the fundamental limitations of the hardware.
-
Hi,
…......................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)........................
James
I guess the only way that could be achieved is if the nozzle itself is the probe and is used to actuate a sensor. With any other sort of Z probe or switch, there is no way that the firmware could determine the relationship between the position of the sensor and the tip of the nozzle (other than "telling it").
Maybe I am misunderstanding something, but doesn't all bed leveling assume a sensor that could do this? It seems that if I know when I hit the bed, I know how long my nozzle is.
Thanks,
JamesErr no (or yes). If you are talking about bed level compensation, then of course it won't be affected by the length of your nozzle. Bed level compensation will make adjustments to compensate if the bed is tilted in X or Y or, in the case of grid based compensation, it will make adjustments to compensate for if the bed is saddle shaped or otherwise deformed. The length of the nozzle is irrelevant.
However, if your are talking about bed height adjustment (i.e. Z homing), then the machine has to "know" where Z=0 is - i.e the point where the nozzle is just touching (or slightly above) the bed. I guess we could just smash the nozzle into the bed and take the point where the motor stalls as being Z=0, but it's likely to cause some damage and not be very repeatable so we adopt a more elegant approach. The way that is achieved is by using a sensor that triggers at some given distance above the bed (before the nozzle actually crashes into it and does some damage). So say for example that trigger point is 2mm above the point where the nozzle is just touching the bed (Z=0). This is what we put into our G31 command. When we "home" the Z axis, the machine will raise the bed (or lower the carriage) until the sensor triggers. It then "knows" that Z=0 is 2mm below this trigger point (because we have told it that is the case). So if we then immediately send G1 Z0 command, it will move the bed to the point where the nozzle just touches the bed -i.e a further 2mm. Therefore, if you were to fit a nozzle that was say 1mm longer, you would need to tell the machine that the trigger height for the sensor is now 1mm above the tip of the nozzle instead of the 2mm that you were previously using.
Which is why I said, that the only way the machine could "know" that you have fitted a longer nozzle, is if the nozzle itself was the probe, and somehow or other connected to a sensor, be that a piezo, fsr, or whatever and even then, the relationship between the part of the nozzle that actuates the sensor would need to be constant, regardless of the length of the nozzle itself.
-
Ian, that is a really good explanation of how probing works. Thanks!
-
Yes, thank you. My plan, because I intend to use piezo force sensors under the bed, rather than a proximity sensor on the nozzle, actually is to "smash the nozzle into the bed." Hopefully that's not a problem – I think other people in this forum are using the piezo technique in some form?
-
Yes, thank you. My plan, because I intend to use piezo force sensors under the bed, rather than a proximity sensor on the nozzle, actually is to "smash the nozzle into the bed." Hopefully that's not a problem – I think other people in this forum are using the piezo technique in some form?
Yes, so in your case, the nozzle is the probe (effectively) so altering it's length should not affect anything. Of course, try to "smash it" gently into the bed :). You'll likely find that that there will still be a slight trigger distance - maybe 0.1 mm or so because the Piezos will need to flex a bit, but as the sensors will be under the bed it will be independent of nozzle length and should remain constant. If the Piezos under the bed do not work out for you, then fitting the Piezo above the hot end should also allow you to change nozzles without having to reset the trigger height.
-
Ian, that is a really good explanation of how probing works. Thanks!
Flattery? Stop it Tony, you'll make me blush:)
-
Sounds good. I was worried that bed mapping or z stop detection wouldn't work for large changes. For example, I thought maybe a bed grid was generally used to map sub-millimeter differences, and that if you changed the nozzle length by 1cm, it might not figure out what was going on without manually changing settings.
-
Two points:
1. Force sensors in the bed supports can suffer from the trigger height varying slightly with position. Typically they are more sensitive when you probe close to one of the sensors.
2. If you are going to change your nozzle length by a large amount on a delta printer without resetting the homed height parameter in the M665 command, you had better specify a large dive height in the M558 command.
