Is it normal for an oscilloscope to accept commands over the network like this?

I've been running scopes over Ethernet like this for years, long before AI got involved, and it's a perfectly normal workflow. Most bench instruments speak SCPI over a network connection these days, and pulling captures off remotely is exactly what that feature exists for. Nothing sketchy about it at all.

The settings drift thing is mostly a non-issue, with one caveat. The instrument doesn't wander off on its own, settings only change when something sends a command. What does happen is the scope makes its own internal adjustments you didn't ask for. Autocalibration can kick in mid-session, some scopes re-run thier auto-setup routine if a command sequence trips it, and trigger holdoff or coupling can quietly differ from what you thought you set. So the fix is simple: after the AI configures the trigger, have it query the relevant settings back and print them. Read-back is cheap, and if a capture looks weird you know exactly what the scope was actually doing, not what you assumed it was doing.

For long unattended sessions the things that actually bite you are boring infrastructure stuff. Network hiccups, the scope's webpage or remote interface needing a kick after hours of idle, capture buffers filling up beacuse nobody is pulling them fast enough. I have the controlling script save every capture to disk with a timestamp plus a screenshot of the front panel at that moment, so even if something goes sideways overnight I can reconstruct what happened later. One habit I'd keep regardless of who or what drives the scope: export the raw waveform data and personally eyeball a handful of the captures, including some where the AI says everthing looked fine. LLMs are good at driving the instrument and spotting obvious anomalies, but they can be confidently wrong about subtle signal stuff like marginal timing or a glitch that's really a probe grounding problem. The captures themselves are as trustworthy as they'd be if you'd set the trigger by hand. The interpretation is where you stay in the loop. And yeah, once your intermittent fault shows up every few hundred transactions, remote triggering is absolutely the right tool. I'd never find it staring at the screen either.

This thread is making me feel better about something I did last month. Not a scope, but I left a logging script running on my network analyser for a week while I was chasing a dropout in a radio link, and it just quietly filled its internal buffer and started overwriting old captures halfway through. Lost the exact moment the fault happened. So if you're doing long unattended runs, check wheather your machine keeps everything or recycles memory, that bit me hard.

Do you find the AI handles it okay when the connection drops mid-session? Mine would just sit there waiting forever and I never figured out a clean way to make it recover on its own.

Did something similar last year on a production fixture at work, had a script hammering our bench scope over the network for three days straight logging every capture. The one thing that got me wasn't settings or buffers, it was the scope's front panel being touched by a well meaning colleague mid run. So now if a job needs to run unattended I just lock the front panel, most scopes have a command for that, and the AI fiddling with yours remotely is actually safer than a human with physical access.

Seconding the read-back advice, that habit saved me a bunch of head scratching last year. I had a script driving a scope for a week and one day the captures all looked stretched. Turns out the timebase had been left on a diffrent setting after the script restarted, and because I never queried it back I chased a phantom timing bug for two days. Now any script I write prints the scope's actual config to a log line alongside each capture, so when something looks off I can see exactly what the instrument thougt it was doing at that moment.