You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.
In order to keep the UI in sync with the scope, and to be certain of continued connectivity, parameters should be pulled from the scope continually when it is idle. This allows the UI to be kept up to date and tests the link.
The text was updated successfully, but these errors were encountered:
Any traffic to the scope, especially on slower/high latency instruments (Rigol, VPN access, etc) adds latency before another command can be issued. If done in the UI thread it will hang the UI and if done in the waveform polling thread it will block the trigger polling. Most of the optimizations made in scopehal over the past years have been aggressively minimizing unnecessary communication, not creating more.
If there was a way for instrument firmware to push "settings changed" notifications to the scope, perhaps as part of polling the trigger, then we wouldn't be adding more traffic. (Feature request for responsive instrument vendors?)
There is a "flush config cache" button on the toolbar of glscopeclient that forces all settings to be refreshed and is intended to be manually clicked when scope settings are modified via the front panel. We used to have a timer that automatically refreshed every N seconds but this ended up causing periodic UI stuttering and was removed to improve responsiveness.
I was explicitly intending this for the case where the scopeclient is otherwise idle, because it lets us track any changes to settings the user might make on the scope front panel. There will be some increased latency in the transition from idle to sampling, but hopefully that would only be in the order of milliseconds. We can't use this technique while collecting samples because it would impact on performance, I agree.
Yeah, it might be OK then but I've worked with scopes (e.g. Rigol over VPN) in which every single command had a cost of hundreds of ms. If nothing else, there would have to be a preference to disable it.
This might be a UI-side issue better for scopehal-apps, but I'll keep it here until we've figured things out more.