pyrpl.test.test_hardware_modules package¶

Submodules¶

pyrpl.test.test_hardware_modules.test_dsp_inputs module¶

class pyrpl.test.test_hardware_modules.test_dsp_inputs.TestInput[source]¶

Bases: pyrpl.test.test_base.TestPyrpl

setup()[source]¶

teardown()[source]¶

test_input()[source]¶

pyrpl.test.test_hardware_modules.test_na_iir module¶

class pyrpl.test.test_hardware_modules.test_na_iir.TestIir[source]¶

Bases: pyrpl.test.test_base.TestPyrpl

na_assertion(setting, module, error_threshold=0.1, extradelay=0, relative=False, mean=False, kinds=None)[source]¶

helper function: tests if module.transfer_function is within error_threshold of the measured transfer function of the module

setup()[source]¶

teardown()[source]¶

test_iircomplicated_na_generator()[source]¶

This test defines a number of complicated IIR transfer functions and tests whether the NA response of the filter corresponds to what’s expected.

sorry for the ugly code - the test works though if there is a problem, no need to try to understand what the code does at first (rather read the iir module code): Just check the latest new CurveDB curves and for each failed test you should find a set of curves whose names indicate the failed test, whose parameters show the error between measurement and theory, and by comparing the measurement and theory curve you should be able to figure out what went wrong in the iir filter...

test_iirsimple_na_generator()[source]¶

test_pz_interface()[source]¶

tests that poles and real/comples_poles remain sync’ed

pyrpl.test.test_hardware_modules.test_pid_na_iq module¶

class pyrpl.test.test_hardware_modules.test_pid_na_iq.TestPidNaIq[source]¶

Bases: pyrpl.test.test_base.TestPyrpl

setup()[source]¶

teardown()[source]¶

test_inputfilter()[source]¶

tests whether the modeled transfer function of pid module with any possible inputfilter (firstorder) corresponds to measured tf

test_iq_na()[source]¶

test_na()[source]¶

test_pid_na1()[source]¶

test_pid_na2()[source]¶

test_pid_na3()[source]¶

pyrpl.test.test_hardware_modules.test_scope module¶

class pyrpl.test.test_hardware_modules.test_scope.TestScope[source]¶

Bases: pyrpl.test.test_base.TestPyrpl

Be carreful to stop the scope at the end of each test!!!

data_changing()[source]¶

test_no_write_in_config()[source]¶

Make sure the scope isn’t continuously writing to config file, even in running mode.

test_save_curve()[source]¶

test_save_curve_old()[source]¶

test_scope_rolling_mode_and_running_state_update()[source]¶

makes sure scope rolling_mode and running states are correctly setup when something is changed

test_scope_slave_free()[source]¶

Make sure the scope returns to rolling mode after being freed

test_scope_stopped_at_startup()[source]¶

This was so hard to detect, I am making a unit test

test_setup_rolling_mode()[source]¶

recalling a state with rolling mode should work.

pyrpl.test.test_hardware_modules.test_scope_asg_ams module¶

class pyrpl.test.test_hardware_modules.test_scope_asg_ams.TestScopeAsgAms[source]¶

Bases: pyrpl.test.test_base.TestPyrpl

setup()[source]¶

test_amspwm()[source]¶

test_asg()[source]¶

test_asg_to_scope()[source]¶

test_scope_duration_autosetting()[source]¶

test_scope_pretrig_ok()[source]¶

Make sure that pretrig_ok arrives quickly if the curve delay is set close to duration/2

test_scope_trigger_delay()[source]¶

Make sure taking a curve in immediately is instantaneous

test_scope_trigger_delay_not_forgotten()[source]¶

Makes sure switching from some trigger_source to immediately and back doesn’t forget the trigger_delay

test_scope_trigger_immediately()[source]¶

pyrpl.test.test_hardware_modules.test_trig module¶

class pyrpl.test.test_hardware_modules.test_trig.TestScope[source]¶

Bases: pyrpl.test.test_base.TestPyrpl

setup()[source]¶

teardown()[source]¶

test_trigger()[source]¶

Module contents¶