[NI-velmurugan]

• 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?

This PR adds nidmm_cont_acq_chart_multiple_samples.py, a Python adaptation of the LabVIEW Cont Acq & Chart Multiple Samples.vi

What testing has been done?

• Manually tested the example using simulated hardware and the real hardware

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 75.18%. Comparing base (5375937) to head (fb642b9).

❗ There is a different number of reports uploaded between BASE (5375937) and HEAD (fb642b9). Click for more details.

HEAD has 47 uploads less than BASE

Flag	BASE (5375937)	HEAD (fb642b9)
nitclkunittests	10	5
nifakeunittests	10	5
nimodinstunittests	10	5
nidcpowerunittests	10	5
niscopeunittests	10	5
nidigitalunittests	10	5
nirfsaunittests	10	5
codegenunittests	2	1
niscopesystemtests	1	0
nidigitalsystemtests	1	0
nidmmsystemtests	1	0
nirfsgsystemtests	1	0
nimodinstsystemtests	1	0
nisesystemtests	1	0
niswitchsystemtests	1	0
nidcpowersystemtests	1	0
nirfsasystemtests	1	0
nifgensystemtests	1	0
nitclksystemtests	1	0

Additional details and impacted files

@@             Coverage Diff             @@
##           master    #2220       +/-   ##
===========================================
- Coverage   88.12%   75.18%   -12.94%     
===========================================
  Files          88       42       -46     
  Lines       22830     6633    -16197     
===========================================
- Hits        20118     4987    -15131     
+ Misses       2712     1646     -1066     

Flag	Coverage Δ
codegenunittests	84.78% <ø> (ø)
nidcpowersystemtests	?
nidcpowerunittests	89.53% <ø> (ø)
nidigitalsystemtests	?
nidigitalunittests	68.43% <ø> (ø)
nidmmsystemtests	?
nifakeunittests	86.08% <ø> (ø)
nifgensystemtests	?
nimodinstsystemtests	?
nimodinstunittests	94.20% <ø> (ø)
nirfsasystemtests	?
nirfsaunittests	63.37% <ø> (ø)
nirfsgsystemtests	?
niscopesystemtests	?
niscopeunittests	43.20% <ø> (ø)
nisesystemtests	?
niswitchsystemtests	?
nitclksystemtests	?
nitclkunittests	98.26% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[NI-velmurugan]

The plotting approach in this example follows the existing gRPC Device Server example continuous-acquire-graph-multiple-points.py , which displays the continuous data with matplotlib.

[divakar-selvam07]

@jarnoldNI, the PR is ready for your review.

[ni-jfitzger]

The plotting approach in this example follows the existing gRPC Device Server example continuous-acquire-graph-multiple-points.py , which displays the continuous data with matplotlib.

Can you post a screenshot of what the plot looks like?

[NI-velmurugan]

The plotting approach in this example follows the existing gRPC Device Server example continuous-acquire-graph-multiple-points.py , which displays the continuous data with matplotlib.

Can you post a screenshot of what the plot looks like?

Thanks for pointing that out. I've attached screenshots of the plot below with additional details for clarity:

Screenshot 1: Shows the plot generated with Python example.
Screenshot 2: Shows the plot generated with LabVIEW.

Please let me know if there's any other information you'd like me to include.

[NI-velmurugan]

@ni-jfitzger, I’ve addressed the comments you mentioned. Could you please take a look and let me know if you have any additional suggestions?

[ni-jfitzger]

I think this is unnecessary.
This is a continuous acquisition, so I would view samples_to_fetch as a minimum. It should be fine to fetch more samples than needed on the last acquisition.
The only reason I would consider this worth doing is if we were managing a buffer that we need to avoid overflowing.

[NI-velmurugan]

Agreed, I removed the clamp. samples_to_fetch is now a minimum, and the last fetch may return more samples than total_samples needs.

Following your buffer point, each iteration now calls read_status() and fetches max(samples_to_fetch, backlog), capped at 100,000, the per-call maximum for a continuous acquisition. The driver docs say a growing backlog eventually overwrites data and raises an error. Fetching the whole backlog lets the chart catch up if plotting is slower than acquisition.

[ni-jfitzger]

Now, you've got me thinking about buffer allocation and looking at the C Example.
The LabVIEW Example uses a single constant value for samples__to_fetch.
The C Example has a preallocated buffer that it fetches into on every iteration of the loop, avoiding allocation of a fresh buffer every time.

Our Python implementation of fetch_multi_point is allocating a fresh buffer on every iteration, of the size samples_to_fetch. If we're concerned about keeping up with the fetch backlog, this isn't very efficient.

@marcoskirsch what are your thoughts?

[ni-jfitzger]

samples_fetched += len(new_samples)
This statement should happen before _update_chart is called. There's no reason for this function to handle updating that value.

[NI-velmurugan]

I moved samples_fetched += len(new_samples) into the main loop, before the _update_chart call. _update_chart now only draws the chart and no longer returns a value.

[marcoskirsch]

I do not think this is an appropriate example. Examples should teach clients how to use the driver API, not how to use a third party plotting library.