Duet WiFi firmware new feature priorities
-
I'm not sure if this has been noted before or not, but ill address it here and you can correct me if its fixed.
here is my scenario, I set up a print to run at 30mm/s, however along the way i see its running well so i bump it up to 60mm/s
( 200% of speed) now when the print is finished the delta tries to home or move some where else to get out of the way and its also at 200% of speed.and that's when things get ugly….
and if for some reason it it dose make it to that location with out crashing and i forget its at 200% of speed, its almost guaranteed that it will crash trying to move to the first position of that next print.
I have all my other moves confined set at just the right speed ( Homing, max travel speeds) , so if its over 100% things get crazy.
is there a way to set the % of speed to only be that when running the print? i'm sure you can add it to the G code but i would think it could be built in so others done experience the same problem?
i use that speed function all the time to run tests and all kinds of stuff.
also dose the higher % of speed also over ride the config files max speeds?
Thanks!!
~Russ
-
Hi Russ,
Yeah I had this issue so now I use M220 S100 in my end gcode and in my cancel.g so any time a print ends I return to 100% speed before homing and begin at 100% for the next print.
I also find for autocalibration I reduce my accel/jerk and speed then return it to normal within my bed.g. -
OK, thanks for the reply, i still wonder if it can be integrated in the firmware??
also i could add to the pause.g for when i want to do that, but when i start back up i guess ill need to change the speed again.
say is there some kind of script that can be used so " get" the current speed, then put it back after a pause.g?
any how. ill add those to my .g files for now!!! Thanks!!
~Russ
-
Hi Russ
Thanks for pointing this out. Interesting question about how and when we want the firmware to overwrite the commands entered by the user in a non obvious way. My perspective (personal view entirely) is that we want the firmware to stay as the user set it until there is a reset or a fault. So if you have changed a speed, temp, acceleration, or any other variable that is what it stays at.
That said there may be very good reasons to deviate in specific cases.
-
On the whole I agree with Tony - the firmware should behave in a consistent and obvious manner. However, here are some options I can think of:
-
Reset the speed to 100% when M0 or M1 are executed. This would handle end-of-print (assuming you use M0 in your end gcode) and cancel print.
-
Always execute homing and similar special moves at 100% speed (i.e. G1 moves with S1 or S2 parameter)
-
Always execute extruder-only moves (or extruder + Z movement only) at 100%
Comments? Other suggestions?
-
-
Oh I would love that!
Only (small) reservation I have is that the more of this kind of functionality we add, the murkier the whole system becomes. The system will start to show behavior that is not totally expected.
In this case that is not a danger, as the system will do what you expect, and not what it should do. (if you get my drift)You are a very busy man, David!
-
Personally, I think the firmware should "behave itself" and not try to second guess and override what the user asks for. I've done similar things to the OP but with extrusion multipliers. One soon learns by ones mistakes. During commissioning, I started slow but played around with the speeds, not just for printing but for homing and non print moves too and I'd have been tearing my hair out if the firmware kept overriding what I was trying to do.
I hate auto correction on my 'phone which doesn't understand proper nouns and/or decides it knows what I mean better than I know myself, but I love it when the spell checker on my PC underlines something. So maybe DWC should how values other 100% in big Red letters as a warning/attention grabber but otherwise it should be left alone.
Well that's my twopence worth anyway…..
-
I'll see if some sort of consensus on this emerges, and if so, look at changing the behaviour in firmware 1.18. It had already occurred to me that whatever we do to the speed override should perhaps be applied to the extrusion override too. OTOH I use the extrusion override to adjust for the characteristics of particular filaments, so I don't generally want to reset it after a print unless I am changing filament.
-
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?
-
Here are my picks.
1-A
2-F
3-J
4-L
5-K -
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.
-
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.
-
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.
