Conversation
|
Since save_config is called through the console, can we just use a good old fashioned Really nice idea though, there are plenty of instruments that would benefit from this, I usually set default attributes in a meta 'lab' instrument which holds all the cooperative methods, and initialization functions for each instrument. This does extra work though for instruments with default parameters already. |
|
I'm with you on the GUI dependencies. I'll see if I can figure out some simple PyQt ones (last time I tried I found it annoying to synchronise within the QtApp) Really unsure what you mean with the Pickle and HDF5 aren't human-readable, so I'm not a huge fan for config files. In terms of YAML vs JSON, I might have a quick go at how JSON handles general Python types. I think YAML more naturally handles things. For example, it uses indentation for hierarchy, which is neat for Python users (see the YAML I pushed to this branch). But I haven't played with JSON much and it might be good too. |
|
I've found JSON and YAML similar for basic types - YAML is slightly more pythonic in structure but both work fine. I don't think JSON has out of the box support for serialising python types, but TBH that's not so human readable in YAML either, so I tend to wrap things in conversion functions to make sure i only load/save simple types. |
|
Got it working with JSON and PyQt. Not really sure there's much more to do in this PR. Maybe integrating with the previous config code which seems to be used to save spectrometer/CCD background/references (and a couple of more things), but I'm gonna need someone to test it |
… new code with JSON. First step in moving away from named configuration settings
|
Integrated with previous configuration code. I've tested it with my SeaBreeze spectrometer, and it seems the functionality is all good to go, but someone else testing it would be ideal Added the possibility of saving all of an instruments parameters. |
|
I am starting to need features I've developed in different branches, so I'm going to merge this next week It would be nice to check that it doesn't break anything beforehand (I'm not sure who is currently actively working on nplab @eoinell), otherwise I'll just be active to help if it does break anything after |
|
I'll have a quick spin next time I'm in the lab!
…________________________________
From: YagoDel <notifications@github.com>
Sent: Friday, February 26, 2021 9:22:28 AM
To: nanophotonics/nplab <nplab@noreply.github.com>
Cc: Eoin Elliott <ee306@cam.ac.uk>; Mention <mention@noreply.github.com>
Subject: Re: [nanophotonics/nplab] First pass at #124 (#126)
I am starting to need features I've developed in different branches, so I'm going to merge this next week
It would be nice to check that it doesn't break anything beforehand (I'm not sure who is currently actively working on nplab @eoinell<https://github.com/eoinell>), otherwise I'll just be active to help if it does break anything after
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<#126 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AKORCB54FN2SOWENPSLQ6UTTA5R5JANCNFSM4SSWD4JA>.
|
|
Thanks! I’ll keep an eye out for it
…On Fri, 26 Feb 2021 at 18:33, Eoin Elliott ***@***.***> wrote:
I'll have a quick spin next time I'm in the lab!
________________________________
From: YagoDel ***@***.***>
Sent: Friday, February 26, 2021 9:22:28 AM
To: nanophotonics/nplab ***@***.***>
Cc: Eoin Elliott ***@***.***>; Mention ***@***.***>
Subject: Re: [nanophotonics/nplab] First pass at #124 (#126)
I am starting to need features I've developed in different branches, so
I'm going to merge this next week
It would be nice to check that it doesn't break anything beforehand (I'm
not sure who is currently actively working on nplab @eoinell<
https://github.com/eoinell>), otherwise I'll just be active to help if it
does break anything after
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<
#126 (comment)>,
or unsubscribe<
https://github.com/notifications/unsubscribe-auth/AKORCB54FN2SOWENPSLQ6UTTA5R5JANCNFSM4SSWD4JA
>.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#126 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADFEQCM3R5BXCQPKZJXASOLTA5TIHANCNFSM4SSWD4JA>
.
|
| """Create an instrument object.""" | ||
| super(Instrument, self).__init__() | ||
| Instrument.instances_set().add(self) #keep track of instances (should this be in __new__?) | ||
| Instrument.instances_set().add(self) # keep track of instances (should this be in __new__?) |
There was a problem hiding this comment.
I don't think using new is necessary
| """ | ||
| instances = cls.get_instances() | ||
| if len(instances)>0: | ||
| if len(instances) > 0: |
| @@ -0,0 +1 @@ | |||
| {"ReadMode": 4, "AcquisitionMode": 1, "TriggerMode": 0, "Exposure": 0.01, "Shutter": [1, 0, 1, 1], "SetTemperature": -90, "CoolerMode": 0, "FanMode": 0, "cooler": 0} No newline at end of file | |||
There was a problem hiding this comment.
can exposure be 1s? most common value in our labs for Si referencing.
There was a problem hiding this comment.
Sure, I'm not using the default_config anyway. In that case, do you know what your shutter speeds are?
There was a problem hiding this comment.
I don't know, so probably setting it to (1,0,0,0) is most sensible..
There was a problem hiding this comment.
I think that'll fail for most shutters. Which could be good, since it'll force people to actively set their own configurations), but could also be a pain in the ass
There was a problem hiding this comment.
Ok, nvm, it seems that's what master does now anyway, so yeah Shutter=(1, 0, 0, 0) it is
| """ | ||
|
|
||
| from builtins import str | ||
| from nplab.utils.thread_utils import locked_action_decorator, background_action_decorator |
There was a problem hiding this comment.
locked_action and background_action are nicer aliases IMO
There was a problem hiding this comment.
Could agree, not an issue for this branch :P (it's been like that since the start of nplab)
|
Do the above comments mean you have tested this branch? |
|
I just mean use the console for input instead of a pyqt popup if it's easier - but you have this working now so nvm :) Just tried it now (sorry for the delay, tbh I prefer to let the rest of nplab do a bit of involuntary testing once i'm pretty sure it'll work) FileNotFoundError: [Errno 2] No such file or directory: 'C:\Users\hera\Documents\GitHub\nplab\nplab\instrument\spectrometer\default_config.json'` This is for the andor - I guess it needs to handle the case where there isn't a default_config file? Sorry this is a bit late in the game, but I can't help but feel that this would be better placed in the |
|
If these config files can't be implemented without having to change the respective instruments' code then they'll just become one more thing in the instrument base class that nobody knows how or why to use. Ideally calling instr.save_config() should be all that's needed to get going. This save call should also try to set all parameters, and remove any that fail. The properties to be set could be integrated with the metadata_property_names system possibly, but this is probably unnecessary. |
|
This is useful stuff, thanks!
So the config stuff all happesn in the
I'll have a look to fix the issue of it failing (it should be simple enough). You got that error just from trying to create an |
|
I very much appreciate the want for a tool that can be used by all users. I'm not sure I understand how an instrument instance can know what it's own "parameters" are though. So specifically, when you say "set all parameters, and remove any that fails", I'm not sure how to do it, other than manually giving it a list of names (which in this case was |
|
Hmm, yeah.. maybe a tuple of all settable parameter names similar to metadata_property_names but this requires some extra code. In camera.thorlabs.kiralux I implemented something where it would just add everything that has a getter and setter method, and remove any that fail but this may be a bit too general. You could explicitly filter properties that come from instrument.. A shamdor instance, yep. I guess there's a bit of a distinction between settings parameters (JSON is perfect here, and this should happen on every instantiation) and configs like background/reference spectra which are arguably better rendered with the h5 renderer and should be optionally loaded. |
|
This config_property_names system probably works well though – sorry I forgot what was in this commit exactly.
From: YagoDel ***@***.***
Sent: Monday 22 March 2021 11:56
To: nanophotonics/nplab ***@***.***>
Cc: Eoin Elliott ***@***.***>; Comment ***@***.***>
Subject: Re: [nanophotonics/nplab] First pass at #124 (#126)
I very much appreciate the want for a tool that can be used by all users. I'm not sure I understand how an instrument instance can know what it's own "parameters" are though.
So specifically, when you say "set all parameters, and remove any that fails", I'm not sure how to do it, other than manually giving it a list of names (which in this case was config_property_names, in parallel with metadata_property_names, but I'm happy to look into either merging them into a single one, or having a hierarchy)
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub<#126 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AKORCB7J25FQ6JAGP4MDKXTTE4V6BANCNFSM4SSWD4JA>.
|
|
Oh, I'll have a look at the I guess I hadn't realised people were actually using the HDF5 config code (that is currently in the Instrument base) for spectrometer, but I had tried to keep it compatible. I guess it breaks down if it tries to do both things (read configuration parameters from a JSON, and config for a spectrometer) Do you know if the current config code is used for anything else? |
|
Camera with location uses it for the pixel_to_sample_displacement
…________________________________
From: YagoDel ***@***.***>
Sent: Monday, March 22, 2021 12:35:40 PM
To: nanophotonics/nplab ***@***.***>
Cc: Eoin Elliott ***@***.***>; Comment ***@***.***>
Subject: Re: [nanophotonics/nplab] First pass at #124 (#126)
Oh, I'll have a look at the kiralux thing, but you're probably right we'd end up with tons of stuff.
I guess I hadn't realised people were actually using the HDF5 config code (that is currently in the Instrument base) for spectrometer, but I had tried to keep it compatible. I guess it breaks down if it tries to do both things (read configuration parameters from a JSON, and config for a spectrometer)
Do you know if the current config code is used for anything else?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub<#126 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AKORCB4I5HOY5NPVPCECVSTTE42RZANCNFSM4SSWD4JA>.
|
|
Ok, so three things:
And finally, following what you said:
I foresee one possible issue. I tried to make the config code backwards compatible, so that instruments could either save to HDF5 or JSON and the rest of nplab would continue working as it was. But if we create an instrument that is a subclass of an instrument that does config in HDF5 and an instrument that does a config in JSON (for example a |
It solves my issue with the Andor (stops setting values in the
Initializemethod), but haven't tested it with other instruments and don't know if it's useful for anything else, so I'm not closing the #124 yet