params not working consistently RRF3.3.0

achrn

@o_lampe said in params not working consistently RRF3.3.0:

@achrn Did you try it with adifferent macro name, like G123?
Although G99 isn't listed in the Duet-gcode wiki and thereby should be allowed to be used as macro name, it might be otherwise reserved and already has a T-param. (wild guessing)

Oooh, good wild guess. I had tried G99 and G801, but they are both memorable numbers.

However, I've now tried it as G147.g and G528.g (two random numbers) and I get the same behaviour.

o_lampe

@achrn Next guees is using Mnnnn (4 digits at least) as macro name. It would make sense to me, using M-code as macro name. I'm sure your macro is highly "machine specific"?

achrn

@o_lampe even better guess!

M5287.g works like it should:

But G5287.g (which I tried out of interest) doesn't work. So then I've played with some other names, and parameters D and T:
Naming the file G67, G99, G147, G528, G801 or G5287 does not work (it can't see parameter T).
Naming the file M67, M528, M801 or M5287 does work (it can see parameter T).

My macro is not really machine specific, actually - it's effectively a G1 in polar coordinates for a catesian-coordinate machine and would apply to any cartesian coordinate machine. Parameter 'T' was intended to be the Theta angle, but I think I'll switch to using A for theta Angle! 'A' does work as G801.

So I think I can't use a parameter 'T' in a 'G' macro, though I can use parameters A, B, D, E, F and Z. I haven't tested other parameters. I can use 'D' 'E' 'F' and 'T' in a 'M' macro, but haven't tested other parameters.

(I haven't tested every possible combination in those sets, but every combination I have tested fits that pattern.)

gloomyandy

@achrn It may be because T1 is actually a valid gcode command in its own right (unlike D1), T1 is the gcode to select tool 1. I think you can in theory have multiple commands on the same line in some cases, but I'm not 100% sure!

fcwilt

@gloomyandy said in params not working consistently RRF3.3.0:

@achrn It may be because T1 is actually a valid gcode command in its own right (unlike D1), T1 is the gcode to select tool 1. I think you can in theory have multiple commands on the same line in some cases, but I'm not 100% sure!

Yes you can but the question is do things that look like commands take precedence over things that might be parameters.

Is the T1 treated as command and thus ignored as a parameter?

Easy enough to test.

Frederick

achrn

@gloomyandy said in params not working consistently RRF3.3.0:

@achrn It may be because T1 is actually a valid gcode command in its own right (unlike D1), T1 is the gcode to select tool 1. I think you can in theory have multiple commands on the same line in some cases, but I'm not 100% sure!

That seems to be it (almost). It looks like a 'G' macro allows for multiple commands on a line (so you cannot have parameters that look like the next command) but 'M' macros do not (so you can have parameters that could be a command).

If I create identical G67.g and M67.g files:

if exists (param.A)
  echo "got param A", param.A

if exists (param.B)
  echo "got param B", param.B
  
if exists (param.G)
  echo "got param G", param.G

if exists (param.M)
  echo "got param M", param.M
  
if exists (param.Z)
  echo "got param Z", param.Z

Both work with respect to A and B parameters:

The M67 sees G and Z parameters as parameters:

However, the G67 sees that as the next command:

Makes sense so far.

However, it gets a bit more subtle when macros are referring to themselves:
M67 A1 G1 Z100 is interpreted as one command with three parameters:

G67 A1 G1 Z100 is interpreted as two commands (though interesting this comes up blue)

So far so good - matches the hypothesis that G commands can stack on a row but M commands do not.

But then M67 A1 M67 Z100 is interpreted as two commands, which breaks that hypothesis!

I think I'll just stick to not using G, M or T as parameters, so it's A for theta Angle, not T for Theta angle.

JoergS5

@achrn interesting thread!

I searched for order information, in https://tsapps.nist.gov/publication/get_pdf.cfm?pub_id=823374 is on page 49 chapter 3.8 is a table about order of the commands, T(ool) is high priority. I would avoid S also.
According to https://duet3d.dozuki.com/Wiki/Gcode#Section_G_Code_Background_Information this NIST document is the base of RRF.
Now I understand why FST are avoided as drive letters.

dc42

@achrn there are no standard G commands that have a T parameter. So RRF treats T after a G command as a new T command.

There are several M commands that take T parameters, so RRF does not treat T after M as a new command.

achrn

@dc42 said in params not working consistently RRF3.3.0:

@achrn there are no standard G commands that have a T parameter. So RRF treats T after a G command as a new T command.

There are several M commands that take T parameters, so RRF does not treat T after M as a new command.

Thank you. Is there a list of safe-to-use parameters?
Can a comment be added at https://duet3d.dozuki.com/Wiki/GCode_Meta_Commands#Section_Macro_parameters - I'd add something myself but I don't know what I'm saying!

o_lampe

@dc42 Is it part of the NIST convention to allow only single letters as parameter?
I'd like to use something like Mxxxx §time_since_last_pause{global.tslp} to mark a parameter with a speaking name.
Where the § sign can be any other unused UTF-8 letter.

achrn

@achrn said in params not working consistently RRF3.3.0:

Thank you. Is there a list of safe-to-use parameters?

(talking to myself) It occurs to me this is easy enough to check. From my testing:

A G macro may not use parameters G, M, or T
A M macro may not use parameter M