LabVIEW
Concurrent Wait Time Issue to Generate Rate of Change Measurements
Solved!
Thank you. I will redesign this to use arrays. Based on others experience, what size and quantity of 1D arrays typically start burdening the computer system running LabView (assume average processing power and RAM).
The only time I ran into issues with that ptbypt data queue was my own darned fault!
<Sea Story=True>
I needed an nZ transform based on the timing or an RT target so I of course did some testing of the code. Forgeting that I was not updating the Tick Count variable. Do you know how many points you need to simulate 200mSec when the time between cycles is 0?
@dclalonde wrote:
@RavensFan wrote:
Do you want your "30 minutes ago" to always be 30 minutes ago from now?, or every 30 minutes it stores a value and then updates that after another 30 minutes has passed.
If the former, then you will need to store arrays of data. What you are doing is called a circular buffer where you continually add new data and discard the oldest, and the size of the buffer determines how far back in time you can look.
You need your data acquisition to run continuously at whatever data rate makes sense. You don't want your analysis of that data to be delayed by arbitrary "wait until next msec" functions.
Thank you. I will redesign this to use arrays. Based on others experience, what size and quantity of 1D arrays typically start burdening the computer system running LabView (assume average processing power and RAM).
This is what I came up with as a solution for the task using arrays. I would appreciate any feedback on how to do this more effectively or general programming tips since I am still quite fresh when it comes to LabView. Thanks!
@dclalonde wrote:
Here are two tips that will simplify the code you have.
1. You are using two different index array functions on the same array. Delete one. Drag down the bottom border of the other. You'll get another output from the same array. If you leave the index input unwired, you get the next item in line. If you wire in something, then you'll get that index value you asked for.
2. You are using Insert Into array at position "i". Normally that means you are just adding to the end of the array. In that case, using Build Array in concatenate mode makes much more sense. Why worry about wiring in the Insert point if you know it is always at the end. But your implementation has a larger problem. How many elements are in that 1-D array you are "inserting" in? If it is more than 1, then you are scrambling your data. For the sake of argument, I'm going to say that array as 3 elements, and I'm going to give them letters.
Start of loop, array is empty, i=0. Insert 3 A's at 0 and you'll have AAA
Next iteration, i=1, Insert 3 B's at 1. You'll get ABBBAA.
Next, i=2, Inset 3 C's at 2, You'll get ABCCCBBAA
Next i=3, Insert 3 D's at 3 You'll get ABCDDDCCBBAA
Do you see the problem?
If you used Build array, you'd have AAABBBCCCDDD, all the elements in order, no matter how many there were in each 1-D array when they were captured.
I appreciate this. I will make these changes and let you know if anything problematic occurs because of my inexperience. My array is only receiving one element per iteration so that is why I did not notice the larger problem. Would "Split Signal" to another similar arrangement work as well should I decide to add additional channels and inputs to help keep them separated for my purposes?
@RavensFan wrote:
@dclalonde wrote:
Here are two tips that will simplify the code you have.
1. You are using two different index array functions on the same array. Delete one. Drag down the bottom border of the other. You'll get another output from the same array. If you leave the index input unwired, you get the next item in line. If you wire in something, then you'll get that index value you asked for.
2. You are using Insert Into array at position "i". Normally that means you are just adding to the end of the array. In that case, using Build Array in concatenate mode makes much more sense. Why worry about wiring in the Insert point if you know it is always at the end. But your implementation has a larger problem. How many elements are in that 1-D array you are "inserting" in? If it is more than 1, then you are scrambling your data. For the sake of argument, I'm going to say that array as 3 elements, and I'm going to give them letters.
Start of loop, array is empty, i=0. Insert 3 A's at 0 and you'll have AAA
Next iteration, i=1, Insert 3 B's at 1. You'll get ABBBAA.
Next, i=2, Inset 3 C's at 2, You'll get ABCCCBBAA
Next i=3, Insert 3 D's at 3 You'll get ABCDDDCCBBAA
Do you see the problem?
If you used Build array, you'd have AAABBBCCCDDD, all the elements in order, no matter how many there were in each 1-D array when they were captured.
