Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Continuously monitor scope configuration #442

Open
mubes opened this issue May 1, 2021 · 3 comments
Open

Continuously monitor scope configuration #442

mubes opened this issue May 1, 2021 · 3 comments
Labels
tabled Don't write code until further discussion

Comments

@mubes
Copy link
Collaborator

mubes commented May 1, 2021

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.

@azonenberg azonenberg added the tabled Don't write code until further discussion label May 1, 2021
@azonenberg
Copy link
Collaborator

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.

@mubes
Copy link
Collaborator Author

mubes commented May 1, 2021

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.

@azonenberg
Copy link
Collaborator

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
tabled Don't write code until further discussion
Projects
None yet
Development

No branches or pull requests

2 participants