OM based "virtual triggers"

[oliof]

This is an idea to run gcode based on certain OM values, as an alternative to looping in daemon.g

Basically, use the triggers functionality, but instead of tying the trigger to a pin, tie it to an object model entry and a condition (i.e. value matches X or exceeds Y).

I guess there is a good reason we have daemon.g instead of that, but I wanted to note this idea here anyways.

[moth4017]

@oliof I like that idea would be good so i can integrate my drybox and spool weight , im using the object Model more and more these days , thanks to minty trebor

[deckingman]

@oliof I like that idea. I haven't used daemon.g but if I understand correctly, it runs ever "n" seconds so there would be a delay between something happening and the response to that event. Whereas a trigger would not suffer that loop delay. It also has "built in conditions" for any time or only while a print is running which is one less thing to check.

[o_lampe]

@deckingman ...what you said

• and it doesn't read the SD-card everytime it runs.

[o_lampe]

...just wondering how many virtual triggers (and perhaps followed by macros) the main loop can handle without extrusion defects/stuttering motion.
There's also a priority issue, I guess.

[jay_s_uk]

@oliof i also definitely like the idea of OM based triggers.
ideally something along the lines of triggering a file on value change or variation from a set point.

[MintyTrebor]

@oliof (& more) I Agree - I like the idea - I have a hunch it could get quite computationally expensive though, especially if you factor in conditionality like delta's or if a value is only considered "changed" if it over a threshold for a set amount of time (to account for noise etc)... Lot's of variables to keep track of, and the OM is quite large to be parsing/extracting values every cycle. I expect it would have be limited to a fixed number of available triggers to keep it lightweight.

[o_lampe]

@MintyTrebor I'm not sure if it's based on OM values, but the undervoltage emergency shutdown is already implemented

To me it's obvious, that it should only be used with similar high priority problems.

[oliof]

@o_lampe undervoltage is based on an analogue sensor triggering an interrupt (conceptually speaking, please don't crucify me for technical imprecision). So that's computationally cheap.

@MintyTrebor I agree that its going to come at a cost (mostly RAM, and of course the actual checking). I don't think you need to check the whole OM when having triggers. And limiting the amount of available triggers to a small number (I think 3 would be sufficient for many setups when used with caution and 5 may hit that 90% spot where the outliers would have the skills to build their own firmware, but of course there will be people who want to do everything with the new thing (-: ).

[chrishamm]

@oliof It's pretty straight-forward to write an SBC plugin for this purpose, although I understand some folks will stark shouting "and what about the standalone users?" once I finish this sentence. For the latter daemon.g + global vars may be a reasonable fallback.

[oliof]

The point is to avoid daemon.g and globals due to the side effects (SD card wear and delayed reaction to changes).

An SBC plugin would be an interesting first approach. It might even be one where I would consider SBC mode useful ...