mesh.g parameter handling

fcwilt

@generisi said in mesh.g parameter handling:

What I have observed is that when G29 is called either without an "S" parameter, mesh.g is called. Is that how it is supposed to work?

Yes - that is the current way of doing things.

G32 invokes bed.g for Auto or Manual Bed Leveling code

G29 invokes mesh.g for creating height maps needed for Mesh Bed Compensation.

Now the code needed for each feature has a "home".

The current DWC has a pull down menu with, among other things, G32 and G29 with the appropriate labels.

Frederick

GeneRisi

@gixxerfast "and in RRF3.3 and later parameters present are passed to mesh.g". I don't think that sentence explains the behavior I see because I expected all parameters to be passed in RRF3.3 and later.

Gixxerfast

@generisi I havent't tested all options but as far as I see it. If called without an S parameter mesh.g is called. Any other parameters are sent to the macro.

If called with a S parameter mesh.g isn't called.

Have you found it to work differently?

In my mesh.g I call G29 S0; If it would call mesh.g I would have an endless recursive loop.

fcwilt

@generisi said in mesh.g parameter handling:

@gixxerfast "and in RRF3.3 and later parameters present are passed to mesh.g". I don't think that sentence explains the behavior I see because I expected all parameters to be passed in RRF3.3 and later.

I have not encountered the need to have any parameters when using G29 or G32.

They just are easy ways to invoke different chunks of code. Rather like G28 invokes homeall.g, G28 X invokes homex.g, etc.

Frederick

GeneRisi

@gixxerfast Yes, what I saw is that a G29 that includes an "S" parameter does not call mesh.g, even if other parameters are included that G29 doesn't interpret.

So, G29 T2 call mesh.g
G29 S2 does not call mesh.g
G29 T2 S2 does not call mesh.g

Gixxerfast

@generisi OK, I cannot find the T parameter in the G29 documentation. What does it do?

Aha, now I see. If you add your own parameters you mean ? Or?

I don't think you can add your own parameters to existing and defined gcodes. I can't test myself right now since my printer is occupied printing.

GeneRisi

@fcwilt I have a use case with a tool changer. The z probe is not physically associated with any tool. All tools are offsets from the tool-less z probe home position. When a tool is picked up, mesh compensation is turned on. When the tool is put back, mesh compensation is turned of. This way, the z home position doesn't change when no tool is mounted. Give this scenario, it is possible, with G29 S1, to use an height map that is not current. I want to create a height map that is current and only use it if it is current. Current means that the machine hasn't been reset or z rehomed. So, G29 S1 can be issued ( by mistake or a bug) when I don't want to use the stored (on SDCARD) height map file.

With my new found understanding, I will use "T" as a substitute for "S" for the S0, S1 and S2 use cases. In the mesh.g macro, I can check if the height map is current and if it is, create the correct G29 "S" gcode.

Is this clear?

GeneRisi

@gixxerfast Yes, if you add parameters that are not defined AND don't use "S", then those parameters are passed to mesh.g A use case is in my response to @fcwilt .

Gixxerfast

@generisi Yes, thanks, I understand now what you want to do.
Here, I think, we have to wait for a response from the officials. I don't know if you're allowed to add your own paraneters to existing gcodes in this case and what is suppose to happen if you do.

Still, as you explain it, it behaves as I expect it to do reading the documentation: With S parameter --> no call of mesh.g, Without --> call of mesh.g

Cheers

T3P3Tony

@generisi

This line from the documentation;

If G29 is commanded with no S parameter, then file sys/mesh.g is run if it exists, and in RRF 3.3 and later any parameters present are passed to mesh.g.

Reads to me like:
If
G29 is sent with no S parameters

and
mesh.g exists

then
run mesh.g
__and
___if running RRF 3.3
_____pass any other parameters to mesh.g

else
run G29 S0

So the only way to pass your own parameters with G29 is to not have any S parameters in the command as you have found out. replacing the S parameter with another one and then creating custom logic to do what you want in mesh.g sounds like the way forward for your usecase.

JoergS5

@generisi IMHO, I would avoid any FST parameters ( S is an exeception here, as it is an official parameter of G29), because they have high order and T is interpreted as new tool command in a multi-command-line.
In https://forum.duet3d.com/topic/25562/params-not-working-consistently-rrf3-3-0/10 David said "there are no standard G commands that have a T parameter. So RRF treats T after a G command as a new T command."

GeneRisi

@joergs5 Thank you; that is good to know. Maybe Q ?

JoergS5

@generisi Nist doesn't mention Q, this seems to be a good letter.