Weird macro behaviour

fcwilt

@exerqtor said in Weird macro behaviour:

I'm setting up bed leveling macro's and i'm starting up with the one that's going to be called when i start a print. But for some reason it jumps from line 40 to line 96 just skipping over everything in between those lines. And i can't figgure out what i've done wrong to make it behave like this.

Here is the macro(s) for those who got time to sift thru them:

print_level_bed.g
klicky_status.g

( I can include all the other macro's that getts called in "print_level_bed.g" but i can't see any need for them since everything stops working at line 40 / second time klicky_status.g gets called.)

Please get in the habit of copy-and-pasting files into the </> tag, one tag per file.

This will create a scrollable region right in your post so the rest of us don't have to download a file to view it.

Frederick

fcwilt

This post is deleted!

Exerqtor

@fcwilt said in Weird macro behaviour:

Please get in the habit of copy-and-pasting files into the </> tag, one tag per file.

This will create a scrollable region right in your post so the rest of us don't have to download a file to view it.

Didn't know that was the perfered way in larger files (esp when refering to line numbers), fixed now 👍

fcwilt

@exerqtor

Nothing jumps out at me.

When it happens to me I starting "sprinkling" my code with echo statements so I can track the progress of the code and see exactly where things go wonky.

And I have to remind myself to check the DWC Console which may list an error message giving a clue to what went wrong.

Frederick

Exerqtor

@fcwilt said in Weird macro behaviour:

@exerqtor

Nothing jumps out at me.

When it happens to me I starting "sprinkling" my code with echo statements so I can track the progress of the code and see exactly where things go wonky.

And I have to remind myself to check the DWC Console which may list an error message giving a clue to what went wrong.

Frederick

Yeah i've done that and confirmed that it goes past the klicky_load.g and it also runs the klicky_status.g after klicky_load (since it changes the global to attached when it's done), BUT if i throw a echo after klicky_status.g on line 40 it dont get called out, the next thing that happens is the "bed allready leveled" on line 96 i can't figgure out what the f is going on at this point.

fcwilt

@exerqtor said in Weird macro behaviour:

Yeah i've done that and confirmed that it goes past the klicky_load.g and it also runs the klicky_status.g after klicky_load (since it changes the global to attached when it's done), BUT if i throw a echo after klicky_status.g on line 40 it dont get called out, the next thing that happens is the "bed allready leveled" on line 96 i can't figgure out what the f is going on at this point.

OK let me take a closer look.

JOOC, how many values can the global status variable have?

Frederick

deckingman

@exerqtor Is it possible that sensors.probes[0].value could be something other than 0 or 1000? I'm not seeing anything that could catch that which would mean that the global.klicky_status would not be set to "attached" nor "docked".

Exerqtor

@deckingman Nope, it's a simple on/off microswitch so it can't output anything else.

Changing the global variable two times in a short amout of time shouldn't have anything to say either should it? I'll uncomment the status refresh before klicky_load.g tomorrow to see if that changes anything.

fcwilt

@exerqtor said in Weird macro behaviour:

@deckingman Nope, it's a simple on/off microswitch so it can't output anything else.

Changing the global variable two times in a short amout of time shouldn't have anything to say either should it? I'll uncomment the status refresh before klicky_load.g tomorrow to see if that changes anything.

No that should not have an effect... except I did read about a problem in 3.4.1, with one macro calling another... now what was the work around... I don't remember.

Perhaps you can find those posts.

Frederick

Exerqtor

@fcwilt said in Weird macro behaviour:

except I did read about a problem in 3.4.1, with one macro calling another... now what was the work around... I don't remember.

Perhaps you can find those posts.

Oh you did? Haven't seen that mentioned yet, i'll try to find it!

EDIT: Is this the thread you were refering to @fcwilt?

Del87

My observations regarding macros:

M83 via console works.
Makros file containing one string M83 not working.

gloomyandy

