Variables and Work Arounds

fcwilt

Hi,

I tried the idea of using dummy fan names as variables.

For my particular needs, two modes used for controlling probing and height map creation/loading, it worked great.

And being able to see the current modes right there in the fan names was a bonus.

Frederick

Kolbi

Nice!

For my project, I needed to hold a number >255 so I have to wait until variables...

Phaedrux

@fcwilt said in Variables and Work Arounds:

Why does G92 not affect the userPosition property of a hidden axis?

Possible because hiding an axis removes the need to home it, so perhaps G92 doesn't have meaning for them?

fcwilt

@Kolbi said in Variables and Work Arounds:

Nice!

For my project, I needed to hold a number >255 so I have to wait until variables...

How big? You may be able to do what I first did - use the position of a dummy, hidden axis. I don't know what their max value is but it is greater than 255.

Frederick

fcwilt

@Phaedrux said in Variables and Work Arounds:

@fcwilt said in Variables and Work Arounds:

Why does G92 not affect the userPosition property of a hidden axis?

Possible because hiding an axis removes the need to home it, so perhaps G92 doesn't have meaning for them?

That makes sense.

But for now dummy fan names is an even better solution for my current needs.

Thanks.

Frederick

Kolbi

@fcwilt The goal was to get system uptime, add 3 seconds to it, call M291 with an OK box and 3seconds max, and then upon return check if 3 full seconds had elapsed or not. This way I could have a cycling interface, where a user presses ok at the desired selection. Then the logic would just be if current uptime is less then saved uptime(+3 seconds) then do some stuff, else keep cycling options.
But glad it worked for you

oliof

@Kolbi in 3.1.1, daemon.g is being called every second, maybe that already gives you enough leeway for your cyclic running of commands?

Kolbi

@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

A Former User

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?

Kolbi

@bearer Yup, that's the objective - to cycle through options unless 'ok' is pressed within a certain time, or user presses cancel.

A Former User

cancel might be an issue, but if it is you could add another "ok" option to stop the cycling.

Kolbi

@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.

fcwilt

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

A Former User

@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.

Kolbi

@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

fcwilt

@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

Kolbi

@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?

A Former User

@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

Kolbi

@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.

Kolbi

Thanks @bearer, I'll take a look into it.