Posts made by mikeabuilder

RRF 3.6.0-rc.2
MB6HC

I've created a print job designed to help me tweak my z offset. It's a single layer rectangle with some added meta commands to let me position it anywhere on the bed. It works great. It's called "first layer.gcode"

I've also written a macro utility to assist in changing filaments. it also works great.

Now I want to let the user start tart the print job at the end of the filament changing macro, but I'm not sure how to do this. I tried M98 P"0:/gcodes/first layer.gcode". This does launch the job, but it does not run start.g at the beginning or enable the pause and cancel buttons in DWC. Is there a proper way to do this? I know I can add a conditional call of start.g and stop.g in first_layer.gcode, but I want to have access to the pause and cancel print buttons.

@dc42 - Following up on this issue. I've implemented trace logging through all my macros and yesterday I had another incidence of the same issue that started me looking at debouncing on PanelDu. The symptom is that I get this Error in my event log:
2025-04-29 10:25:15 [warn] Error: Push(): stack overflow on Aux

I still suspect multiple starts on one attempted PanelDu touch (fingernail only), but there are a couple of odd things I'm hoping to understand.

The macro called from the PanelDu touch is 0:/macros/Load or Unload Filament.g and I post a message via M118 at the beginning of the macro. Then the macro asks the user to select whether to Load, Unload, or Cancel, using
M291 S4 T0 P"FILAMENT - Load, Unload, or Cancel" K{"Load", "Unload", "Cancel"}

Here is the event log just before the error. You can see that the macro is starting multiple times and the M291 is being logged each time. After these n=messages, the M292 acks are logged. If the user replies to the M291 with "unload", then another macro ( 0:/macros/load_unload_filaments/unload_current_filament.g) is called. Thar macro has a start message then posts a message with the current tool and filament. Then my stack overflow happens.

2025-04-29 10:24:47 [info] starting 0:/macros/Load or Unload Flament.g
2025-04-29 10:24:47 [info] M291: - [no title] - FILAMENT  -  Load, Unload, or Cancel
2025-04-29 10:24:49 [info] starting 0:/macros/Load or Unload Flament.g
2025-04-29 10:24:49 [info] M291: - [no title] - FILAMENT  -  Load, Unload, or Cancel
2025-04-29 10:24:49 [info] starting 0:/macros/Load or Unload Flament.g
2025-04-29 10:24:49 [info] M291: - [no title] - FILAMENT  -  Load, Unload, or Cancel
2025-04-29 10:24:50 [info] starting 0:/macros/Load or Unload Flament.g
2025-04-29 10:24:50 [info] M291: - [no title] - FILAMENT  -  Load, Unload, or Cancel
2025-04-29 10:24:51 [info] starting 0:/macros/Load or Unload Flament.g
2025-04-29 10:24:51 [info] M291: - [no title] - FILAMENT  -  Load, Unload, or Cancel
2025-04-29 10:24:53 [info] M292: cancelled=false shouldAbort=true
2025-04-29 10:25:00 [info] M292: cancelled=false shouldAbort=true
2025-04-29 10:25:03 [info] M292: cancelled=false shouldAbort=true
2025-04-29 10:25:10 [info] M292: cancelled=false shouldAbort=true
2025-04-29 10:25:15 [info] M292: cancelled=false shouldAbort=true
2025-04-29 10:25:15 [info] starting 0:/macros/load_unload_filaments/unload_current_filament.g
2025-04-29 10:25:15 [info] M291: - [no title] - Current Tool Number: 1      Current filament: PLA
2025-04-29 10:25:15 [warn] Error: Push(): stack overflow on Aux
2025-04-29 10:25:20 [info] M292: cancelled=false shouldAbort=true

One question I had is "which of the M291's in the 5 macro starts was responded to by the user?" The T0 parameter on the M291 means it will not time out, but I do not think this makes it blocking. So each of the first 4 M291 messages is lost. Are those macro starts left at a paused execution state? Are they taking up "open file" slots and pushing me towards my stack overflow?
Is there a an easy (meaning via object model or gcode) for me to see how many files are open?

