XY graph multi plot with single x and multiple Ys

[altenbach]

Here's a simple way to accumulate the data in a shift register and display it as it arrives.

(Note that this is literal refactor of your VI, same functionality and timing. I am sure you can adapt your real code in a similar fashion.

[edmonton]

Hello  altenbach,

Your sample VI is exact one I am looking for. 

Thank you very much.

Gu

[edmonton]

Hi GerdW,

Thank you for your suggestion. I have enqueue/dequeue in my program to separate data collection and display. I found that writing data to spreadsheet runs much faster in producer loop with data collection than in consumer loop with data display. I have not tried to have data logging in an independent consumer loop. 

Regards,

Gu

[edmonton]

Hi  altenbach,

One more question to trouble you. 

Can you please provide a comment on selection of serial or parallel structure for multiple similar program instances?

Taking the XY graph with multiple plots with single x and multiple Ys as an example,  first we used 3 parallel instances to select random numbers greater than 0.5, 0.75, and 0.95 respectively, then we changed to use a for loop to do a random number select at each iteration, meaning a serial operation to do the same task.  Of course, the code for the serial option is much compact and easy to read.

My question is which option runs more efficient programmatically. or which option runs faster?

There may not be a significant difference between serial and parallel options for the example of the random number selection, as it's logical is simple for any option. We may see significant difference when we keep them running for a long time. And for my application, I need to have 50-100 streaming data per second for each of 8 channels running for 10-15 minutes.

Best regards,

Gu

[altenbach · Accepted solution]

---

@edmonton wrote:

My question is which option runs more efficient programmatically. or which option runs faster?  

---

There is no significant difference here because there is so little code. Yes, if you have a CPU with >3 full cores, LabVIEW might run the three segments in parallel gaining you a nanosecond or so, but that's not guaranteed either. The compiler is extremely smart and there is even a good chance that both versions generate very similar machine code. It is always highly recommended to keep the code as simple as possible because there are fewer places for bugs to hide. In your case you have 3 different instances of the "greater than" and there is a nonzero chance that one of them is a "less than" by accident. Also if you later want to change the code slightly, you would need to make identical changes in three different places: 3x more work and 3x more chances to make mistakes. 😮

In terms of performance optimizations, other parts of the code would require significantly more attention because they are potentially orders of magnitude more serious. For example building arrays in shift registers is a much more severe problem because of the need for incremental memory allocations. If the problem allows, significant improvements are possible here, for example if the final size of the arrays is known (here it's 100!) they could be initialized at the final size with NaNs, replacing elements with new data as it arrives. You could also build the array in a different way to avoid the transpose operation.

All this is worth considering once the data structures are significantly larger than here but you need to have a deep understanding to know where to focus the optimization efforts.

[edmonton]

Hi altenbach,

You really provided a deep thought in optimization of a program. I think you are very skillful in LabVIEW.  Combining auto index and stop directly at condition as well as XY graph with single X and multiple Y makes the coding so compact and artful, I mean fine art.

In my case, I know the max sizes for the 1D and 2D arrays,  I have changed the two types of arrays using array initialization to declare their max sizes. It is difficulty to directly build an array to the format that can be directly used for single x multiple Y graph. So, we have to use transpose. 

In LabVIEW, 1D array can be a raw or a column, there is no difference between the two. What if we have 1D raw array different from 1D column array as the attached example,  and allowed to build a 2D array as illustrated, 1D raw array to form a raw appending and 1D column array to form a column appending, we would not need to use a transpose operation in many cases. 

I hope that NI should use the way you do XY graph with single X and multiple Y as a standard function. This is really a frequently needed function in multiple channel data acquisition.

Best regards,

Gu

[edmonton]

ooops, the attachment

[edmonton]

Hi altenbach,

I encountered a new issue with the XY-graph after replacing the dynamic 1D and 2D arrays with fixed size arrays.

1. The array sizes are changed to be the same value as the for loop iteration limit, which is 10,

2. The build arrays are replaced using replace arrays and indexed to iteration, the loop counter

3.  The for loop's iteration limit  for the XY graph is also wired to the loop count. 

The issue is that the graph loop ignores the loop count as its loop limit, it takes the array full size as its iteration limit, graphing with all the zeros that have not been replaced. The chart is not correct till all zeros are replaced at the last iteration. see the attached vi.

Is there any way to get out of the issue?

Thanks,

Gu

[altenbach · Accepted solution]

1. Initialize the arrays with NaN so they won't graph
2. Don't wire N to any of the inner FOR loops. Autoindexing takes care of it Both loop counts are fixed at 3, i.e. the number of traces)
3. Make it scalable instead of using redundant information (make all sizes dependent on the number of traces!)

[edmonton]

Hi altenbach,

Thanks.

It's my first time to learn and use NaN constant. I searched NI web for NaN constant definition and found a old post showing it is in numeric palette, I did not find it in my 2015 LV. any way I typed it in and it works.

Best regards,

Gu