Modifying a global variable while running

[audryhome]

I wrote a macro to cool down parts after print, using the fan and the XY part trace to scan the entire printed area of the bed until head temperature reach an acceptable value. The idea is to accelerate part cool down, thus reducing wait time.

However, this process should be interrupted manually if the cooled part is easily removed from bed without damaging it.

I run a macro to do this, however I would like to interrupt the macro by setting a flag from command line, something like set global.part_cool = false. Macro does something like
"while (global.part_cool and temperature> something)
scan_the_bed
"

Using G4 P100 in the loop doesn't solve the problem, since G4 does wait, but don't allow me to send command to set a global variable until macro end, which is precisely what I want to avoid.

Using daemon.g won't solve the problem, since it will execute a set of commands the same way, only at regular intervals.

Question: Is there a command/trick that would allow this, other than wiring a hardware button somewhere and using it as a trigger?

Many thanks for help

[cosmowave]

@audryhome
that should be possible with daemon.g

in daemon.g something like:

if global.part_cool =true
....your code

And additionally a macro for toggle the variable:

if global.part_cool = false
    global.part_cool = true
else global.part_cool=false

To toggle the variable you can also use the BtnCmd PlugIn for direct access to the object model. But then only in DWC and not on the panel if you have one.

Note: this code is untested and only for demonstration.

[audryhome]

@cosmowave Thanks for the tip, but I cannot wait 10 Sec between action not put a loop inside the daemon.g code, since my code is scanning a a certain rate to cool down, and I need also to deactivate the daemon.g from the outside => more global variables..... Since this 10 sec is hard coded, I'm stuck....

[dc42]

@audryhome you can use a loop containing a G4 command in the daemon.g file.

[audryhome]

@dc42 Yes, but it will fire only at 10 sec interval, plus the G4 parameter, plus more, which is far too long.
I understand the reason why you stretched this delay, but in my case, I just scan the print area with the fan running at100%, nothing to do with print quality. BTW it cools the part, dual extruders and bed 40% quicker on my bigbox.

For instance, a G4 S4 will end up with 4 +10 minimal delay. Since I cannot change the 10 sec delay, it is useless. Would need as low as 100 ms to be workable for my use case.

BUT it works when I use the DWC console (set global.cool_part=false) while printing through Octoprint on a RPI 4. There is hope there, except I have to switch from Octoprint to DWC, what I try to avoid.
I don't dislike DWC, but I use mainly the PanelDue rather than the web interface once launched the print through OCTOAPP on mobile, and setting up a global variable through the panel is not very easy and I don't see how I can do it through octoapp.

Maybe I miss something on panel due ( custom button with a meta command on main page possible? )

Many thanks

[jay_s_uk]

@audryhome i believe if you add a loop it runs continuously and isn't subject to the 10 second delay

[Sindarius]

This post is deleted!

[dc42]

@jay_s_uk said in Modifying a global variable while running:

@audryhome i believe if you add a loop it runs continuously and isn't subject to the 10 second delay

Correct. The 10 second delay occurs when RRF reaches the end of daemon.g or daemon.g aborts, before RRF tries to open and start daemon.g again.

[audryhome]

@dc42 So I solved the problem by putting a simple macro that shows up on Panel Due main page.
This toggles the variable that control the cooling. Then I can modify it while a macro is running in a loop.

Regarding daemon.g, I think user should have control on the 10 sec delay. I understand the reason why this is done that way, but this greatly limit the usability of this interesing functionality.

Many thanks again for help

[OwenD]

@audryhome said in Modifying a global variable while running:

Regarding daemon.g, I think user should have control on the 10 sec delay. I understand the reason why this is done that way, but this greatly limit the usability of this interesing functionality.

Actually you have failed to understand the advice you were given.

If you put an infinite loop in your daemon.g, it does not run every 10 seconds.

; daemon.g
while true
   echo state.time
   G4 S1

Would do everything in that loop once a second (plus the time to carry out the commands within the loop)

As the macro remains open, RRF won't open it again.
The reason it was changed to 10 seconds was because every time it's opened it must be read from the SD card, which impacts on other processes.