Repository navigation
Adding Continuous Acquisition Chart Multiple Samples example in NI-DMM - #2220
NI-velmurugan wants to merge 20 commits into
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests.
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
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
|
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. |
|
@jarnoldNI, the PR is ready for your review. |
| try: | ||
| with session.initiate(): | ||
| # A fetch_count of None runs until the chart window is closed or Ctrl+C is pressed | ||
| while plt.fignum_exists(figure.number) and ( |
There was a problem hiding this comment.
Intentionally skipped the LabVIEW STOP button behavior to keep the example simple.
The loop stops when the chart window is closed or Ctrl+C is pressed.
There was a problem hiding this comment.
There's certainly precedent for leaving out something like in our Python examples.
niscope_fetch_forever.py terminates its fetch while loop after fetching after a configured number of samples.
This, like that, is a continuous acquisition, so perhaps we should use a similar termination mechanism?
Does your current code update the graph continuously?
There was a problem hiding this comment.
Similar to niscope_fetch_forever.py, we now have a termination mechanism using total_samples. The user can configure the total number of samples to acquire, and the acquisition will stop once that count is reached.
If total_samples is not specified, the acquisition will continue until the user terminates it by pressing Ctrl+C or closing the chart window.
Please let me know if this aligns with what you had in mind.
Does your current code update the graph continuously?
Yes, the graph is updated continuously as new measurements are fetched. After each fetch, the newly acquired measurements are added to the chart, and the graph is refreshed to display the latest measurements. The chart maintains a rolling window of the most recent 250 measurements.
There was a problem hiding this comment.
Yeah, this seems to do basically the same thing.
Not sure how well it meshes with the plotting (the graph may disappear before the user can view it, in practice), but users don't have to pass a value and you've defaulted to keeping the graph open.
There was a problem hiding this comment.
Thanks for the feedback. The chart won't disappear when total_samples is reached. After the acquisition stops, the example calls plt.show(), which keeps the final chart on screen until the user closes the window. If total_samples is omitted, it runs until the chart window is closed or Ctrl+C is pressed.
Please let me know if you'd like any changes to this behavior.
NI-velmurugan
changed the title
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. Please let me know if there's any other information you'd like me to include. 
|
| figure, axes = plt.subplots() | ||
| (line,) = axes.plot([]) | ||
| axes.set_title('Measurements') | ||
| axes.set_xlabel('Samples') | ||
| axes.set_ylabel('Measured value') | ||
| axes.grid(True) |
There was a problem hiding this comment.
All this matplotlib stuff feels like a distraction from the demonstration of how to use nidmm. @marcoskirsch what do you think?
There was a problem hiding this comment.
It seems a bit more involved than what we did for the nidaqmx examples:
- https://github.com/ni/nidaqmx-python/blob/master/examples/analog_in/voltage_acq_int_clk_plot_data.py
- https://github.com/ni/nidaqmx-python/blob/master/examples/analog_in/voltage_acq_int_clk_plot_wfm.py
But that might be because it's doing a chart rather than a single graph.
There was a problem hiding this comment.
The intent was to demonstrate continuous acquisition by fetching measurements in batches and displaying them on a live-updating chart. While this adds some complexity compared to plotting a single acquired dataset, I believe the current implementation is a reasonable approach for demonstrating continuous acquisition and live chart updates.
There was a problem hiding this comment.
To keep the nidmm usage front and center, I moved all matplotlib code into two private helpers, _create_chart() and _update_chart(). example() now shows only the NI-DMM flow: configure a continuous acquisition, initiate, then fetch batches with fetch_multi_point(). The chart is updated with a single _update_chart() call per batch. Readers can ignore the helpers when learning the driver API.
|
@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? |
| # The last fetch only takes the samples still needed to reach total_samples | ||
| samples_in_this_fetch = samples_to_fetch | ||
| if total_samples is not None: | ||
| samples_in_this_fetch = min(samples_to_fetch, total_samples - samples_fetched) |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
|
|
||
| def _update_chart(plt, axes, line, measurements, new_samples, samples_fetched): | ||
| measurements.extend(new_samples) | ||
| samples_fetched += len(new_samples) |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
- [ ] I've added tests applicable for this pull requestWhat does this Pull Request accomplish?
This PR adds
nidmm_cont_acq_chart_multiple_samples.py, a Python adaptation of the LabVIEWCont Acq & Chart Multiple Samples.viWhat testing has been done?