search

Exopy / exopy_hqc_legacy

Transition package to smooth transition from HQCMeas to Exopy.
BSD 3-Clause "New" or "Revised" License
0 stars 9 forks source link

No timeout when acquisition card bugs #44

Open lcontami opened 6 years ago

lcontami commented 6 years ago

For example when you forget to turn on the modulation signal, the card can't demodulate (simply can't even trigger) but the program just stays stuck without returning an error or timeout at some point.

MatthieuDartiailh commented 6 years ago

Indeed this does not appear to be supported at the moment. I believe the best would be to have a timeout before acquisition starts (after it can last as long as necessary). Help welcome.

lcontami commented 6 years ago

Sometimes the card also seem to bug in the middle of the measurement at one point (for no reason that I can see), and never returns an error. I will try to understand what is happening tomorrow to see which correction could fix that.

lcontami commented 6 years ago

the driver should also catch memory overflow and raise an error. It looks like it does not for now

https://spdevices.com/images/stories/user_guides/14-1351_ADQAPI_Reference_Guide.pdf references a GetStreamOverflow method.

It would additionnaly be nice to add in the driver the trigger limit (it is at .5V per default, I think this information could be written in the driver, what do you think ?)

MatthieuDartiailh commented 6 years ago

I believe both changes would be reasonable. The question would be when to check for Overflow we do not want to do that too often.

Billthered commented 4 years ago

Sometimes the card also seem to bug in the middle of the measurement at one point (for no reason that I can see), and never returns an error. I will try to understand what is happening tomorrow to see which correction could fix that.

A likely related issue occurs occasionally in the middle of measurements during DemodSPTask with ADQ14. Observed it when using 'avg_before_demod'.

Traceback:

>   File "C:\Users\hqc\.conda\envs\exopy\lib\site-packages\exopy\tasks\tasks\decorators.py", line 86, in decorator
    return function_to_decorate(*args, **kwargs)
  File "c:\users\hqc\documents\tino\exopy_hqc_legacy\exopy_hqc_legacy\tasks\tasks\instr\spdev_tasks.py", line 200, in perform
    freq, cosin, sinus, ch1_i, ch1_q = treat_channel_data(1)
  File "c:\users\hqc\documents\tino\exopy_hqc_legacy\exopy_hqc_legacy\tasks\tasks\instr\spdev_tasks.py", line 188, in treat_channel_data
    ch_i_av = 2*np.mean(ch*cosin)
ValueError: operands could not be broadcast together with shapes (50000,500) (50000,)

It seems that for some reason, either the acquisition card does not work properly (this occurs randomly) or resizing does not work in driver.get_traces. Then the array of traces that is returned is not of good dimensions (should be 2 in 'avg_before_demod' with 2 channels, dim1 ->channels, dim2 -> samples). After the call to driver.get_traces in perform of spdev_tasks.py, during treat_channel_data(.), an error occurs line 188 ch_i_av = 2*np.mean(ch*cosin) for example

ValueError: operands could not be broadcast together with shapes (50000,500) (50000,)

where here 50000 was the number of traces and 500 the number of samples. The shape of cosin, given by nsamples defined line 172 nsamples = np.shape(ch)[0]

looks wrong. Indeed in 'avg_before_demod' ch should be dimension 1, but seems to be 2 here. I believe that treat_channel_data(index) works fine but driver.get_traces has the unexpected behavior of returning a larger array.

I could not see what is causing the issue of size. Any idea? Or would it be acceptable to add a check on the size of the returned array ?

MatthieuDartiailh commented 4 years ago

@Billthered Could you share a typical configuration file exhibiting this issue ? I will try to have a look this week-end or next week.

MatthieuDartiailh commented 4 years ago

The issue comes from https://github.com/Exopy/exopy_hqc_legacy/blob/master/exopy_hqc_legacy/instruments/drivers/dll/sp_adq14.py#L250 After a failure, we retry once but we do not pass the value of average which defaults to False hence the issue. Passing the average value would help. Making retry a counter rather than a bool may also make sense to allow than one retry. Please confirm that the fix in #68 address the issue and I will merge.

Billthered commented 4 years ago

Great ! As this occurs occasionally only (likely one out of 1.000.000 calls) I guess the best is to start a long measurement over the WE and see whether this happens again, I will be able to tell very soon! Thanks a lot @MatthieuDartiailh !

Billthered commented 4 years ago

No fail over 10 billion traces over the WE. It seems fine and can be merged !