My trace data (below) confirms that the last of the 5 repeated opens is the one that was responded to. In my tracing, at the start of every macro, a global variable is incremented and that number assigned as the trace-number for that instance of that file being run. I also log the start time of the macro and these correspond to the times in even log. And on line 6, you can see that the trace number 225 (the last instance of "load or unload Filament") is logging that it's calling the next macro.

221 , 2025-04-29T10:24:47 , 2522 , 0:/macros/load_unload_filaments/Load or Unload Filament.g , Starting Macro
222 , 2025-04-29T10:24:49 , 2524 , 0:/macros/load_unload_filaments/Load or Unload Filament.g , Starting Macro
223 , 2025-04-29T10:24:49 , 2524 , 0:/macros/load_unload_filaments/Load or Unload Filament.g , Starting Macro
224 , 2025-04-29T10:24:50 , 2524 , 0:/macros/load_unload_filaments/Load or Unload Filament.g , Starting Macro
225 , 2025-04-29T10:24:51 , 2525 , 0:/macros/load_unload_filaments/Load or Unload Filament.g , Starting Macro
225 , 2025-04-29T10:25:15 , 2550 , 0:/macros/load_unload_filaments/Load or Unload Filament.g , About to call: 0:/macros/load_unload_filaments/unload_current_filament.g
    226 , 2025-04-29T10:25:15 , 2550 , 0:/macros/macros/load_unload_filaments/unload_current_filament.g , Starting Macro

So, as we used to say, "a lotta crap to read, what do we do?" I'm writing a debouncer into the start of the macro to not let it start too quickly after the last time it started. I'm picking 5 seconds.

Does all my analysis and plan seem reasonable?

I don't think these are needed, but here's my M122 output (m122 output.txt ), my full trace (trace_12.txt ) and the load and unload filament macro (pre start time debouncer) (Load or Unload Filament.g )

@chrishamm - thanks for the response and the github pointer. I took a look at the description and see it's just the same as what I found. Some of the description is beyond my knowledge, but it's good to know I'm only 2 years behind the leading engineers in finding things.

My Bad. I should have included my HW info.

1. Display device is DWC. I also have a PanelDue 7i on this machine, and I just tested launching the macro from it. When I do, only my echo messages appear on the PanelDue console, none of the M292 messages.

2. Duet board is MB6HC and is stand alone.

3. RRF and DWC are both 3.6.0-rc.2

Not sure if this is a bug, or undocumented behavior, or something new for me to understand.

I'm writing a macro where the user is asked for a lot of input via M219 commands. All is working well. The last line of my macro echos a macro-finished message. On the console, An M292 message is printed along with my exit message for every M291 that was used. I'm not sure why all these messages should be going to the console only if a future echo command is issued.

I've stripped down my macro and did some testing and it appears that there are M292 messages "buffered" and on the next echo command in the macro, they all get sent to the console.

Here's my repro case, and console output.

echo "start echo test"
M291 S4 K{"2", "5", "20", "50", "100", "Done"} T0 P"Select radius to include."
M291 S4 K{"20", "50", "100", "200", "300", "500", "Done"} T0 P"Select speeds to include.  300 is printer default"
M291 S4 K{"500", "1000", "5000", "10000", "Done"} T0 P"Select accelerations to include.  10000 or 1000 is printer default"

echo "middle of test"

M291 S4 K{"1", "10", "25", "50", "Done"} T0 P"Select jerk value to include.  10 or 25 is printer default"
M291 S4 K{"8", "16", "32", "64", "128", "256",  "Done"} T0 P"Select micro_steps value to include.  16 is printer default"
M291 S4 K{"2200", "1800", "1200", "800", "Done"} T0 P"Select max motor_current value to include.  2200 is printer default"
echo "end of echo test

4/28/2025, 8:28:07 AM 	M292 R{1} S144
                        end of echo test
4/28/2025, 8:28:07 AM 	M292 R{4} S143
                        end of echo test
4/28/2025, 8:28:07 AM 	M292 R{2} S142
                        end of echo test
4/28/2025, 8:28:04 AM 	M292 R{1} S141
                        middle of test
4/28/2025, 8:28:04 AM 	M292 R{2} S140
                        middle of test
4/28/2025, 8:28:04 AM 	M292 R{3} S139
                        middle of test
