Variables and Work Arounds

[fcwilt]

Hi,

3 questions:

1. Any idea when variables will be available in firmware 3?

2. Can I create an axis, say U, make it hidden and use it's userPosition property for now as a sort of variable?

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

Thanks.

Frederick

[Kolbi]

@fcwilt I have read somewhere on these forums about using a 'fake' fan as a variable workaround. I have tried it myself as it works - kinda. You can set the speed 0-255 and recall that information as an int, also you can set the name and then recall that as a string.

Cheers,
Kolbi

[A Former User]

dc42 also suggested using dummy tools with offsets

[fcwilt]

@Kolbi said in Variables and Work Arounds:

@fcwilt I have read somewhere on these forums about using a 'fake' fan as a variable workaround. I have tried it myself as it works - kinda. You can set the speed 0-255 and recall that information as an int, also you can set the name and then recall that as a string.

Cheers,
Kolbi

Yes I like that idea better. If I can set and test the name that would make things even simpler for what I have in mind.

Frederick

[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