Acceleration override while probing M558
-
The M558 command allows for travel and probemove speed overrides but I would love to jerk/acceleration override added as options.
My reason for this addition is as follows: I just a smart effector with a custom watercooled heatbreak I designed. The heatbreak itself and water/waterlines swinging around are source of false triggers. I have played around with using different combinations of high/low sensitivity on the smarteffector, faster/slower probe speed and waittimes. Yet, in my instance, the issue the instant the effector starts to move often triggers the probe.
Thinking about this I don't think adjusting the sensitity or speed is the correct way to handle this. The root cause is innertia at the start of the move itself. And I belive this should be handled by adjusting the jerk and possible the acceleration as well.
I am currently using a diy workaround my manually overriding these values in my bed.g file and resetting them afterwards. This is subobtimal as the settings effectively get defined twice, once in config.g and again in beg.g. Furtermore this fix does not work when running mesh grid probing.
-
@nxt-1 said in Acceleration override while probing M558:
I am currently using a diy workaround my manually overriding these values in my bed.g file and resetting them afterwards. This is subobtimal as the settings effectively get defined twice, once in config.g and again in beg.g. Furtermore this fix does not work when running mesh grid probing.
There are a couple of ways to avoid duplicating values.
One is to create a file with a suitable name that contains the commands for the normal settings.
You then call this file from config.g using M98.
You also call it from bed.g or mesh.g to restore the normal settings.
The other way with v3.3 or better firmware is to create a couple of global variables, in config.g, to hold the normal settings.
Then you can reference these variables in bed.g or mesh.g to restore the normal settings.
Frederick
-
@fcwilt Thanks for your input.
A couple of comments on the define in a separate file route. This indeed is a clever workaround to having to duplicate values. At the same time it does strike me as kind of ugly (athough less then what I am doing now
). I am not a big fan of spreading around configuration commands in different files though.
You reference mesh.g and after searching the forum I have found a couple of mentions about is, but I have never known this file to exist. It also doesn't not seems to be mentioned in the documentation, nor does it appear among the system files on my printer. What am I missing here? Assuming mesh.g is similar to bed.g, it's existence would be essential to use the above technique. Otherwise I wouldn't be able to introduce my own gcode before and after the G29 command.The global variable route is an option as well. To me this is less 'dirty' then the separate file. I might look into this while/if my idea get implemented.
-
@nxt-1 said in Acceleration override while probing M558:
@fcwilt Thanks for your input.
A couple of comments on the define in a separate file route. This indeed is a clever workaround to having to duplicate values. At the same time it does strike me as kind of ugly (athough less then what I am doing now
). I am not a big fan of spreading around configuration commands in different files though.
You reference mesh.g and after searching the forum I have found a couple of mentions about is, but I have never known this file to exist. It also doesn't not seems to be mentioned in the documentation, nor does it appear among the system files on my printer. What am I missing here? Assuming mesh.g is similar to bed.g, it's existence would be essential to use the above technique. Otherwise I wouldn't be able to introduce my own gcode before and after the G29 command.The global variable route is an option as well. To me this is less 'dirty' then the separate file. I might look into this while/if my idea get implemented.
Before global variables I used separate files - that to me was better than duplicating values.
Now I use global variables in several places.
I don't know exactly when bed.g and mesh.g were introduced but they seem now to be the "preferred' way of doing things.
It's pretty simple.
G32 is used for bed leveling and executes bed.g
G29 is used for mesh compensation and executes mesh.g - if it exists.
I just create these files in the System folder and put into them the commands that I want to have for each process.
I prefer to have all the commands needed to insure the process completes successfully.
Which means I have some commands that are typically put into config.g. And I may be executing some commands that may have already been done in some other process.
Example of commands that typically are in config.g but I put into these files, as needed, are the commands to specify the probing grid for creating the height map or the commands to configure the Z probe.
Configuring the Z probe is another place where I have commands in a separate file that I can call from wherever needed to be sure the probe is configured with the most recent values if I have perhaps tweaked some of the values.
I create several files that perform common tasks so I can invoke them from multiple places if needed.
-
@nxt-1 to add to what fcwilt said, G29 calls mesh.g if it exists, or just executes G29 S0 to create the heightmap if not. So if you create a mesh.g file, you can put whatever pre/post commands in that you like, just have G29 S0 somewhere in the middle
I do the separate file approach in my setup for the same reasons as you. I also drop the motor currents to reduce damage from a nozzle strike if probing fails. This is less of a concern now with the BLTouch than it was with a piezo.
Back to your original wish, my vote would be for a generic command(s) to a command that reduces the machine limits (accel, speed, jerk etc) to a percentage of the set limits. Something akin to M913 for motor currents.
This means it could be used more generally for other use cases. Ideally I'd like to see it used by slicers for acceleration limits for different move types instead of changing the machine limits (potentially to higher values!)Edit: corrected to G29 S0
-
@nxt-1, RRF already reduces acceleration during probing moves, and if the jerk policy is set to the default 0 then it will not use jerk during non-printing moves.
Do you already have a M558 R parameter to allow the effector to settle before it starts the probing move? If not, I suggest you add one. If you have, try increasing it while leaving the jerk and acceleration alone.
-
@nxt-1 said in Acceleration override while probing M558:
You reference mesh.g and after searching the forum I have found a couple of mentions about is, but I have never known this file to exist. It also doesn't not seems to be mentioned in the documentation, nor does it appear among the system files on my printer. What am I missing here?
It was introduced with RRF 3.2, so quite recently. It is mentioned in the G29 wiki entry.
@nxt-1 said in Acceleration override while probing M558:
At the same time it does strike me as kind of ugly
I disagree. The beauty of RRF is that many things can be done without requiring them to be coded directly into the firmware itself. It's flexible enough and generic enough to allow you to script out how you want things to happen without requiring DC42 to custom code it for every specific desire. Before with just macros it was powerful already, but now add conditional gcode and variables and the object model and you've got a pretty powerful environment to accomplish a lot. Is it as pretty as having a new variable in M558? No, but it already has a dozen variables, which in a way is ugly itself.
-
@dc42 said in Acceleration override while probing M558:
@nxt-1, RRF already reduces acceleration during probing moves, and if the jerk policy is set to the default 0 then it will not use jerk during non-printing moves.
Do you already have a M558 R parameter to allow the effector to settle before it starts the probing move? If not, I suggest you add one. If you have, try increasing it while leaving the jerk and acceleration alone.
Yes, as I stated in the first post I played around with the waittimes. Also, the travel move is not the issue here as I explained. The issue is the start of the actual probe move.
@phaedrux said in Acceleration override while probing M558:
I disagree. The beauty of RRF is that many things can be done without requiring them to be coded directly into the firmware itself. It's flexible enough and generic enough to allow you to script out how you want things to happen without requiring DC42 to custom code it for every specific desire. Before with just macros it was powerful already, but now add conditional gcode and variables and the object model and you've got a pretty powerful environment to accomplish a lot. Is it as pretty as having a new variable in M558? No, but it already has a dozen variables, which in a way is ugly itself.
Yes I completely agree that is what makes RRF so nice. Yet I do feel like there is a big difference in not having to recompile firmware and spreading around pieces of the configuration around across multiple files. Especially vital pieces like accel and jerk settings.
Seeing the consensus of a few big forum contributors view this differenty then I do
, I will adapt and use one of the workarounds provided. Does anyone have an example of a mesh.g, just so I can see what it's syntax is. -
G29 with no S parameter now runs file sys/mesh.g if it exists; otherwise it behaves like G29 S0 as before
At its most basic mesh.g would need to contain
G29 S0to initiate a mesh compensation probing routine. As long as the probe and mesh grid configuration are already in config.g. Beyond that you can get as fancy as you want. Preheat, homing, special probe configuration, speed settings, etc.; Macro to run a mesh bed compensation routine (G29) ; M291 P"Grid bed compensation map will be cleared and re-calculated. Ok or Cancel?" R"WARNING. This will take about 30 minutes." S3 ; User must click OK or cancel. ; Preheat to probing temps M291 P"Preheating to bed to 60 and nozzle to 210 for accurate probing" R"Proceed?" S3 T0 ; Activate first tool M190 S65 ; Set bed to 65 and wait ;M109 S210 ; Set nozzle to 210 and wait. Used only for stall detection probing. ; Clear current mesh compensation map and disable compensation. G28 ; Home all M561 ; Disable any current bed compensation ; Set lower speeds for Z homing and lower Z motor current M98 P"ZSpeedsSlow.g" M98 P"CurrentsHoming.g" ; Drop motor current to prevent damage in case of head crash M98 P"0:/macros/musical tunes/GetAttention.g" ; Tone to get user attention M291 P"Running mesh grid compensation probing cycle. Do not disturb the printer." M558 H1.5 ; lower dive height G29 S0 ; Run mesh compensation M98 P"0:/macros/musical tunes/GetAttention.g" ; Tone to get user attention M558 H3 ; return dive height ; Turn off heaters M140 S0 ; Set bed to 0 and release M104 S0 ; turn off hot end heater M98 P"ZSpeedsNormal.g" M98 P"CurrentsNormal.g" M291 P"Homing" G28 ; Home all M84 ; turn off the motors M291 P"Check heightmap for results." R"Probing complete!" S3