3.5b2 - Macros called from a job lose parameters.

pfn

This has been working for me fine in 3.4.x, however upon migrating to 3.5b2 I am encountering a problem in calling a macro with parameters from a job and get an error like: Error: in file macro line 18 column 12: meta command: unknown parameter 'H'

In the job, the macro is called as M98 P"job-prologue.g" T240 H110 L0.2 S0

This command works directly from the console. In some instances, the first run of the job with macro works. It's very odd as the check for exists(param.H) passes without error.

cube_1.gcode
job-prologue.g:

;M98 R1 ; commented out, tried with and without

if !exists(global.probe_block_detach)
  global probe_block_detach = false
set global.probe_block_detach = false

G21 ;metric values
G90 ;absolute positioning
M83 ;relative extrusion
M107 ;start with the fan off
G92 E0 ;zero the extruded length
M150 K1 R255 P192 S1 F0
if !exists(param.H)
  abort "Missing H"
M140 S{param.H} ; start preheating the bed
M190 S{param.H}

if param.H >= 100
  while heat.heaters[0].avgPwm > 0.28
    echo "Waiting for bed heater to settle"
    G4 S60
M150 K1 U255 B255 P192 S1 F0

set global.probe_block_detach = true

var need_g32 = false
G10 P0 S{param.T} R50; start preheat hotend_0

if !move.axes[0].homed || !move.axes[1].homed || !move.axes[2].homed
  set var.need_g32 = true
  G28
  if result != 0
    abort "Homing failed"
else
  G28 Z
  if result != 0
    abort "Homing failed"

if var.need_g32
  set global.probe_block_detach = false
  M402
  M98 P"k/brush-nozzle.g"
  G1 Z15 F2400
  M401
  set global.probe_block_detach = true
  G32
  if result != 0
    abort "QGL failed"

set global.probe_block_detach = false

if var.need_g32
  G29
M402

M116 P0

M98 P"k/clean-nozzle.g"
G1 X297 Y150 Z1 F12000
G1      Y50 Z{param.L} E30 F500 ;intro line
G92 E0 ;zero the extruded length again
M150 K1 W255 P192 S1 F0

pfn

Whats weird is when the heaters are turned on, these variable errors stop getting spit out.

dc42

@pfn I suspect this is an issue with the multiple file readers in 3.5. I will add your example to my list of issues to investigate.

pfn

@dc42 was there any change in b3 that would have helped here? I am currently avoiding b3 due to the news I've heard about extrusion issues with toolboards.

chrishamm

@pfn I have identified a bug that could erase the variables from the macro scope of a second file reader if the first one caused the print to abort. I have been unable to reproduce other variable-related problems apart from this scenario, even with your G-code scripts.

pfn

@chrishamm I hope that's enough to fix my issue then. At the moment, this is 100% reproducible causing problems in my configuration--I have to run my start gcode separately as a macro before invoking my print job.

But for me, this happens regardless of a previous aborted print. A slightly different scenario, but maybe it's related regardless.

OwenD

@pfn said in 3.5b2 - Macros called from a job lose parameters.:

In the job, the macro is called as M98 P"job-prologue.g" T240 H110 L0.2 S0

You can't use T as a parameter in your M98.
It will be trying (and failing) to select tool 240 and then treating the following H110 as a new command I believe.

You cannot use P as a parameter (as P is already used to reference the gcode file that is being called by M98)
When using a macro as custom gcode, do not use G, M, N, or T as parameters in a custom 'G' gcode file. Do not use G, M, or N as parameter in a custom 'M' gcode file. There are no standard G or M commands that use these parameters and RRF will treat the parameter as being the start of the next command.

pfn

@OwenD This is only true, about not being able to use T, if there is a behavior change (undocumented) from 3.4 to 3.5

According to your posted quotation, T is only prohibited in custom 'G' code files (e.g. G123.g), and there is no prohibition on T in custom 'M' code files (i.e. completely valid in any of M123xyz.g). Additionally, it is not prohibited from general macros.

But it does sound plausible that the move to multi-stream processing might have a bug around honoring these rules.

OwenD

@pfn
You are correct.
I just tried it and T is allowed in M98 (and works fine).