Duet WiFi firmware new feature priorities
-
I' ll add to the list a "region extrude inhibit" some times a piece comes off of the bed, if I can do a region extrude inhibit, I can pause the printer, remove the piece that comes off mark a region and inhibit the extrude in that region. when the print finish i can print the piece that fail
-
I've spoken to David previously about adding support for a simple switch based filament out sensor to the PanelDue so that you don't have to run as many wires (I'm on a delta and the PanelDue is right next to my spools).
If you have any interest in that please chime up.
Is a cool feature. I have the panel due in the printer's bottom. For me is the same to wire from duet or from panel due (in my setup I prefer from duet )
-
@dc42 My apologies. Everything I'd seen to this point (including this thread) seemed to indicate it wasn't yet a feature (reading comprehension fail).
Can it ignore the sensor when not actually printing? When my print is finished, the Tunell sensor will trigger a non-moving condition. As a result, the switch would be triggered until I reset it. This would cause the system to go to the "pause position" while at home and that's not so awesome of a result on a Delta printer.
A valid answer is, dump the fancy electronic sensor for one that doesn't trigger unless it's out of filament but I hope that's not the one you give me.
If you follow the link to the gcode wiki in my previous post, you will see that the M581 command has an option for the trigger to be recognised only while printing from SD card.
M581 is recently implemented and not much used yet. Please let us know how well it works with your Tunell filament sensor.
-
Another Request:
Add a switch to M117 Gcode to allow send de message via email (to check via email if the printer started to print or the print finished for example)
M117 S"This is the subject" -D"john@example.com" -B"This is the message body"
-
Just got mine. Luverly..
Can the BL Touch probe be added.
Steve a newbe -
About the BL touch, Have a look at this thread : http://forums.reprap.org/read.php?416,669287,669287#msg-669287
Short answer : Not yet
Longer answer: It may be workable to output a servo compatible signal with a fan/signal output, using M106 code to adjust the PWM, but this is not yet tested. -
In version 1.15 the PWM resolution is greatly increased. One of the main reasons I did this was to provide better resolution of the servo pulse length when a PWM channel is used as a servo output.
-
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.
