Weird macro behaviour
-
@fcwilt said in Weird macro behaviour:
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.
-
@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
-
@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".
-
@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.
-
@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
-
@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!
-
My observations regarding macros:
M83 via console works.
Makros file containing one string M83 not working. -
@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
-
@gloomyandy
dunno that, thanks! -
-
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🤣
-
@exerqtor said in Weird macro behaviour:
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
-
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.
-
@exerqtor I've got a fix ready that will be part of the next 3.4.2-b1 version. dc42 has already merged it.
-
@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!
-