@del87 When a macro is run some settings are saved and restored I'm pretty sure that the extruder absolute/relative mode is one of them, so M83 in a macro may appear to do nothing. See: https://docs.duet3d.com/en/User_manual/Tuning/Macros_tasks#running-macros

Del87

@gloomyandy
dunno that, thanks!

fcwilt

@exerqtor said in Weird macro behaviour:

EDIT: Is this the thread you were refering to @fcwilt?

Yes - you found it.

Frederick

Exerqtor

@fcwilt

Adding echo "" at the end of the nested macros did the charm, thanks for the heads up on that one!. Lets hope @chrishamm finds a fix for it soon 🤣

fcwilt

@exerqtor said in Weird macro behaviour:

@fcwilt

Adding echo "" at the end of the nested macros did the charm, thanks for the heads up on that one!. Lets hope @chrishamm finds a fix for it soon 🤣

Glad to hear it is now working for you.

Frederick

mikeabuilder

Glad it's working, but I'll toss in couple of comments.

The comment - Per @deckingman comment, I think it's good coding practice to check probe values with a ">X" vs "=Y".

Another comment - I don't see an initialization for global.klicky_status. If it was not initialized, you should have seen an error in the console or log file. Adding an "else with a message stating klicky status is not defined and an abort would be nice, that way you've covered all options for global.klicky_status. Even better would be a third return value for gloabl.klicky_status in klicky_status.g. on Line 12 add an else set global.klicky_status = "invalid". Then you'd see if the value passed back to the main macro is neither 0 nor 1000.

My speculation is that if the variable was not initialized it might abort the "code block" that contains it, which might be the block starting on line 1and ending on line 90.

chrishamm

@exerqtor I've got a fix ready that will be part of the next 3.4.2-b1 version. dc42 has already merged it.

Exerqtor

@mikeabuilder said in Weird macro behaviour:

Glad it's working, but I'll toss in couple of comments.

The comment - Per @deckingman comment, I think it's good coding practice to check probe values with a ">X" vs "=Y".

Noted, then i guess this will taste better:

if sensors.probes[0].value[0] < 1
  set global.klicky_status = "attached"
elif sensors.probes[0].value[0] > 999
  set global.klicky_status = "docked"
echo ""

Another comment - I don't see an initialization for global.klicky_status. If it was not initialized, you should have seen an error in the console or log file.

global.klicky_status get's initialized along with all my other globas thru a macro named "globals.g", "globals.g" on it's side gets called by "init.g" as one of the last steps in my "config.g".
end of "config.g"

; Miscellaneous
M950 P0 C"out2"	                                                               ; create output Port0 attached to out2 connector for LED lights 
M911 S10 R11 P"M913 X0 Y0 G91 M83 G1 Z3 E-5 F1000"                             ; set voltage thresholds and actions to run on power loss
M572 D0 S0.0                                                                   ; Disable Pressure Advance
M98 P"/sys/lib/init.g"                                                         ; iniate external configs
M501                                                                           ; load config-override.g
T0                                                                             ; select tool 0

"init.g":

; /sys/lib/init.g
; Called in the end of config.g
; Used to setup more stuff

M98 P"/sys/lib/globals.g"                                                      ; setup global variables
M98 P"/sys/lib/speed/speed_printing.g"                                         ; set normal speed & accel
M98 P"/sys/lib/current/xy_current_high.g"                                      ; set normal xy currents
M98 P"/sys/lib/current/z_current_high.g"                                       ; set normal z currents
M98 P"/sys/lib/fw_retraction.g"                                                ; set firmware retraction settings

"globals.g"

; /sys/lib/globals.g
; Called by init.g
; Used to initialize global variables

; global declarations and defaults

; ====================---------------------------------------------------------
; temperature
; ====================

if !exists(global.bed_temp)
  global bed_temp = 0

if !exists(global.hotend_temp)
  global hotend_temp = 0

