Conditional gcode help required - New Problem

deckingman

Can I use something like this

After the echo "setting temp for tool"

if G10 P{iterations} S >0
(indented) G10 P{iterations} S210 R210
(not indented) G10 P{iterations} S0 R0

Does that work as an "else"?

A Former User

@deckingman said in Conditional gcode help required:

Does that work as an "else"?

no else needs to be explicit; without it it will revert the changes on every run immediately as the last line will always execute.

you're on the right track, but have to access the object model instead of the G10 g-code.

something like

if tools[#tools].activeTemp > 0
  ;set the temp to 0
else
  ;set the temp to 210

I'm not sure about the correct object model node, but will try to poke it some more later, stepping out for a bit now that the sun is no longer scorching everything in an instant.. (and deliberately testing the last tool as it will be defined, the first might not)

OwenD

@bearer
if tools[#tools].activeTemp > 0

should be

if tools[#tools-1].activeTemp > 0

Tools array starts at zero, whereas number of tools starts at 1

A Former User

to poke the object model you can user M409 it will print out the top level object model in a flat JSON string, use something like https://jsonformatter.org/ to make it more readable.

M409 shows the tool object, and you can dig further with M409 K"tools" which return an array of tool objects, M409 K"tools[19]" will return the last tool object. (The returned JSON string will have the actual object model inside the result object - for for M409 K"tools[19]" you should have result.active[0] for the active temp, but the object model will not use the result as part of the path, but it will need the tools[19] as part of the path giving you tools[19].active[0]. (why active is an single element array idk so this may break in wonderful and unexpected ways)

I now see your thinking was to look at each individual tool inside the loop, but my thinking was to look at the last tool and have two loops - subtle difference. Not sure if either is better, depends a little on wheather or not all tools will be in the same state.

taking

if G10 P{iterations} S >0
  G10 P{iterations} S210 R210
G10 P{iterations} S0 R0

and inserting into

;/macros/tool.g
echo "Running toosl.g"
while iterations < #tools
  if tools[iterations] != null
    echo "Setting temp for tool T", iterations
    G10 P{iterations} S1 R0 ; - set it's active and standby temperature
echo "done"

you get

;/macros/toggletools.g - toggles stand by temps for all tools.
echo "Running toggletools.g"
while iterations < #tools
  if tools[iterations] != null
    if tools[iterations].active[0] > 0
      echo "Turning off tool T", iterations
      G10 P{iterations} S0 R0
    else
      echo "Turning on tool T", iterations
      G10 P{iterations} S210 R210
echo "done"

edit looking back there was something amiss with tools[#tools-1] so worked out well to go with your approach and a single loop avoiding tools[#tools-1]

deckingman

@bearer Thanks very much for putting the time into this, and also thanks for the lessons.

Having slept on it and thought about it some more, I can foresee a few scenarios where having a single "toggle" macro could be problematic. I'm often "tinkering" and even my home Z will pre-heat the nozzle. So it is likely that sooner or later, the active temperature might be other than zero when the macro is called but the intention is to set the tools to print temperature. If the active temperature is non zero, then the tool(s) will be set to zero which would be the opposite of what is intended. For that reason I think it will be safer to use two separate macros, one which will explicitly set the temperatures to print temperature, and the other to set them to zero.

But thanks again for showing me how to do it. I'm sure that knowledge will be useful in the future.

And thanks also to @OwenD for your contribution.

Edit - I've changed the title to show (in an unconventional way) that this is solved.

arhi

@deckingman said in Conditional gcode help required:

With a multi-input mixing hot end, one defines tools (colours) by using combinations of extruders and then setting mixing ratios for those extruders. But having a large number of tools defined at once, takes up too much space on the web interface. I haven't yet worked out the best way to deal with that but one option would be to have a "palette" of 50 tools but only use a selection of that full palette defined at any one time.

I think that when version with support for variables come up this should be easier. In theory (we'll see whent he variable support is out) you could have something like a config variable that you set in the config.g header and then you have each tool defined in it's separate .g file and then according to that variable you call the specific number of g-code files... and since it all works in runtime with RRF you could have your slicer startup file do something like:

$bt={bed_temperature}                ; copy bed temp from slicer to $bt variable
$ht={hotend0_temperature}            ; copy hotend temp from slicer to $ht variable
$htsb={hotend0_standbytemperature}   ; set standby temperature for hotend to $htsb

$tool_combination=7                  ; Use specific set of configured tools
M98 P"start_print.g"                 ; call start_print.g macro

and then in start_print.g you have something like

if $tool_combination == 0
  M98 P"configure_tool_1.g"
  M98 P"configure_tool_4.g"
  M98 P"configure_tool_5.g"
else if $tool_combination == 1
  M98 P"configure_tool_1.g"
  M98 P"configure_tool_2.g"
  M98 P"configure_tool_3.g"
else if $tool_combination == 2
  M98 P"configure_tool_4.g"
  M98 P"configure_tool_8.g"
else if $tool_combination == 3
  M98 P"configure_tool_4.g"
  M98 P"configure_tool_5.g"
  M98 P"configure_tool_6.g"
  M98 P"configure_tool_7.g"
...
else if $tool_combination == 30
  M98 P"configure_tool_14.g"
  M98 P"configure_tool_15.g"
  M98 P"configure_tool_20.g"
else
  abort "You did not set valid tool_combination value"

M200 D0 ; do not use volumetric extrusion
M83 ; relative extruder

; heat up

; heat up bed first
M140 S{$bt}
M190 S{$bt}

; heat up extruder
while iterations < #tools
  if tools[iterations] != null
    if tools[iterations].active[0] > 0
      echo "Turning off tool T", iterations
      G10 P{iterations} S0 R0
    else
      echo "Turning on tool T", iterations
      G10 P{iterations} S{$ht} R{$htsb}

; do not home if already homed
if !move.axes[0].homed || !move.axes[1].homed || !move.axes[2].homed
  G28

M98 P"wipe.g" ; do the wipe 
G29S1 ; use MESH compensation
M913 X100 Y100 Z100 ; all currents to 100%
M290 R0 S0 ; reset baby steps
; reset speed overrides
M221 S100
M220 S100 

; Dynamic Acceleration Adjustment
; M593 Fxxx

; Pressure Advance
M572 D0 S0.03


; ...

in theory, this start_print.g can be something you call before number of other operations as it will reconfigure your tools based on the input variable ...

in any case, variables should come with 3.2 and if I understood dc42 properly they are now testing new batch of toolboard they got from the supplier so question is when will this come around and how will the variables work... but I believe you understand the basic idea

deckingman

@arhi Yes, I had been thinking along those lines myself. Essentially taking the tool definitions out of config.g and putting them in one or more macros.

For info, I already use pre-and post print macros which take care of the everything from heating the bed to homing and purging (as well as setting tool temperatures which will now be done by calling this new macro). That's mostly because it gives me better control over the order that things happen. For example, I pre-heat the bed to around 40 and wait. Once it reaches 40 I set the bed to (say) 55 but don't wait and commence homing and all the other stuff. The net result is that homing, heating tools, and purging all happen within the time it takes for the bed to reach temperature, but not too soon before to minimise the time that the hot end is at print temperature before printing starts.

OwenD

@bearer said in Conditional gcode help required - SOLVED:

edit looking back there was something amiss with tools[#tools-1] so worked out well to go with your approach and a single loop avoiding tools[#tools-1]

My bad.
Should have been tools[(#tools-1)]

The equation must be in braces

A Former User

@OwenD said in Conditional gcode help required - SOLVED:

braces

dammit, i only tried curly braces. noted

edit: interesting:

6/18/2020, 11:43:48 AM	M409 K"tools[19]"
{"key":"tools[19]","flags":"","result":{"active":[0],"axes":[[0],[1]],"extruders":[0,1,2,3,4],"fans":[0],"filamentExtruder":-1,"heaters":[1],"mix":[10.00,0,0,0,0],"name":"All6","number":19,"offsets":[0,0,0],"offsetsProbed":0,"retraction":{"extraRestart":0,"length":2.0,"speed":16.7,"unretractSpeed":16.7,"zHop":0},"standby":[0],"state":"off"}}
6/18/2020, 11:43:35 AM	M409 K"tools[(#tools-1)]"
{"key":"tools[(#tools-1)]","flags":"","result":null}
6/18/2020, 11:39:30 AM	echo (#tools-1)
19
6/18/2020, 11:39:15 AM	echo {(#tools-1)}
6/18/2020, 11:39:04 AM	echo {#tools-1}
6/18/2020, 11:38:56 AM	echo {#tools}
20

deckingman

I now have a new problem which is frying my brain somewhat. I have this macro to set the tool temps to zero at the end of a print:

while iterations < #tools
if tools[iterations] != null
echo "Setting temp for tool T", iterations
G10 P{iterations} S0 R0 ; - set it's active and standby temperature

It is correctly indented - but this forum removes the indents when I do a copy and paste.

This macro works like a charm if I simply run it. But when I put inside my "Post-Print" macro I get a bunch of errors - "Error G10: 'iterations' used when not inside a loop". And of course the temperatures don't get changed. But I can run that macro "stand alone", immediately afterwards and it'll work just fine.

Here is my Post-Print Macro

;End print gcode

G10 ; retract
G91 ; set relative
G1 Z5 F240 ; move bed down 5mm
G90 ; back to absolute
G1 X165 Y300 F9000 ; move to rear

M98 P"0:/macros/ToolTemps/ToolTemps0.g" ; set the tool temperatures to 0

M140 S0 ; turn off bed
M106 S0 ; turn off part fan

M291 P"Print finished" R"Post-Print Macro" S1 T10

What is really frying my brain is that I do something very similar in a Pre-Print macro which calls another almost identical macro to set the tool temps to 210, and that works as expected.

For the sake of completeness, here is a "Pre-Print" macro which works as expected

; Pre-print gcode 45deg bed, 210 hot end

M291 P"Heating bed to 40 degC " R"Pre-Print PLA" S1 T10

M190 S40; start heating bed and wait for it to get to 40

M291 P"Homing all axes" R"Pre-Print PLA" S1 T10

M140 S45; Now start to heat bed to 45 but don't wait
M98 P"0:/macros/PrePrintHome.g" ; home all axes (at high temp)

M98 P"0:/macros/ToolTemps/ToolTemps210.g" ; set the tool temperatures to 210

G1 X80 Y363 F9000 ; move to rear
M83;

M291 P"Waiting for heaters to reach active temperatures" R"Pre-Print Macro" S1 T10

M116 ; wait for all temps including hot end

M291 P"Wiping nozzle" R"Pre-Print PLA" S1 T5
M98 P"0:/macros/Nozzle wipe"

So, I can't fathom why calling a macro to set the tool temps works from within a "pre-print" macro and also "stand alone" but calling it from within my post-print macro brings up errors.

dc42

@deckingman said in Conditional gcode help required - New Problem:

while iterations < #tools
if tools[iterations] != null
echo "Setting temp for tool T", iterations
G10 P{iterations} S0 R0 ; - set it's active and standby temperature

If you use code escapes (three back-quote characters at the start and end of the block) then it will preserve the indentation:

while iterations < #tools
  if tools[iterations] != null
  echo "Setting temp for tool T", iterations
  G10 P{iterations} S0 R0 ; - set it's active and standby temperature

Please either post the contents of the non-working macro in this way, or attach it as a file

arhi

@deckingman said in Conditional gcode help required - New Problem:

forum removes the indents

you can do it like this:

while iterations < #tools
  if tools[iterations] != null
    echo "Setting temp for tool T", iterations
  G10 P{iterations} S0 R0 ; - set it's active and standby temperature

or withot "type of the code" like this

while iterations < #tools
  if tools[iterations] != null
    echo "Setting temp for tool T", iterations
  G10 P{iterations} S0 R0 ; - set it's active and standby temperature

and if you want to quote it in-line you do it like this

arhi

looking at the code it should work as expected. better upload files directly as this "space formatting" can be the source of the problem

deckingman

OK. Thanks all for the info about preserving indentations.

By a process of elimination I have isolated what causes the error. It is the preceding Z move. That is is to say, if I comment out the two lines below so I have ..........

G10 ; retract
;G91 ; set relative
;G1 Z5 F240 ; move bed down 5mm
G90 ; back to absolute
G1 X165 Y300 F9000 ; move to rear

M98 P"0:/macros/ToolTemps/ToolTemps0.g" ; set the tool temperatures to 0

..............Then I get no errors and the macro runs just fine.

Or if I just re-arrange things so that the macro runs before the Z move, it works fine too. i.e. I now have.................

;End print gcode

G10 ; retract

M98 P"0:/macros/ToolTemps/ToolTemps0.g" ; set the tool temperatures to 0

G91 ; set relative
G1 Z5 F240 ; move bed down 5mm
G90 ; back to absolute
G1 X165 Y300 F9000 ; move to rear

M140 S0 ; turn off bed
M106 S0 ; turn off part fan

M291 P"Print finished" R"Post-Print Macro" S1 T10

........and this work fine. So it's either the preceding G91 switching to relative, or the G1 Z5 that breaks the conditional macro.

A Former User

@arhi said in Conditional gcode help required - New Problem:

and if you want to quote it in-line you do it like this

you can even escape things with \ like `quote it in-line` becomes quote it in-line and then you can go all inception to show \`quote it in-line\` and then you can...

edit: you can use double (as in two) quotes to avoid escaping single quotes (and three to escape two and so on..)
``single `quote` `` becomes single `quote`

deckingman

I spoke too soon. I just ran a print with the end gcode macro as per my last post above and received the errors "Error G10: 'iterations' used when not inside a loop". I ran that same post-print macro again, and it worked without errors on that second try.

So it's seemingly random. Some times it runs without error, other times I get those errors.

Here is the macro yet again:

while iterations < #tools
  if tools[iterations] != null
    echo "Setting temp for tool T", iterations
    G10 P{iterations} S0 R0 ; - set it's active and standby temperature

dc42

Can you confirm that you are running firmware 3.1.1 on the main board?

deckingman

@dc42 said in Conditional gcode help required - New Problem:

Can you confirm that you are running firmware 3.1.1 on the main board?

Yup

M122
=== Diagnostics ===
RepRapFirmware for Duet 3 MB6HC version 3.1.1 running on Duet 3 MB6HC v0.6 or 1.0 (standalone mode)

M122 B1
Diagnostics for board 1:
Board EXP3HC firmware 3.1.0 (2020-05-15b1)

Don't know if it makes any difference but all the extruders are connected to expansion boards 1 and 2 and the hot end heater and thermistor are on expansion board 1.

deckingman

Does nobody have any idea why that macro sometimes works and at other times throws up errors - "iterations used when not inside a loop". Interestingly, the other very similar macros which set the tool temperatures to high values and which are used at the start of a print always work. It's just this one which sets the temperature to zero at the end of a print.

Because it is erratic and unpredictable, I've had to go back to my old way of doing things and use a number of macros, each with a fixed but different number of G10 Pnn S0 R0 commands, rather than use the while loop. Otherwise, more often than not, the tools will all remain at print temperature when a print finishes which is highly undesirable.

OwenD

@deckingman
If it works sometimes and not others I suspect an unhandled exception. I.e. the firmware isn't getting what it expected.
It may help in diagnosing if you add a delay after the echo and add an "else" section to notify when a null value is being returned by your if statement (also with an echo and delay)
I'd also do a "finished" section for good measure.

I suspect if you don't have sequential numbering on the tools something may be going awry that you aren't seeing.

Those changes should help determine which "iteration" is giving the grief