New API #41
Replies: 2 comments 2 replies
-
Hey Jacob and Michael, Sounds like a great plan to upgrade NSpyre! I'm excited to see how it evolves! To get the discussion started, here are a few thoughts I had (although obviously user feedback will be way more important!):
I think it's a nice idea, but I would recommend you make sure there is still an easy way to completely kill the server, because sometime (when thing goes sideways), you might want the ability to "kill it with fire!". In particular, I would be careful to accommodate the following use case: if the user starts an instrument (that they are currently developing) on the server, can they then make a modification to the instrument drivers and then re-instantiate the instrument with the new code they've just written. This is currently done by shutting down the server and restarting it, so implementing an easily accessible kill switch would do the same. An even better system would be the ability to do this more granularly (on an single instrument basis) so that not all instrument need to be restarted, but that would require some very careful thinking when it comes to reloading python modules (within the same process) in a robust way.
I think it's great to include that option, although I would suggest there still be some "recommended" standardized framework (potentially Lantz). This standardization layer enforces some discipline in the drivers implementation and also allows for higher level code to have an expected interface (think of the Instrument Manager GUI for instance, with every instrument being completely arbitrary it will be very hard to implement a GUI that works across the board). I think the "option" of building instrument outside of the standardize framework can be useful on occasion, but I would still try to incentivize the user to stay within the framework 99% of the time. Overall, I'm excited about this upgrade plan and I can't wait to see a demo when you have it working! And of course, I would also love to hear some thoughts from some of the current NSpyre users. |
Beta Was this translation helpful? Give feedback.
-
Hi Jacob / Michael, I really appreciate you typing up such a long post to show where you would like to go with the project. In general, my biggest worry is that you're building this software for people who have a similar level of coding skills to yourselves. I do not think that is the case. For instance, I only just learned how to zip tuples in python in order to repackage data. This is after consistently coding those tuples for the past five months. So, I see it taking a long time for me to figure out how to code a driver well, code a GUI well, combine instruments together, etc., in such a free form way. The standardization that makes NSpyre so inflexible and causes some problems also takes away a lot of the back end. And while I still kinda had to learn the backend, learning the backend helped me understand what I could do. So, if there's less backend, I'm worried that it will be harder to get my bearings while writing code. I liked Michael mentioning that he's developing example drivers to look at. I also thought the boiler plate code (I believe I am understanding it correctly but this might be the wrong term) was a great idea, since I think I still have a ways to go on Qt literacy, and I know several people who know even less than me. Not that we can't learn: we just want to spend as little time as possible on the nitty gritty. That being said, this writeup does look great, especially for those coming to NSpyre for the first time. The spyrelet does look more readable (despite not knowing what your helper functions mean), the instrument server seems even easier to handle, and getting rid of mongo is wonderful (well, I have written my own save function due to the current one not working for us, and I use Mongo to hack it, but it helps with almost everything else.) As long as there will be some sort of tutorial or documentation about how to use this open-ended version, then I am happy. |
Beta Was this translation helpful? Give feedback.
-
Hey everyone, Jacob and Michael here. We've been discussing the redesign of the nspyre API and thinking about what an ideal interface would look like. Below we've provided a toy example to demonstrate what we have envisioned and would like everyone's feedback, especially because this is the part of nspyre that you - the user - will be interacting with daily for experiments. If you have any ideas, questions, or comments you can just post them below. (TLDR at the bottom.)
Spyrelets
Let's say we need to write a script to take ODMR measurements and we would like to use its functionality in a Jupyter notebook, a standalone GUI, or part of the larger integrated NSpyre GUI combining a number of different measurements and hardware control. Our file to do this,
odmr.py
, looks like this:Structuring our code in this way provides a number of benefits and the maximum flexibility in how measurements are run. We found a lot of people were confused by the format of the previous Spyrelet class, which severely limits how experiments are structured. The new format does not place any restrictions on how experiments are written or run and our simple file above provides multiple modes of operation.
Simply executing the script as
python odmr.py
will launch an NSpyre GUI application with ourWidgetODMR
class displayed. It checks if the Instrument Server is running and start the server if necessary. Additionally, the Instrument Manager GUI can be launched automatically if it is not running. This is the easiest way to take a measurement quickly. No more opening three consoles just to get everything started; this is all taken care of for you. You may have also noticed that a client configuration file is no longer needed to run a spyrelet. The ODMR data is directly available for you to manipulate and save how you please (if you don't want to use nspyre's built-in methods, although they are being revamped). If you want to use this ODMR functionality in a Jupyter notebook, you can do so directly, all you need is a gateway connection and you can use it directly as before:Finally, if you have multiple 'pieces' of code to which it is necessary to have simultaneous access and/or would like to combine custom and generic UIs, this is possible by passing nspyre the
WidgetODMR
class. For example, say you have two spyrelets you need to have access to for measurements. In addition, you would like a live camera feed for imaging and a set of custom UI controls you've written for moving your objective and sample stages. As long as each of these pieces is aQWidget
class (notice theWidgetODMR
class is such an example), you can add each of these to your local nspyre directory of available spyrelets and on startup of the NSpyre GUI select the desired pieces to load a custom UI. Each spyrelet is resizable, minimizable, and independent of the others. You can even save these configurations as a template to load from the startup menu for future ease of use. (You'll just have to trust us on this claim, no fancy example images here.)Visualizing Data
One feature that is wrapped up in all these changes but is not apparent from the above code if how nspyre handles data. Gone is MongoDB and in its place is a lightweight data server for providing real-time data to any connected clients. The lightweight implementation means NSpyre handles connections in the background, which is why in the code above, the only lines related to this are the calls to
nspyre.datatype
andnspyre.data_pub
. For localhost clients, this means the data is passed directly to the client, such as a View Manager. For remote clients, this means the data is as real to time as it gets. Multiple people can easily view the same data in real-time on different machines on different networks; no more screen sharing a zoom call to work on things together. This will be particularly useful for the eventual long distance entanglement experiments between labs. Finally, the View Manager UI is being revamped to allow for the visualization of multiple datasets at once.Instrument Server
For the Instrument Server, the current methods for configuring, starting, and interfacing will persist, with two exceptions. First, the server will be spawned as a daemon process detached from any shell/process from which it is started. The benefit of running the server as a background process is that simply exiting out of the startup console or command line interface will not stop the server. Secondly, new convenience functions will be added to allow for the creation and modification of servers within a script. The server can now be configured entirely from a python script. Finally, drivers no longer have to be written in Lantz and can be arbitrary class objects. The proposed interface looks as such:
To connect to and modify an existing server, the following capabilities are exposed:
We think the above examples provide a clear view of the new API design, which we hope addresses most of the current concerns, frustrations, and failures of the current implementation. Thanks for taking the time to read this lengthy post. We would greatly appreciate your suggestions as we start work on this redesign (some of which is already complete). Thanks!
-- @jacobfeder and @mtsolmn
TLDR
Beta Was this translation helpful? Give feedback.
All reactions