[Possible bug] Params parsing

AndMaz

Hi

I'm facing a weird problem in params parsing with v3.4.5 and v3.5.0-beta4. For some reason param.E is being ignored in some scenarios.

Here's a repro code.

Contents of the test.g

echo "param.I="^param.I
echo "param.R="^param.R
echo "param.S="^param.S
echo "param.L="^param.L
echo "param.O="^param.O
echo "param.B="^param.B
echo "param.C="^param.C
echo "param.D="^param.D
echo "param.E="^param.E
echo "param.F="^param.F
echo "param.H="^param.H

NOT OK - param.E not parsed

M98 P"0:/macros/test.g" I"test" Rtrue S1800 Ltrue O0 B0.7 C0.7 D0.7 F0.7 H0.7 E0.6

Result:

param.I=test
param.R=true
param.S=1800
param.L=true
param.O=0
param.B=0.7
param.C=0.7
param.D=0.7
param.E=null <--- param.E was not parsed and the value is null
param.F=0.7
param.H=0.7

OK - - param.E parsed as it should
Command:

M98 P"0:/macros/test.g" E0.6 I"test" Rtrue S1800 Ltrue O0 B0.7 C0.7 D0.7 F0.7 H0.7

Note: param.E comes in the first place

Result:

param.I=test
param.R=true
param.S=1800
param.L=true
param.O=0
param.B=0.7
param.C=0.7
param.D=0.7
param.E=0.6 <-- parsed as it should
param.F=0.7
param.H=0.7

Is E a reserved key? Do we need to pass params in alphabetical order to be properly parsed?

dc42

@AndMaz thanks for reporting this. I confirm it is a bug. I will schedule it for fixing in the next 3.5 beta or release candidate.

https://github.com/Duet3D/RepRapFirmware/issues/878

dc42 created this issue in Duet3D/RepRapFirmware

closed Can't pass E parameter to M98 unless it is the first parameter #878

dc42

@AndMaz I found the problem. In your command:

M98 P"0:/macros/test.g" E0.6 I"test" Rtrue S1800 Ltrue O0 B0.7 C0.7 D0.7 F0.7 H0.7

the parameters Rtrue and Ltrue are not valid. Ideally, RRF would issue an error message for each of them. The letters in "true" are causing null T, R, U and E parameters to be created.

You can pass "true" using { } like this:

M98 P"0:/macros/Parameter test" I"test" R{true} S1800 L{true} O0 B0.7 C0.7 D0.7 F0.7 H"test" E0.6 H0.7

AndMaz

@dc42 thank you very much for quick response. You're a lifesaver!

shugo1110

Hi,
i see that my "invalid value for parameter '-'"-errors are related to this bug report.

With the current allowed-chars-list i get an error when i do a

M98 P"0:/anymacro" S-1

until this fix i also could do a

M98 P"0:/sys/home.g" XYZ

this is resulting in an error now.

dc42

@shugo1110 said in [Possible bug] Params parsing:

With the current allowed-chars-list i get an error when i do a
M98 P"0:/anymacro" S-1

That's a bug - thanks for reporting it. Workaround: use S{-1}.

until this fix i also could do a
M98 P"0:/sys/home.g" XYZ
this is resulting in an error now.

That's intentional. In most contexts, parameter letters must be followed by a value for that parameter. Older versions of RRF assumed a zero value if none was given, but that sometimes made it harder to diagnose what was wrong in the command line.