if !exists(global.chamber_temp)	
  global chamber_temp = 0

; ====================---------------------------------------------------------
; stepper currents
; ====================

if !exists(global.xy_current)	
  global xy_current = move.axes[0].current

if !exists(global.z_current)	
  global z_current = move.axes[2].current

if !exists(global.e_current)	
  global e_current = move.extruders[0].current

; ====================---------------------------------------------------------
; mechanical Z pin
; ====================

if !exists(global.zpinx)
  global zpinx = 194.5

if !exists(global.zpiny)
  global zpiny = 355

; ====================---------------------------------------------------------
; klicky probe
; ====================

; the distance from the body of the klicky probe to it's own trigger point
if !exists(global.klickyoffset)
  global klickyoffset = 0.23  ; a larger values makes the nozzle closer to the bed after running autoz

; the absolute X location of the klicky while docked
if !exists(global.klickydockx)
  global klickydockx = 18.6

; the absolute Y location of the klickywhile docked
if !exists(global.klickydocky)
  global klickydocky = 357.3

; the relative disance and direction of the klicky docking move	
if !exists(global.klickywipe)
  global klickywipe = 30  ; -30 for a left wipe 30 for a right wipe

if !exists(global.klicky_status)
  global klicky_status = "none"

; ====================---------------------------------------------------------
; bed
; ====================

; define the bed size (print area from 0 to X and Y max)
if !exists(global.bedx)
  global bedx = 350

if !exists(global.bedy)
  global bedy = 350

; ====================---------------------------------------------------------
; misc
; ====================

if !exists(global.initial_extruder)
  global initial_extruder = 0

if !exists(global.bed_leveled)
  global bed_leveled = false

if !exists(global.job_completion)
  global job_completion = 0

if !exists(global.debug_mode)
  global debug_mode = true

; ====================---------------------------------------------------------
; output current values
; ====================

;echo "global.bed_temp defined. Value : " , global.bed_temp
;echo "global.hotend_temp defined. Value : " , global.hotend_temp
;echo "global.chamber_temp defined. Value : " , global.chamber_temp
echo "global.klicky_status defined. Value : " , global.klicky_status
echo "global.bed_leveled. Value : " , global.bed_leveled
echo "global.job_completion defined. Value : " , global.job_completion
echo "global.debug_mode defined. Value : " , global.debug_mode

Adding an "else with a message stating klicky status is not defined and an abort would be nice, that way you've covered all options for global.klicky_status. Even better would be a third return value for gloabl.klicky_status in klicky_status.g. on Line 12 add an else set global.klicky_status = "invalid". Then you'd see if the value passed back to the main macro is neither 0 nor 1000.

Agreed on that, an else condition that resulted in "invalid" the result was anything between 1 too 999 would fix that with an abort. But i can't figgure out how to construct that, for instance

if sensors.probes[0].value[0] < 1
  set global.klicky_status = "attached"
elif sensors.probes[0].value[0] > 999
  set global.klicky_status = "docked"
else sensors.probes[0].value[0] = {what to but here to check if the value is between 1 and 999?}
  set global.klicky_status = "invalid"
  echo "Klicky status invalid - aborting"
  abort
echo ""

Or just go the easy route with

if sensors.probes[0].value[0] < 1
  set global.klicky_status = "attached"
elif sensors.probes[0].value[0] > 999
  set global.klicky_status = "docked"
else
  set global.klicky_status = "invalid"
  echo "Klicky status invalid - aborting"
  abort
echo ""

My speculation is that if the variable was not initialized it might abort the "code block" that contains it, which might be the block starting on line 1and ending on line 90.

Turns out the premature ending was a bug in DWC, so it wasn't my fault this time lol.

@chrishamm said in Weird macro behaviour:

@exerqtor I've got a fix ready that will be part of the next 3.4.2-b1 version. dc42 has already merged it.

Sweet, hope that beta see the light of day pretty soon!