Adding PLE scanner application

[nyama8]

Implemented PLE scanner application in qt3utils.applications.qt3ple initially implemented by Lane (see qt3utils PR here qt3uw/qt3-utils#132).

Additionally modified low-level DAQ sampler classes in qt3utils.datagenerators.daqsamplers to remove unnecessary sleep function calls in the edge counter sampler.

This PR does not include any further modification or simplification of other parts of the code which needs to be addressed in a separate, new PR.

[ethan-r-hansen]

Overall looks good. There is only one place where I think the comment about a class should be added back.

Another thing is that, I think for the main qdlt-utils, we should have docstrings for all functions, making future coding and usability much easier. Github copilot helps with docstrings, although we probably want to pick which convention we want to use as a group (I like the numpydocs convention). Then, we could autogenerate documentation to have online. But that is definitely a change for a different PR and doesn't really concern this.

[ethan-r-hansen]

Nah I think this is good to have

[nyama8]

I will need to verify the code but I suspect that this function has been superseded by direct calls to the wavelength controllers. It probably should be removed unless you have a specific reason to keep it.

[ethan-r-hansen]

Can we add some description of this function back?

[ethan-r-hansen]

What is this lol...

[nyama8]

Apparently this is what happens to local image files in jupyter notebook. I think it can be ignored since the actual notebook renders correctly.

[ethan-r-hansen]

Bless up

[nyama8]

FYI, implementation of this is not complete but I will address it in issue #4 most likely.

[ethan-r-hansen]

This is great and was a comment I was going to make throughout, we should be adding docstrings for every function in the future.. Maybe we can bring this up during the group retreat. With GitHub copilot, generating docstrings is usually pretty easy.

[ethanqw]

Good.

[ethanqw]

Is this script specific to a certain lock-in device/model?

[nyama8]

I believe this was an addition from @LaneUW at an earlier stage of the code (where we were trying to be universal). I suspect that we should remove this for now and let people implement this on their own (or add support for specific hardware when addressing #4).

[NnguyenHTommy]

If this is general, needs documentation for the params that need to be set so that anyone can hook up any lock-in and use this code. Some testing should be done and documented somewhere to show that it works.

Some guidelines that I found helpful when dealing with any pull request:
When you issue a pull request, be very clear and verbose about the changes you are making. New code must be reviewed by another colleague before it gets merged to master. Your pull request should include things like

• a statement describing what is changed or new
• a reference to the Issue being fixed here (Github will automatically generate a handy link)
• a statement describing why you chose your specific implementation
• results of tests on your hardware setup, which could be data, screenshots, etc. There should be a clear record demonstrating functionality.
• a Jupyter notebook in the "examples" folder that demonstrate usage and changes
• documentation

I think it would be useful to follow these especially when pulling on the main branch of qdl-utils

[NnguyenHTommy]

If this is general, needs documentation for the params that need to be set so that anyone can hook up any lock-in and use this code. Some testing should be done and documented somewhere to show that it works.

Some guidelines that I found helpful when dealing with any pull request:
When you issue a pull request, be very clear and verbose about the changes you are making. New code must be reviewed by another colleague before it gets merged to master. Your pull request should include things like

• a statement describing what is changed or new
• a reference to the Issue being fixed here (Github will automatically generate a handy link)
• a statement describing why you chose your specific implementation
• results of tests on your hardware setup, which could be data, screenshots, etc. There should be a clear record demonstrating functionality.
• a Jupyter notebook in the "examples" folder that demonstrate usage and changes
• documentation

I think it would be useful to follow these especially when pulling on the main branch of qdl-utils

[NnguyenHTommy]

Why is this implemented this way? Other piece of hardware (nidaq and spectrometers) doesn't have an application controller in the yaml file.

[nyama8]

I think it is probably better to implement YAML files separately for each application since the logic of the generic "config_from_yaml" function will be specific to each application. Having the header be the name of the application should help in ensuring that the purpose of the config files are well-defined.

Alternatively we could make a "super"-config file which has all hardware and applications in one file, but it'll probably be a bit messy.

[NnguyenHTommy]

I think it would make sense to remove this whole file and have users make their own. Or have users input their own file paths for the wavemeter they are using

[nyama8]

I will probably remove these extra files as the initial conception of the code was overly general.

[NnguyenHTommy]

this is good b/c it's in a seperate class

[NnguyenHTommy]

only meaningful change. all other changes were readded. Since this was just a parameter added to a class, I dont think this will break anything

[ethan-r-hansen]

Looks good