Variables and Work Arounds
-
@oliof Thanks for the suggestion. I never thought about that before, although I must admit that I'm not sure how to implement it for my desired goal. I'll put some thought to it and see what I can figure out.
Cheers,
Kolbi -
so you want to f.ex. say "print a", "print b", "print c" and have a M291 dialouge visible for 3 seconds before moving on to the next one, and which ever the user presses ok on is the one you want to act on?
and loop forever until the user presses ok on one of them?
-
@bearer Yup, that's the objective - to cycle through options unless 'ok' is pressed within a certain time, or user presses cancel.
-
cancel might be an issue, but if it is you could add another "ok" option to stop the cycling.
-
@bearer I think the cancel would be a win-win in that it would stop the cycling and eject from the current routine. The biggest hurdle I have is trying to figure out if the user did one of two options; let the designated time expire, pressed ok within the designated time.
-
Hi,
The problem with M291 is that the options S2 or S3 that display an OK button ignore any T parameter and never timeout and are blocking.
Would it work for you if you had a macro that stepped a fan variable through a set of options with each click and then another macro that when clicked executed based on the current fan variable value?
Frederick
Printers: a small Utilmaker style, a small CoreXY and a E3D MS/TC setup. Various hotends. Using Duet 3 hardware running 3.4.6
-
@fcwilt said in Variables and Work Arounds:
and never timeout and are blocking.
can be countered by daemon.g and M292 based on storing the past uptime in a variable before calling M291, comparing to current uptime was my thinking but I haven't sat down to toy with it yet.
-
@fcwilt Totally concur with M291 assessment, would be great if it provided a feedback flag to let you know what happened also.
As of now, my macro steps though options, at each prompt changing a separate gcode file (like stepping a fan variable in your reply) and with this, leaves that setting intact when the user ejects from the menu macro. It works, not the most elegant solution though. With variables use it would be much easier to compare time of prompt and return, to then decide what logic to follow.
If interested, you can take a look at it here:
"Set Filament Type" asks what type filament you are going to use; PLA, PETg, ABS, or PC. Based on the selection, this macro rewrites the "Heat Nozzle" macro to heat the nozzle for the selected filament type.https://github.com/rkolbi/RRF-machine-config-files/tree/master/Prusa MK3s/macros
-
@Kolbi said in Variables and Work Arounds:
If interested, you can take a look at it here:
"Set Filament Type" asks what type filament you are going to use; PLA, PETg, ABS, or PC. Based on the selection, this macro rewrites the "Heat Nozzle" macro to heat the nozzle for the selected filament type.So you don't make use of the filament handling features (M701, M702, M703) that are part of the firmware?
I've taken that approach and it works well for me.
Frederick
Printers: a small Utilmaker style, a small CoreXY and a E3D MS/TC setup. Various hotends. Using Duet 3 hardware running 3.4.6
-
@bearer said in Variables and Work Arounds:
storing the past uptime in a variable before calling M291, comparing to current uptime
Yup, this is and has been my exact thought but the question is, at the current time with the3.11 - how to store in a variable?
-
@Kolbi said in Variables and Work Arounds:
how to store in a variable?
i'd try what dc42 suggested, a dummy axis that have one numeric offset for each axis. but as there was a hint the other day 3.2 wasn't too far off its a medium low priority in case that introduces full on variable support
-
@fcwilt I do - kinda. This is mainly for the paneldue display as that is what I use most. The macro set does execute 701/702 to make the duet aware of which filament is loaded so that the filament's corresponding config.g can be executed.
-
Thanks @bearer, I'll take a look into it.