4/28/2025, 8:28:00 AM 	M98 P"0:/macros/data/echo_test.g"
                        start echo test

@dc42 - thanks for explaining that. In my use case, I was building an array to fill in later with numbers and was using text as a placeholder when I created the array. I switched to null as my placeholder and now it works great.

HW - DUet3 6HC
RRF 3.6.0-rc.2

I'm getting a little bit fancy developing a macro to help me run some tests on my printer. I've just run into a situation where I the boolean-expression in an IF statement that is evaluating whether a string is equal to an integer. For example:

if "some_string"  =  1

I expected this to evaluate to false - a string can never equal a number. But I get an error message:

Error: in file macro line 1 column 14: meta command: cannot convert operands to same type

If my assumption is bad about this expression evaluating to false, then maybe the meta command doc should say something about this.

I'm mostly through instrumenting all my code to enable tracing the opening and closing of macros. I have a couple of follow up questions for @dc42

The first question is regarding the error message: Error: Max open file count exceeded. What does this refer to, and what is the open file limit? My guess is the total number of open nested macros. A google AI response tells me the limit is 20, and if so this may be the source of my printer hang. I do a lot of redirection of files (maybe too much) during tool changes and when my problem happened, a user was also trying to start other macros from the touch-screen.

My second question is about M292. I see that the S parameter is the message sequence, and I wonder if there is a limit on it's value. I also send a lot of messages (also maybe too many) during tool changes and I wonder if during the course of a lot of tool changes I might hit this limit.

@dc42 - My home machine has a duet3 6HC board and is running RRF 3.6.0-rc.2 I made a quick test macros to help me understand the J2 option. I think I found a documentation error on the M291 Page.

In my testing, not using S4 without the J2 option is blocking, and any T parameter is ignored. If I use this method, I need to name a button "Cancel", then evaluate the input variable to see if the cancel button was pressed.

M291 S4 K{"button 0","button 1"} T1 P"test message" 
echo "returned input", input
echo "returned result", result

With the J2 parameter, I can set a timeout. I evaluate the Result variable to see if either the cancel button was pressed or a timeout occurred.

With no T parameter the message is blocking

M291 S4 K{"button 0","button 1"}  P"test message" J2
echo "returned input", input
echo "returned result", result

According to my reading of the M291 Doc page description of the T parameter "A zero or negative value means that the message does not time out (it may still be cancelled by the user if it has a Cancel button)"

When I tested this, T0 behaves as expected (blocking) but with a negative value for T, I get an error message.

M291 S4 K{"button 0","button 1"} T-1  P"test message" J2
echo "returned input", input
echo "returned result", result

Error: in file macro line 1 column 35: M291: value must be not less than zero
result 2
returned input null

Nice! Upgrading RRF has been on our list and so now it's moved to the top.

Thanks. I'll see if @dc42 has some trick... but I've also been thinking about the relative effort of

• Adding my trace code to existing M291 S3 commands, plus adding whatever trick might exist.
• Swapping M291 S2 for M291 S4 and using my existing bread crumbs.

