nulinspiratie / SilQ

Software for quantum control of donor atoms in silicon
Other
6 stars 1 forks source link

AlazarTech, ATS9440 digitizer crashes #213

Open RostyslavSavytskyy opened 4 years ago

RostyslavSavytskyy commented 4 years ago

AlazarTech, ATS9440 digitizer crashes very often when you run long measurements with many repetitions and long pulse sequences. For example, if you run EDSR (flip-flop) spectrum scan with 0.6s pulse sequence, Alazar crashes after approx. 30 repetitions, where each repetition had approx. 80 frequency points. If you run EDSR (flip-flop) Rabi measurement of similar (varying) pulse sequence duration, it crashes already after only 2-4 repetitions, where each repetition had 50 pulse duration points (from 0 to 200us). The main error message it shows in this case is: "RuntimeError: ('error 513: ApiFailed from function AlazarPostAsyncBuffer with args: [3504, 2148532224, 230400]', 'getting triggered_controller_acquisition', 'getting ENDOR_EDSR')"

Upon closing of the instruments in SilQ (Instrument.close_all()), it shows a message: "Buffer prevented memory leak; Memory released to Windows. Memory should have been released before buffer was deleted. Buffer prevented memory leak; Memory released to Windows. Memory should have been released before buffer was deleted."

Recently, we found out that this error/crash does not happen if we do not plot measurement results actively in the measurement notebook. Instead, we load the data and plot them in the analysis notebook. By applying this method we have not yet seen any more crashes with Alazar card.

Similar issue was present in Aachen when Tim was measuring and they resolved this in the same manner - by plotting separately on a different PC.

To summarize, currently the measurements are run in a way that we plot separately and we can of course adjust ourselves to this style of measurements, but it would still be beneficial to find a possible fix.

nulinspiratie commented 4 years ago

The memory leak message makes sense, because the acquisition failed before the buffer memory has been freed.

One thing I can imagine is that for long traces it takes longer to load the trace, and it might be too slow. As a test, can you increase pulse_sequence.final_delay to something like 100 ms? And keep plotting