Duet WiFi firmware new feature priorities
-
Why don't you reset the extruder % and speed changes in stop.g and use M0 at the end of the print and no change in RRF needed.
Indeed, the problem can be solved by adding suitable commands to the macro files. That said, I think there is a case for some sort of change.
Suppose RRF were to apply the speed and extrusion parameters only to printing moves, I.e. moves with both XY movement and extusion? So homing, travel, retraction and filament load/unload would not be affected.
-
Maybe some sort of flag or toggle in the user config so that users who want the firmware to reset speed/extrusion can have it, and those that want it left as is can have that?
Definitely not. That increases the number of things that can go wrong and have to be tested, and the number of things that users have to learn or be told.
In which case, just leave as is. Users will have to learn or be told about any change.
-
so my opinion is that the printer should never go past the max speeds set in the main config.g
with that is also homing. pause, ect.
that's why theses things are set in there. if i was an advanced user theses things like adding extra G code in the print file and changing things with command line are no big deal.but if i was a beginner and i was playing with my speed ( as we all have) then to see it crash when done printing would really annoy me.
it could be as simple as a section in the config.g that sets this as an option, "over rive all speed controls for % of speed"
and then the user can do what ever they want knowing that nothing will change and everything will go way to fast ( or everything except the print will go faster) depending on the selection in config.g
for me, i spend a lot of time finding out what the maximum speeds are for everything, rapid moves, homing, accelerations ect. and set them so things are right at there liniment.
so i want those to never change, even when i take the speed past 100% there already " Tuned" so i don't want them to sped up.
only the printer movies should speed up ( and the extruder )
I just wanted to point this out because it can be a real pain when things start going crazy. lol most beginner users wont know what to do to fix it or whats going on.
i program a lot of things to slow and see how its printing then speed it up and keep checking, once I'm happy i will set the next print to that speed in the slicer. or for cnc and stuff. ( think more than just printing)
iv had my printer up to 1000% of speed lol yeah when that homing or pause hits … its over lol
thanks for the amazing feed back and response.
~Russ
-
Russ
I get the frustration, however the counter is it can be odd undefined behaviour for a user to have set the extrusion ratio(for example) to 110% and then see it auto reset to 100%.
Another example of a case where one could like selectivity is in retract speed. If for example I set the speed to 500% I want the moves to be at 500% (including extrusion obviously) then I get the object in a much shorter time but rather roughly printed. However if I am already at the edge of the extruder's capabilities then increasing the retract speed by 500% would cause all sorts of issues:maybe skipped steps or ground filament. So in this case I want the retract speed to stay at 100%. The problem with this case is it is very user specific and keeping the retract speed (in my example) at 100% is counter intuitive to someone using the speed multiplier while printing a retraction torture test to play with the speed to get the perfect one for their setup. Of course it's possible to think of some examples for other similar changes.
As I have thought about this more I am firming up on the idea that it is up to the macros or user commands to change these speeds/ratios/ amounts not the internal firmware.
-
yeah, i agree with you,
things like you say i agree on, those would need to change with the % speed,however for a lot of other things, it is very bad lol like homing… or going past a set max travel speed... all extruder moves let er rip! those will most likely not make a mess of the printer
it just needs to be thought out and explained some where, ( for new people to understand)
in the end i'm not the correct person that should decide what to and not to set % of speed.
but i'm more than happy to point out thing like this that may not have been looked at
hehe( scratches his head)
~Russ
-
When you increase the speed with M220, the maximum speeds, accelerations and jerk you configure in config.g are still respected.
-
When you increase the speed with M220, the maximum speeds, accelerations and jerk you configure in config.g are still respected.
ok cool, i was not sure about that one,
is the M220 the one on the interface? ( slider bar on web interface and PanelDue?)
so really its mainly Homing, ( this is where i normally have seen it) as well i have seen it on the start of a print. or a finish, but that could just be that i did not have my max speed set right at the time.
Thanks !!!
~Russ
-
Yes, the speed slider uses M220.
Currently the speed of homing moves does get affected by M220. This is one of the reasons that I am thinking of changing M220 to affect printing moves only, so not travel or homing moves or retractions. Firmware retractions are already not affected by M220.
-
Yes, the speed slider uses M220.
Currently the speed of homing moves does get affected by M220. This is one of the reasons that I am thinking of changing M220 to affect printing moves only, so not travel or homing moves or retractions. Firmware retractions are already not affected by M220.
ok, thanks David!
yeah, I've had a lot of experience with marlin, and homing in not effected by speed settings. However even marlin will crash on the start of the print if the speed % is set way to high. That first move from home to the bed is a "Print" move.
with that said, it would be smart to have the the homing moves not be effected by the % speed settings.
I'm not sure if there is an easy way to do it within the firmware with out other things being effected.
I do agree with others that if the %speed is set to xx value then it constantly being overwritten is a pain.
Is there was a way to " read" the value of the % speed setting? Then we could set up a simple line of code at the beginning of the home.g file to read and save that % speed in memory, then set it to 100% run the homing stuff, Then at the end just wright back to where it was ???…
the same with all other things we all ways want to run at 100% of speed. like bed probing and stuff ( I'm not sure if that speed is effected or not?) but we could use that command to read speed setting> do something at 100'%> wright back speed setting from before.
this might be a useful thing for other things as well...any how just a thought, I'm not even sure is possible from the front end ( code) or if its something already there i don't know about..
Thanks!!
~Russ
-
On option would be to have the speed setting included when the firmware saves parameters before executing a macro file. Then you could use M220 S100 at the start of the homing files, bed.g etc. But then you wouldn't be able to define a macro that e.g. sets the speed to 150%.
-
I wouldn't go much farther than disabling the speed override for homing. If maximum speeds are set for all axes, and they are reasonable, no crashes should ever occur. In my opinion, max speeds should be set so that no g-code can cause undesirable behaviour. If I accidentally home my printer at 10,000% speed, it will (presumably, I haven't tried it) home at the max Z speed of 60 mm/s. Isn't that what limits are for? If your printer is crashing upon first move, limit the Z speed to one that will not cause a crash.
-
When you implement "Support for three independently-controlled Z motors" can you also add support for two independently-controlled Z motors? I have two motors on each side of the heated bed, and I believe this isn't an uncommon setup.
-
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
