Duet WiFi firmware new feature priorities
-
For the BL Touch, you could use https://www.sparkfun.com/products/13118 for the servo signals, then all you need a pin to toggle it.
-
G. Support for three independently-controlled Z motors
S. BLTouch
F. Support for multiple independent X carriages
B. Multi-threaded web server
H. Grid-based bed compensation -
S. Using stallguard for missed step detecion and auto rehome.
Apparently the tmc2660 shall be able to detect unexpected high loads.
After a few hours of frustration I finally did a semi successful benchy3D the most visible faults are due to the head hitting hardened overhanging corners curling upwards and producing missed steps, or hitting an already printed structure. Unfortunately I generally detect the fault 1-2 layers later.
If it could eventually be detected immediatly the delta could be paused, rehomed and restarted with no layer shift.
For some reason it does seem to work most of the time when done manually.
And yes I could up the current. But I don't want to because it prevents to hard shocks in case of colisions, -
Does this include changes requested for webcontrol?
If so, Is it possible to have a config.g backup made automatically?
I just attempted to make an update to config.g via the web interface to change the offset of my probe after adding a PEI sheet to the build plate. Made the change, hit save and the firmware evidently reset without warning or saving the config.g, taking out config.g in the process. It's now a 0 byte file. Like a fool, I don't have a backup, you can bet I will be grabbing one before changes from now on…
Anyhow, my request would be to have the current config.g backed up every time an update is made, that would at least keep a quasi backup file on the SD card.
Or if someone wants to point me in the direction of the code, I will add it, if nothing else, for myself.
-
Personally, I always keep the config files in a folder on my PC and keep this backed up. When I want to make changes, I re-name the config as configold or some such and upload the new file, rather than edit it from within the web interface. I've had one too many corrupt SD cards in the past.
-
I've started a new forum heading for Duet Web Control feature requests. Please start a new thread there to request keeping a backup copy of config.g.
-
1.F/f
2.F/f
3.F/f
Thanks. -
1.F/f
2.F/f
3.F/f
Thanks.F is multiple independent X carriages. I think it's possible to implement this without any firmware changes. You would use the M584 and M574 commands in homex.g and homeall.g to switch between motors and endstop switch locations, and M584 to switch X motors in the tool change files. You would need to connect the two normally closed X endstop switches in series, and simultaneous homing of both carriages would not be available.
-
1.F/f
2.F/f
3.F/f
Thanks.F is multiple independent X carriages. I think it's possible to implement this without any firmware changes. You would use the M584 and M574 commands in homex.g and homeall.g to switch between motors and endstop switch locations, and M584 to switch X motors in the tool change files. You would need to connect the two normally closed X endstop switches in series, and simultaneous homing of both carriages would not be available.
I was thinking of this the other day. With two x carriages, one may have a different z offset than the other, is there a way to incorporate a move to lower the bed by some amount (to clear any edge clips/obstructions) and then raise it to the other tools z offset during toolchanges?
-
Yes, there is a Z parameter in the G10 command that defines the tool offsets. You can define whatever parking moves you want in the tool change gcode files.
-
I was not aware of tool change gcodes… this is fascinating. The more I use RRF, the more I am impressed by its capability.
Does the mere existence of T0.g, T1.g, etc, allow for their execution upon tool selection?
-
They are called tpree0.g, tpost0.g and tfree0.g for tool 0, and similarly for the other tools. See https://duet3d.com/wiki/Configuring_RepRapFirmware_for_a_Cartesian_printer#Tool_change_files.
-
Curious if there is a beta of the Grid leveling that can be tested
The grid levelling is more than 50% implemented in the 1.17dev5 release that is now on GitHub. You can define the grid using M557 and probe it using G29. Still to do is to finish the interpolation code, then add save/restore of the height map to file, and segment long moves. I may get time to do those next week.
-
Hi all,
I have not found a smooth way to have the heat bed cooled down in a controlled (following a temperature function) way.
Just switching the heatbed power off cools down to fast and results (from my opinion) on some filaments in warping on the print object.How about implement a firmware function to allow the heat bed cool down on a parameter like e.g. 3 ° Celsius per minute ?
The same feature would be useable for those having a heated chamber.What do you think ?
Regards
Pumlux -
That feature could certainly be added. However, I haven't seen anyone else ask for it. OTOH a common complaint is that the bed cools down too slowly and a fan is needed to speed up the process.
What is the construction of the bed on your printer? Does it have insulation beneath it?
-
I use a 8 mm Aluminum heatbed with some temp isolation at the reverse side.
I notice that (depending on the filament) the edges are warping.
This warping may occurre during the print itself, or even when not happing during the print, it can happen after printing,
when the temp is falling too fast.
Currently I'm sitting beside the printer and do manually controll the bed temp in some steps downwards.
I have the impression this helps, may be others didn't try this, or have no warping issue at all with the filament.Not sure how much work it is to add this as a feature into the firmware.
How about having a macro that after print is completed, contains some timers with mapped temperatures ?
e.g.
Macro cool_down
timer 1: 5 minute (after Macro call) - bed temp 70 °
timer 2: 10 minute (after Macro call) - bed temp 60 °
timer 3: 15 minute (after Macro call) - bed temp 50 °
timer 4: 20 minute (after Macro call) - bed temp 40 °
timer 5: 25 minute (after Macro call) - bed temp 30 °
timer 6: 30 minute (after Macro call) - bed heater off -
I had no idea that the wish list was so long, what would we do without you.
Here are my priorities.O. Support for restore points. This would allow the print to be paused, a restore point created, and the printer shut down - either automatically because of power failure (although a UPS or SLA battery would be needed to power the printer for a few seconds), or manually. Then the printer could be re-started and the print continued from the same point. Only practical for 3D printers that can be re-homed when there is a print on the bed, or for which the motors can be relied upon to retain their positions if they are shut down at an appropriate full step position.
B. Multi-threaded web server, capable of supporting several concurrent connections even when one of them is uploading a file. May also increase the speed of file uploading a little.
J. Dynamically-varying microstepping, allowing true 256x microstepping at low speeds, with microstepping automatically reduced for faster moves.
M. Babystepping, i.e. ability to change where the printer thinks Z=0 is in small steps during a print.
C. Predictive temperature control. This will replace PID. Probably the main benefit is that it will have a simple and fast auto tune procedure. implemented in version 1.15 -
I might have missed it but did babystepping make it into one of the updates?
Also will grid levelling be available for delta as well as other kinematics?
Just read the grid levelling thread. -
Babystepping is still on the to-be-implemented list. Grid based bed compensation got more votes.
-
A filament tracking with encoder plug to an endstop pin can be my request on firmware wishlist !
