Reduce max. Acceleration and Speed
-
Maybe I'm missing something, but if you have to work out what percentage to use - then you might as well apply the absolute value?
To restore to nominal power you could either execute config.g or separate that section to its own config file and call it both from config.g and as needed.
I.e. try to work with what you have instead of against it?
-
@bearer said in Reduce max. Acceleration and Speed:
Maybe I'm missing something, but if you have to work out what percentage to use - then you might as well apply the absolute value?
My thoughts exactly. This proposal will only mean that users can replace numbers with different numbers in order to achieve what is already possible.
I don't know enough about coding to say if a single command could interpret values as meaning a) absolute values if they are integers >1, else b) restore to full (configured) current if the value ==1, else c) set percentage current if it's a non integer<1. If not, then additional gcode commands would be required, just as M913 is required in addition to M906 to achieve the same thing.
And if this gets implemented, then it will only be a matter of time before some user or other wants it to be expanded for M204, M566, and goodness knows what else. Which leads to a whole raft of additional gcode commands, essentially duplicating what is already possible.
Of course, that's just the opinion of an old fart as I'm sometimes reminded.........
-
@deckingman said in Reduce max. Acceleration and Speed:
@bearer said in Reduce max. Acceleration and Speed:
I don't know enough about coding to say if a single command could interpret values...If would be simple enough to allow the presence of the % symbol to indicate mode thus no need for multiple commands.
One issue might be insuring that prior to any use of a percentage of a value that the absolute value had been set.
-
@fcwilt Why didn't DC do that with M906 instead of introducing a new M913 gcode?
-
@smoki3 said in Reduce max. Acceleration and Speed:
@fcwilt it depends on which tool is mounted. For direct drive I have to reduce the speed, for Bowden tools I can use the max
Sorry but I'm confused. You said that with the ability to set a percentage in the "tool" change bit of code you would only have to change config.g to deal with a different tool.
I took from this that the different tools had unchanging values that were all fixed percentages of the "master" values in config.g
Can you clarify what these different "tool" change files are doing?
Thanks.
Frederick
-
@fcwilt the tool files are handling the tool change on Reprap firmware.
Drive to the dock, grab the tool, apply offsets, park the tool and so on. They are hard coded in rep rap firmware.
-
@bearer said in Reduce max. Acceleration and Speed:
Maybe I'm missing something, but if you have to work out what percentage to use - then you might as well apply the absolute value?
To restore to nominal power you could either execute config.g or separate that section to its own config file and call it both from config.g and as needed.
I.e. try to work with what you have instead of against it?
Yes the procedure to work out the percentages is the same as if I work out the absolute value.
But for example I put a raspberry on the tool head (not on the tool) then the mass gets higher for all 4 tools because the raspberry is carried all the time. So I have to reduce the acceleration from 6000 to 5000 to avoid ringing. Then I have to change all the tpost, tfree script and the config.
If I had percentages then I just edit the config and the values of the single tools get adjusted automatically.
And this is the same behavior for the motor current with: You put a motor on you printer and figure out the max. motor current once and define it in the config. In some cases you need to reduce the current (e.g. idle, homing). Then for example you have to replace this motor because of a defective and the new motor need a different current. With absolute values you have to edit all files which have absolute motor currents. With relative currents you just edit the config.
-
@smoki3 Ahh. So you are saying that on a regular basis, you are changing the mass of the entire gantry which in turn changes the mass of all tools that are attached to that gantry, yes?
Your opening post stated "............if you have different tools with different weight." But changing the mass of the gantry to which the tools are attached is an entirely different thing.
That being the case, and if you genuinely change the carriage mass on a regular basis, then I can see the benefit of your proposal.
-
Yes this is exactly what I mean. Sorry may my initial post was not clear enough.
-
@smoki3 Oh course, changing the maximum print speed (M203) won't really help because most moves generated by the slicer will be at feed rates which are a lot less than this maximum. So you will need to re-slice anything you print whenever you change the carriage mass, in order to change the feed rates used for print moves. And if you want to have percentages of accelerations, then you will also need to apply your proposal to M204 as well as M201. The instantaneous speed change (M205 jerk) will likely also need to be different depending on carriage mass, so that would need to changed to allow percentages as well. I would imagine that's quite a lot of work.
-
@deckingman In the slicer I use 600mm/s as travel speed. So don't have to reslice everything. For printing moves it doesnt make any difference. There mainly the accelerations play some role.
I did different tests, but jerk doesn't have much influence on the print quality.
-
@smoki3 said in Reduce max. Acceleration and Speed:
@deckingman In the slicer I use 600mm/s as travel speed. So don't have to reslice everything
In you opening post, you stated quote "For different tools you may need different max. acceleration speeds and max. travel speeds". I take that as meaning you want to use different speeds for different tools. If not, why not (given that the mass is what you say you are regularly changing)? If so, then because the feedrates for print moves are governed by the slicer commands, then you need to re-slice in order to change those print speeds.
-
@deckingman said in Reduce max. Acceleration and Speed:
@smoki3 said in Reduce max. Acceleration and Speed:
@deckingman In the slicer I use 600mm/s as travel speed. So don't have to reslice everything
In you opening post, you stated quote "For different tools you may need different max. acceleration speeds and max. travel speeds". I take that as meaning you want to use different speeds for different tools. If not, why not (given that the mass is what you say you are regularly changing)? If so, then because the feedrates for print moves are governed by the slicer commands, then you need to re-slice in order to change those print speeds.
Yes but if the slicer request 10000mm/s and you limit the firmware to just use 500mm/s then the printer is just moving with 500mm/s. So the travel speed in the slicer is always the same for every tool. But it will be limited by the firmware.
And I am not talking about print speeds I am talking about the travel moves. The print speed are so low that the printer can easy handle this for all tools no matter which mass.
-
@smoki3 said in Reduce max. Acceleration and Speed:
....................... And I am not talking about print speeds I am talking about the travel moves.
Ahh, that's something else that wasn't clear until now.
I think it might be an idea if you detailed or summarised exactly the scope of the changes you are asking for.
-
With a newfound understanding, maybe you could achieve it by means of the object model. I think the sample on that page is outdated so poke around with
M409to see if you can find the current value and apply a percentage of it?If its not in the object model you could probably use the variables function when its available (in 3.2?)
-
@bearer this a good idea. But I dont find the max acceleration in the object model
-
then you could go with using a variable for now; altough you'd need to do something like create a dummy tool and store the acceleration value as f.ex. tool offsets, or dummy fans/heaters etc.
not sure if you can set
tools[n].offsets[0]..tools[n].offsets[2]or if you need to useG10to set the offset, but you can test that easily enough. If you have more axes than xyz, you can probably set more than 3 offets pr tool as well.
