search

labscript-suite-oldfinal1 / labscript

The labscript Python library provides a translation from simple Python code to complex hardware instructions. The library is used to construct a "connection table" containing information about what hardware is being used and how it is interconnected. Devices described in this connection table can then have their outputs set by using a range of functions, including arbitrary ramps.
BSD 2-Clause "Simplified" License
0 stars 0 forks source link

#19: Remerge JQI with Monash. Then get ground rules down for proper behavior with rules. #19

Open philipstarkey opened 7 years ago

philipstarkey commented 7 years ago

Original report (archived issue) by Ian B. Spielman (Bitbucket: Ian Spielman, GitHub: ispielma).

There has been a lot of development at JQI. This needs to be merged into the main branch. Then the labscript documentation should define the exact procedure we want to follow to add features.

philipstarkey commented 7 years ago

Original comment by Philip Starkey (Bitbucket: pstarkey, GitHub: philipstarkey).

I would like to suggest that many of the BLACS features logged so far could be incorporated into a more expanded "plugin" system so that they can be easily turned on/off by people who are not looking for that functionality and there is less inter-dependency between the core framework of BLACS and features. The plugin system also exposes access to the BLACS preferences panel, meaning configuration is possible without having to delve into the labconfig file and without needing to restart the application. Particularly #31 and #32 should be able to be implemented as plugins provided some additional callbacks are exposed through the plugin system.

philipstarkey commented 7 years ago

Original comment by Chris Billington (Bitbucket: cbillington, GitHub: chrisjbillington).

Agreed, and the plugin system is a good way to keep the code maintainable regardless of preferences for what should be enabled and not. So basically instead of putting code at the beginning and end of the queue, we'd add things like a "pre_shot_actions" hook and a "post_shot_actions" hook to the plugin system, and then have the plugins register actions to occur at those points and keep track of their state internally.

philipstarkey commented 7 years ago

Original comment by Ian B. Spielman (Bitbucket: Ian Spielman, GitHub: ispielma).

So really runmanager would be telling blacs what pre and post-shot actions come with each shot? What about cases where Blacs is giving itself shots (like reps)? In such a case we do not want backups, for example, so Blacs would have to contain some added logic that replicates runmanager logic. I think this adds to the argument that the primary shot queue should be in runmanager and that Blacs should be asking runmanager for the next shot when it is ready for it.

philipstarkey commented 7 years ago

Original comment by Chris Billington (Bitbucket: cbillington, GitHub: chrisjbillington).

Ah, no, this plugin system is about how code and settings are organised and in BLACS. Rather than putting code at the start and end of the queue managing code, we'll put a "run_pre_shot_actions()" function at the start and a "run_post_shot_actions()" or similar at the end, and BLACS plugins will register actions that they want to take place. The plugin code is all still within BLACS, it's just a neater way of organising the code and settings. We ought to implement many features as BLACS plugins regardless of whether that code is calling out to runmanager. Plugins can register actions as well as insert things into the GUI, so I think even the progress bar should be implemented as a "plugin", even though it's unlikely to ever be disabled - it's a clean way of organising the code in the presence of uncertain feature growth.