Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add fetch_capture_waveform() fancy wrapper #1096

Closed
wants to merge 26 commits into from

Conversation

texasaggie97-zz
Copy link
Contributor

  • This contribution adheres to CONTRIBUTING.md.
  • I've updated CHANGELOG.md if applicable.
  • I've added tests applicable for this pull request

What does this Pull Request accomplish?

  • Create a "fancy" wrapper around fetch_capture_waveform_u32()
    • Returns array of named tuples Measurement(data, site)
    • Gets site list and uses that when creating named tuple

List issues fixed by this Pull Request below, if any.

What testing has been done?

  • Visual inspection

@codecov
Copy link

codecov bot commented Nov 6, 2019

Codecov Report

Merging #1096 into master will not change coverage.
The diff coverage is n/a.

Impacted file tree graph

@@           Coverage Diff           @@
##           master    #1096   +/-   ##
=======================================
  Coverage   89.99%   89.99%           
=======================================
  Files          20       20           
  Lines        3679     3679           
=======================================
  Hits         3311     3311           
  Misses        368      368

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 004c7ae...2250729. Read the comment docs.

@texasaggie97-zz texasaggie97-zz changed the title Add fetch_capture_waveform() fancy wrapper [#1086] Add fetch_capture_waveform() fancy wrapper Nov 6, 2019
@texasaggie97-zz texasaggie97-zz changed the title [#1086] Add fetch_capture_waveform() fancy wrapper Add fetch_capture_waveform() fancy wrapper Nov 11, 2019
Copy link
Member

@marcoskirsch marcoskirsch left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is a lot of diff noise in this PR.
I'd like to get rid of unrelated changes, and ideally do the metadata updates in their own earlier PR. Thanks!

Comment on lines +1571 to +1572
- **site** (int)
- **data** (array.array of int)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if named tuple of int/array of int is the best way to return this.
What are all the places in the API in which this type could be used? Can it ever be an input?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's used in two places:

  1. niDigital_SortSiteResultsViUInt32Waveform - This will NOT be added in Python, since its use is superseded by multi-instrument sessions.
  2. niDigital_WriteSourceWaveformSiteUniqueU32 - This should use the same type as what we use here for fetch_capture_waveform. Tracked here.

I looked at one of the use-cases for fetch_capture_waveform - streaming capture waveform data from h/w test program. It would be ideal for fetch_capture_waveform to accept a buffer and populate that with the waveform data (like fetch_into in niscope).

But the streaming use-case is not common and even then the size is about tens of MBs. If we learn about a use-case where performance is not sufficient, we can add fetch_into later. Usability of streaming with fetch_capture_waveform that returns a dict is not bad:

# Pattern burst is configured to fetch 1024 samples
 num_samples_expected = 16
 samples_per_fetch = 4
 waveforms = collections.defaultdict(list)
 for i in range(num_samples_expected // samples_per_fetch):
     fetched_waveform = multi_instrument_session.fetch_capture_waveform(site_list='', waveform_name='capt_wfm', samples_to_read=samples_per_fetch, timeout=10.0)
     for key in fetched_waveform:
         waveforms[key] += fetched_waveform[key]

So, now the question is whether to use dict or namedtuple..

One drawback for dict is iteration order is not deterministic (at least in Python 3.5). It looks like in 3.6 and later, iteration is ordered. Either way, I think it's better to not guarantee any order, because trying to do that is little tricky:

If method is called with site='' then the order will 0,1,2... with disabled sites skipped.
If method is called with site='3,0,1' (crazy but allowed), then the order will be 3,0,1 with disabled sites skipped.

Given that order depends on input and also can contain gaps, users should not really rely on order. Even if they want to iterate in a particular order, it's not difficult to do that in Python (Everything's easy in Python )

In summary, the recommendation is dict(int, array of unsigned int)

:return:


List of named tuples with fields:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is the order important?
Maybe it would be nicer for clients to return a dictionary of site -> data?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See answer above.

TL;DR - dict is better.

@@ -2114,7 +2174,7 @@ get_site_results_site_numbers



:type site_result_type: int
:type site_result_type: :py:data:`nidigital.SiteResult`
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This does not appear to be related to this PR.

@@ -1543,16 +1535,14 @@ perform_short_cable_comp
Performs the short cable compensation measurements for the current
capacitance/inductance range, and returns short cable compensation
**Resistance** and **Reactance** values. You can use the return values
of this method as inputs to :py:meth:`nidmm.Session.ConfigureShortCableCompValues`.
of this method as inputs to :py:meth:`nidmm.Session.configure_short_cable_comp_values`.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These does not appear to be related to this PR.

@@ -371,12 +371,10 @@ close
deallocates any memory resources the driver uses. Notes: (1) You must
unlock the session before calling :py:meth:`niswitch.Session._close`. (2) After calling
:py:meth:`niswitch.Session._close`, you cannot use the instrument driver again until you
call :py:meth:`niswitch.Session.init` or :py:meth:`niswitch.Session.InitWithOptions`.
call :py:meth:`niswitch.Session.init` or :py:meth:`niswitch.Session.init_with_options`.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This does not appear to be related to this PR.


waveforms = []

if sys.version_info.major >= 3:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@MrDuff8 when can we drop Python 2.7?

@texasaggie97-zz
Copy link
Contributor Author

I have moved this to a new PR to no longer include extraneous changes.

See #1112

@texasaggie97-zz texasaggie97-zz deleted the bug1076/add_fetch_capture_waveform_u32 branch November 13, 2019 18:58
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

fetch_capture_waveform_u32 missing in nidigital API
3 participants