Laser scanning toolchain used for e.g. PLE #120
Conversation
…en trying to change anything in the streamer
…es NOT interpolate.
Wavemeter_histogram_logic runs repeatatly by a QTqueued connection. This logic has access on the time series reader logic, while both are connected to their instreamer, respectively. It is to be checked if this implementation of logic being connected to logic is done properly. Moreover, the data acquistion/ synchronisation is implemented in the following way: The samples to read from the hardware are determined by the faster acquiring count instreamer. Upon this value the wavelength is then queried and directly interpolated in the hardware file as soon as at least one value is available. Thus a data array of equal size is generated. The time trace for the scatterplot is extracted from the wave instreamer.
-New gui file with subscript _2 -generating main window without QT Designer / .ui file -Implemented InteractiveCurvesWidget such that the current laser position is visible as marker with the move_marker_selection method -Implemented an axis toggle option between nm and Hz The logic is changed in such a fashion that it needs the time series reader application to be running with only one digital channel. For this an additional signal in the time_series_reader_logic.py is added which emits only the most recent data points of the time series instreamer and is received in the wavemeter_histogram_logic.py.
-Implementation of saving, fitting, envelope, toggle of bottom dockwidget and autoscale histogram functionality
-Try to improve performance by introduced separate gui refresh rate and plotdataitem with the ability to set a downsampling. Further, first try of two separate start buttons is implemented.
GUI: -Histogram region; show all data; added dockwidgets; restore default LOGIC: -Improved the binning of the histogram such that no empty bin; saving of envelope data
-Set up of remote connection; netobtain and new config (not commited) -Hence hardware file cannot emit signal for current wavelength any more -small adjustments for Gui
-Added name tag option for saving -Enabled saving again while acqusition is running
-Added signal (sigStopWavemeter) in timer_series_logic to fix interplay. (When timeseries is stopped the wavemeter data acquisition is stopped.) -Enabled fitting of envelope
commit changes in order to update main: -mw anritsu, awg, unit.py, config
# Conflicts: # src/qudi/gui/time_series/time_series_gui.py # src/qudi/logic/time_series_reader_logic.py
-moved to newest version of the main branch (meaning that especially instream interface changes merged) -added awg model -config wavemeter_rework -the high_finesse_wavemeter hardware module is the one from kilians pull request -new logic&gui (wavemeter_scanning; naming has to be changed) -in the timeseries logic solely a signal for the interplay is added -high_finesse_constants version from kilian
-harxware module
…e PR. Handling of wm_start_time.
… logic stop the qudi stream accordingly. -Fully enabled NaNs for the histogram process and green GUI marker
…E scanning toolchain" accordeingly.
# Conflicts: # src/qudi/hardware/wavemeter/high_finesse_constants.py # src/qudi/hardware/wavemeter/high_finesse_proxy.py # src/qudi/hardware/wavemeter/high_finesse_wavemeter.py # src/qudi/hardware/wavemeter/high_finesse_wrapper.py
…gic side -generic stop signal from time_series_reader_logic.py -formatting
…the wavemeter readout based on time-series gives a warning that the time-series data cannot be read. If the wavemeter recording is started first however (and then stopped), then the readout works fine. Code needs to be cleaned up and unnecessary functions removed. Need to also discuss whether to sync wavemeter dummy with confocal.
Solved issue with generation method parameters.
-verified that correct keywod samples_per_channels is used -included data_instream_dummy_wavemeter which is the same as data_instream_dummy but with adjusted values and sample rate.
…meter_development
There was a problem hiding this comment.
I believe read_data_into_buffer should be blocking until the requested samples are available (see the docstring in the interface). Why did you add this timeout? Can you have this timeout in your logic instead?
There was a problem hiding this comment.
I have added this timeout because if the wavemeter is either under- or overexposed the function is blocking for long time until the requested samples are available. Might make more sense to handle this in the logic but I was thinking this would concern other logic modules as well. What do you think?
There was a problem hiding this comment.
Interesting. The hardware is supposed to give NaN values during under- or overexposure. But that should not delay anything.
Could it be that you are working with automatic exposure and that the wavemeter is going to really high exposure time values upon loss of signal?
There was a problem hiding this comment.
Well, this is exactly why you also have DataInStreamInterface.read_available_data_into_buffer which only reads data that is available without waiting. It does not make much sense to me to add a timeout to the very function that is supposed to wait for all samples. This smells more like a design flaw in the logic (do not request more samples than you want to wait for, or handle it dynamically with the afore mentioned method) or the hardware module (better handling of under-/over-exposure).
Dynamical handling could look like a logic loop that is periodically checking available_samples property and only call read_available_data_into_buffer once a sufficient number of samples can be read.
There was a problem hiding this comment.
Could it be that you are working with automatic exposure and that the wavemeter is going to really high exposure time values upon loss of signal?
Yes, we are working in auto exposure mode and that is exactly the issue.
There was a problem hiding this comment.
This dummy is different from the data_instream_dummy only in minor details:
- it uses a different default sample rate
_make_counts_funcuses different scaling
I suggest to add one or more config options to data_instream_dummy to make it more flexible instead of adding a new dummy.
There was a problem hiding this comment.
This could be embedded into a documentation page on setting up this toolchain, what do you think?
There was a problem hiding this comment.
Yes definitely, at latest when the PR is ready for merge.
Description
This PR implements the functionality of the laser scanning toolchain
(wavemeterlogger)used for PLE scanning of the old core in the new core. It is based on the new wavemeter data instream hardware file developed by @qku that was merged with PR #79 and started with discussion in #59.It also contains the solution for bug #117.
Motivation and Context
The heart of this toolchain is to synchronize counts received through the independent
time_series_reader_logicwith the queried wavelength values received from the wavemeter instream hardware device and displaying this with a histogram. For this, it uses software based timing such that thewavemeter_scanning_logic_3is connected to a QT signal from thetime_series_reader_logicdelivering the counts. Upon this rate the wavemeter values are queried and interpolated onto the values from thetime_series_reader_logic.Further it provides the ability to additionally display the wavemeter values over time or solely to display the wavemeter values.
How Has This Been Tested?
It is tested and used extensively in laboratory with a remote HighFinesse WS7 wavemeter and a NI X instreamer. Further it has been tested with two
data_instream_dummyinstances (for one sample generation is matched for wavemeter values).Types of changes
Checklist:
/docs/changelog.md.(syntax, indentation, mutable default values, etc.).