The M291 swap replaces 1 line of code with three lines (the M291, plus an if statement, and an M99 (to cancel).

Any trickiness to retain the M291S3 would almost certainly require more than that.

In both cases, there is the search for M291 in multiple files and add the breadcrumb code (two lines). And this is maybe the biggest effort.

So I'll amend my request for a tricky solution to include - "only if it's dead-simple"

@Phaedrux - follow up question. I'm in the midst of implementing my trace-macros thing and I've added a couple of additional placed where my macros might branch (and so I need to leave a breadcrumb) - calling a gcode that calls a macro - things like G32, M701, M703, M0, etc. I think I've got those covered.

My questions regards M291 S3 messages. One of the possible responses "cancels the operation in progress". This means it stops running the macro where the M291 is located. This is an exit point for the macro and I can't think of a way to capture that so I can write an entry in my trace_log.

The only thing I can think of is rewriting all my M291 S3 uses to M291 S4 and making my own OK and Cancel buttons.

Any clever options I'm not thinking of?

@Phaedrux - unfortunately I don't have the M122. If I get another case of it I'll grab an M122.

I also read in a couple of old posts reporting a similar issue that a likely cause is a recursive connection withing the macros. I have a lot of macros on the system - close to 40, so posting all my code for someone else to look is not reasonable. and trying to inspect the code seems easy to miss something.

So my plan is to log threads through all my macros. I'm thinking I'll make a global variable global.call_number I'll increment it every time I start a macro and long into a special file:
time stamp, global.call_number, macro name, "starting"

Then if a macro is about to use an M98, I'll log again
time stamp, global.call_number, macro name, "About run M98 P"next macro"

And when the M98 returns, I log
time stamp, global.call_number, macro name, "Returned from M98 P"next macro"

And finally, when the macro exits
time stamp, global.call_number, macro name, "Exiting"

This should let me watch the execution thread through all my macros and hopefully help me spot any recursions.

I had a printer failure last week with several consequences and I finally got to looking in the eventlog. There are two several log entries that occurred with the printer failure and I'm hoping someone can help me understand them.

HW - Duet2 WIFI
RRF - 3.5

Error: Max open file count exceeded.
Warning: Macro file check_limit_violations.g not found
Error: Push(): stack overflow on Aux

I suspect the first error is an indication that too many macro files are "in play"> I use that term because I think it might be a count of nested macros has been exceeded, but might the count include macro's that are queued?

The second error is a mystery to my but I expect it's a consequence of the first.

Also, the troubling behaviors I noticed in my system seemed to be caused because some tool change macros were not being run. The warning is an example of one of these.

I suspect I caused the initial problem with a macro that was queued too many times and I have a fix for this.
But it seems that when this set of errors started, the machine fw skipped execution of some macros (or maybe parts of macros) and I wonder if it would be better if operation is halted when one of these errors occurs. If there are good reasons to want to continue operation after one of these kinds of errors, maybe there is some flag I can set in config.g or a print file to force a halt on error?

@dc42 - thanks for the info. Leaning on the button is certainly a possibility here.

I was curious about how fast a macro could repeat so I did a quick test with a macro that appends state.upTime to a file, then kept my finger on the touch screen button. I got 10 entries per second, so I'll assume the touch does a 100msec debounce - or that's the round trip time to read and execute the macro.

Then I wrote a macro with my logic above and again held down the macro button. I proved to myself that the slow-finger would end up with the macro queued multiple times, not run simultaneously. Nothing surprising to you, but I'm happy to prove it to myself.

To avoid my problem of the slow-finger, I now have a global variable holding state.upTime that I set when the macro ends. At the start of the macro, I test whether the current upTime is "long enough" after the saved upTime (I picked 5 seconds for my case), and only proceed with the rest of the macro if it's been long enough.

I have a clone PanelDu 7
connected to a Duet2 wifi
running RRF 3.5

I'm having occasions where it seems like I'm getting multiple instances of a macro running on a single intended touch of the screen. It's like the touch property is not getting de-bounced. I've only noticed on macros I've written but I haven't tried to test other buttons.

I have a couple of questions.

1. Is there any user control of de-bouncing that happens with PanelDu touches? I assume PanelDu uses sw de-bouncing, not HW.

2. Are there any recommendations for de-bouncing in macro launches? I've been thinking I might test and set a global variable at the beginning of the macro (I'd create it at machine startup). Something like

if global.this_macro_already_running
  M99
set global.this_macro_already_running = true

; rest of macro

Then as the last command I'd set the value to false

set global.this_macro_already_running = false

What I don't understand is how multiple macros are queued and started in RRF. Is it possible that a second instance of the same macro initiated from PanelDu would either start before I get the global set from the first instance? And is it possible the second instance could start before the last command resets the variable in the object model? Should I insert a short pause (say 200msec) after the last command?

Or maybe there are other better ways to handle this?

I think you're on the right track with the G60 command. You don't provide any details of the trigger macros, so the rest of this post is just guessing on my part...

I assume you've read this page on setting up triggers: https://docs.duet3d.com/en/User_manual/Tuning/Triggers, and that you've set up the inputs for the two buttons using M950, and also defined triggers numbered 10 and 11 using M581. Also, you've got these commands in your config.g file so they'll be executed every time you start the machine.

