How to work around variable queries from scripts being cached?

Development
1

Hi OctoPrint tweakers,

I'm the creator of the SMuFF, the Smart Multi Filament Feeder - a thing that no one really needs but many want to have :rofl:

I've been asked a couple of times, if the SMuFF could be controlled via OctoPrint in order to be used on Marlin printers (I've made it for Duet3D initially).
After browsing the OctoPrint online documentation, I found a interface that sound pretty powerful to me: The hooks - the GCode hooks in special - and I made a very bold statement "Yeah... it can be done easily, you know, you just have to..."
A couple of days later, I decided to test my statement and came up with a simple SMuFF plugin - which I though could serve as a framework for those who like to tinker around. I didn't have the chance to fully test it at that time, so it just sat there for a couple of month.
Now that I do have the testing environment, I though, I give it a try and make it fully working.

Well... long story short, that's what made me come here visit you...
After a couple of days playing around, I wasn't able to solve one major issue:

As you may imagine, I'm utilizing the GCode scripts "beforeToolChange" and "afterToolChange" in order to provide a tool change. At some point I wanted to have a bit more control over what happens while loading/unloading and tried to integrate the SMuFFs Feeder-Endstop states into the scripts.
The only way I was able to achieve this, was this code fragment within the scripts:

; some GCode
{% set _stop = "" 		%}
{% for i in range(1, 16)	%}
{%   if not _stop 		%}
{%     if plugins.SMuFF.feeder=="on" %}
          M117 Feeder = {{ plugins.SMuFF.feeder }} - {{ loop.index }}
          M83
          G1 E-10 F300
          M400
{%     else %}
{%       set _stop = "1"	%}
{%     endif 		%}
{%	 endif 			%}
{% endfor 			%}
; some other GCode

Now, one would expect, that within the loop the plugin variable ".feeder" gets queried a couple of times, which is not the case. I've put a log-info in the code section of the plugin, and this is being printed out:

2020-05-28 16:37:00,578 - octoprint.plugins.SMuFF - INFO -  >> Script vars query: [gcode,beforeToolChange] {'tool': 'T4', 'aligned': 'no', 'feeder2': 'off', 'feeder': 'on'}

Nice! But it's the only line in the log file, where I suspected many of them. So, obviously, the very first request gets through but it's being cached somewhere deep down in the guts of OctoPrint.

So, finally, here's the master question, as the title says:
Does anybody know a way to work around this behavior?

2

Maybe something in octoprint.comm.protocol.scripts that might work for you? @kantlivelong would probably be one of the people that would know for sure.

3

The one thing you need to look out for though is the notice regarding these gcode processing hooks. You aren't suppose to block them as it can cause unexpected serial timeouts and other problems with the printer's buffer.

4

GCODE(Jinja) scripts are currently processed then sent to the queue and as such data isnt refreshed. I'm not sure if this would work and don't have the time at the moment to check but you may be able to get refreshed data by calling a snippet.

5

That's what I did to publish the vars to the script.

Meanwhile, I dug a bit deeper into the OctoPrint code and found what @kantlivelong said. The script code is being processed when the script is loaded. Hence I'm getting only one query of the vars.

Will try the snippet thingy and let you know.

Thank you guys.

Edit: Nope, same result with snippets as with without.