val_mapping creator function to solve on/off/true/false issue

[nataliejpg]

Fixes #924

I made a function which given the instrument values for 'on' and 'off' maps all the obvious inputs (1, True, 'On', 'on', 'ON') to on and off. The inverse always maps back to booleans which I chose relatively arbitrarily as 'the most sensible' to be the convention. Happy to extend it if more are voted for.

Also, Implemented in the rhode schwarz SGS100A for now but I imagine other drivers would also benefit from it.

TODO:

• Test
• Add a note about it to driver creating notebook doc
• Use in other drivers?

@WilliamHPNielsen @jenshnielsen

[codecov]

Codecov Report

Merging #1413 into master will increase coverage by 0.02%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master    #1413      +/-   ##
==========================================
+ Coverage   73.86%   73.88%   +0.02%     
==========================================
  Files          92       92              
  Lines       10411    10420       +9     
==========================================
+ Hits         7690     7699       +9     
  Misses       2721     2721

[astafan8]

I've refactored the code, and added tests.

Questions:

• What other "sensible" on/off inputs we need?
• Do we also need enabled/disabled val mapping? Or shall that case be strongly recommended to be True/False and parameter should always be called smth_enabled so that the API is smth_enabled(True)?

[jenshnielsen]

• I think this is fine
• I vote for leaving that out for now

[astafan8]

@QCoDeS/core ready for review.

Question: shall i also go through all drivers quickly and use this new function in cases where it makes sense and does not break instrument-driver's API?

[astafan8]

@nataliejpg as the original author of the PR and the main feature requester, could you also have a look? :)

[nataliejpg]

looks good to me @astafan8, thanks for the work. I didn't understand your question:

Do we also need enabled/disabled val mapping? Or shall that case be strongly recommended to be True/False and parameter should always be called smth_enabled so that the API is smth_enabled(True)?

[astafan8]

@nataliejpg

I didn't understand your question:

Do we also need enabled/disabled val mapping? Or shall that case be strongly recommended to be True/False and parameter should always be called smth_enabled so that the API is smth_enabled(True)?

I also don't really remember :( I think it was about parameters which have enabled/disabled meaning which might probably be different from on/off meaning in some cases (definitely not in this PR's rhode schwarz driver), if we need a create_en_dis_abled_val_mapping function of some sort.

But now i think we don't, and also this question of mine is a bit "stupid" :)

[Dominik-Vogel]

I this PR is sensible, clean, and good to go