The trigger10.g macro should need only one command.

;trigger10.g
G60 S3

When this macro runs it will save the current machine location into slot #3.

The trigger11.g macro should looks something like this:

;trigger11.g
G0  R3 X0 Y0 Z0

This commands a fast move to the stored S3 location without any offset in the X,Y,or Z positions stored in S3. If you don't have the X0 Y0 Z0 in your command, those axes won't be moved (it will look like nothing has happened when you push the second button).

An additional thing to consider in your trigger 11.g macro. If your "move to" button is pressed before the "save position" button, the default coordinates stored in slot S3 are 0,0,0 so you'll drive a move you might not want. If you are unlikely to ever save 0,0,0 with your "save location" button, you could write an IF statement into your trigger11.g macro to look at the current values saved in this slot and if they are all 0, you could do something like post a message and not make the move.

To test your trigger10.g macro without the buttons, you can send M98 P"trigger10.g" in the Web control window, then send echo state.restorePoints[3].coords to see the saved coordinates. You can also look at the object model plugin to see if the location has been stored. It will be in state > restorePoints >3

You can similarly test trigger11.g. After running trigger10, move the machine using the Web control then send M98 P"trigger11.g" in the Web control window. Your machine should move back to the stored position.

You can also test the inputs by looking at the inputs section of the object model while you press the buttons.

I agree with Ian (Dr-O'farts, I think it might be Irish). A loose grub screw will let the motor move a bit when it switches direction without moving the belt.

If you're going to print more tests, you could make an 8-sided box to enable looking at X-axis, Y-axis, and also each motor separately. You might also make that shape a "stepped pyramid" to be able to see if artifacts are starting at the corner (which might imply something to do with print head acceleration or extrusion speed). Your pictures posted on 16 Fed look like they have a very slight step at the bottom of the part, which gave me this idea.

Other thoughts after looking at the picture of the printer posted on 11 Feb...

Is there anything other than the shaft couplers preventing vertical motion of your Z lead screws? On my printer, I had some issues with z-banding and I switched from couplers like those you are using to the spring kind (which allows more Z movement). Then I put a screw collar (https://www.amazon.com/Shaft-Collar-Aluminum-Thickness-Screws/dp/B0BNZ937MV) on each z-shaft and put a thrust bearing (https://www.amazon.com/uxcell-F8-16M-Miniature-Bearings-8x16x5mm/dp/B07QLTXJDH) between that the the top of the lower bearing. Finally, I designed a spring loaded thing to put above the top of the shaft and keep a downward force on it. That cleaned up my z-banding.

On another printer, I had an issue where the threaded z shafts were not perfectly straight and they were moving the cars on the Z tracks slightly (again, z-banding). On this printer, I added oldham couplings (https://www.amazon.com/2-Pack-Coupling-Couplers-Compatible-Printer/dp/B0B17QWTG2) between the lead screw nut and the bed supports. It looks like you've maybe got something equivalent there. If so, these would isolate shaft wobble., but you might look for anything else that might be applying a force to the bed supports or the bed itself. It looks like there's a cable that may be tie-wrapped to the rear 2020 bed support. Better to tie wrap that the the lead-screw nut below the wobble decoupler. Any forces it applies will be isolated by the wobble-decoupler. The wiring from there to the bed would them have constant forces.

I think I might also be seeing a spring for a bed leveler on the right front corner (hard to tell for sure in the picture. If there isn't a hard connection for leveling (meaning the spring is holding it in place), that's another possible place for movement to happen if there are small irregular forces on the bed assembly.

Another thing to thing about is how rigid the print head is on the slider on the bridge. If there is any "play" in the slider, then the cables going to the print head might be wiggling the print head. If the extruder is "far" from the slider, it will amplify tiny movements.

Here's a wild theory - there's some interaction between the bed heater and the extruder heater, such that when the bed heater turns on, the power to the extruder heater is reduced slightly, leading to small variations in the flow of plastic. If the duty cycle on the bed heater is regular, it could lead to a regular pattern in the output.

It seems unlikely because the relay you pictured shows your bed is heated by AC. But maybe something on the control side is sinking too much current.

You could test by monitoring the voltage and duty cycle to the extruder heater.