Conditional gcode help required - New Problem

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

deckingman

@OwenD Thanks -

I don't know if it helps but actually I get one error for every tool that exists. The tools are always sequentially numbered, so for example if I have 11 tools numbered from 0 to 10, then I get 11 error messages.

And as I said, running an almost identical macro at the start of a print to set the tool temperatures to (say) 210, always works. But I'll add the delays and an else section and see what happens.

dc42

Ian, does this issue only occur when you call that macro from within end.g, or can you reproduce it in any other way?

deckingman

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

Ian, does this issue only occur when you call that macro from within end.g, or can you reproduce it in any other way?

Unfortunately, it isn't as clear cut as that. I've just spent the last couple of hours trying to provoke it to misbehave. It seems the only time it will misbehave is at the end of a print. But running the post print macro on it's own (which in turn calls the tool temps macro), does not make it misbehave.

To recap, the macro which provokes errors (at the end of a print) is this:

  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 called from within this macro which is called "PostPrint.g":


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

I can run that "PostPrint" macro any time and it runs without errors. Yet when it is called from the end of a print, I get the "iterations used when not inside a loop" errors (11 of them - 1 for each tool)

When I get the errors, I can send M98 P"PostPrint.g" and it will run without errors.

This is the end of a gcode file that I've just finished

G1 X107.377 Y142.526 E0.05564
G10 ; retract
M107
; Filament-specific end gcode 
;END gcode for filament
;end
; Filament-specific end gcode 
;END gcode for filament
; Filament-specific end gcode 
;END gcode for filament
; Filament-specific end gcode 
;END gcode for filament
; Filament-specific end gcode 
;END gcode for filament
; Filament-specific end gcode 
;END gcode for filament
; Filament-specific end gcode 
;END gcode for filament
; Filament-specific end gcode 
;END gcode for filament
; Filament-specific end gcode 
;END gcode for filament
; Filament-specific end gcode 
;END gcode for filament
; Filament-specific end gcode 
;END gcode for filament
;end
M98 P"0:/macros/PostPrint.g"
; filament used = 17028.6mm (41.0cm3)
; total filament cost = 0.0
.........lots more comments after this

Could those filament specific comments that the slicer puts in before the M98 macro call screw things up?

I've tried running the last gcode commands in order - i.e. G10 followed by M107 followed by the M98 P... but that does not provoke the errors.

Weird or what?

A Former User

can you upload a sample print file along with the config? stuck in the countryside for a rainy weekend, never know, might find the time to poke it

deckingman

@bearer Thanks. I've sent you a chat message with shareable link to a folder that I have created on my Google Drive, which contains what I think are all the relevant files.

deckingman

OK. So by a process of elimination, I have found the reason (but not the cause) for the errors and a work around. I created a gcode file with simply the start part and the end part of a print file which provokes the problem. That is to say, with all the G1 moves removed. Running that did provoke the problem. Then I progressively removed various commands until I ended with simply this:

M98 P"0:/macros/PrePrintPETG.g"

;G21 ; set units to millimeters
;G90 ; use absolute coordinates
;M83 ; use relative distances for e
M107

M98 P"0:/macros/PostPrint.g"

..........and that will provoke the problem when run as a print file. Yet running those commands "stand alone" via the console does not provoke the problem - it has to be done as a print from the sd card.

The work around is to put M400 before that second "post print" macro (or indeed at the start of that macro before the call to the second "tool temps" macro).

If that's how it has to be, that's fine by me, but I suggest it be documented somewhere so as to help others in the future.

HTH

dc42

Thanks, that will make it easier for me to track down.

deckingman

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

Thanks, that will make it easier for me to track down.

No worries. I have those macros in a folder on my google drive so I can send you a shareable link if you want to replicate things exactly.

dc42

Thanks, I've reproduced the fault using those files, and I'm looking into it.

dc42

I've worked out what's going on. The G10 command would normally be synchronised to the movement queue. If there are movements not yet complete, it is put in the deferred execution queue. When it is retrieved from that queue, the "iterations" context has been lost.

I think the solution will be to substitute for all { } parameters when copying the GCode command to the deferred execution queue.