I think the comment in that feature request from #67608 captures it: we are basically hunting for rare undesirable behavior and need to record on trigger for hours or days, preferably capturing all instances of the issue. The script API lets us trigger, record for a reasonable period of time, and then resume waiting for another trigger. It’s simply too data heavy to do logs for this long most of the time, considering most of the time is spent waiting for triggers.
Said another way, I’d say these devices are fundamentally used for two purposes:
- development: sitting in front of hardware that’s supposed to behave in a certain way, testing that it does, and fixing it when it doesn’t
- debugging: waiting seconds, minutes, hours, days, weeks, etc for a situation to occur and gathering as much information as possible from the hardware signals to figure out what the issue is, whether that is hardware, firmware, or something else.
While we spend more time using this in development, debugging is where a tool like this can save a ton of money and pay itself off many times over. Without scripting, your product only solves the development use case. With scripting, it solves both. You definitely have a sense of this given the scripting available on 1.x software, so we encourage you to consider this a required feature for 2.x and all releases going forward. It’d actually be better if this capability was built into the app GUI, but we don’t mind scripting at all if the hooks are there in the API.
Mostly unrelated: it’d be great if you could trigger on more than one line at the same time, whichever comes first.