how can table execution be optimized?

[altenbach · Accepted solution]

---

@Sidkay wrote:

i need the index values to change with every new packet that VISA reads with every iteration but the loop rate is very low that it misses many packets by the time next iteration begins... i have used 6 instances of set cell value as i am using 6 different columns...

---

So does each loop iteration add a row at the bottom, every time with the same number of columns?

My question is about the desired loop rate, not what you are seeing. To ensure that no data is missed, you might need a produce consumer architecture.

In any case, here's a simple way to append rows forever to a string array, but only display the last N element. You still need to handle the case when the array in the shift register grows forever. You might just want to stream the data to disk instead of wasting more and more memory.

Here's a very rough draft that at least keeps the front panel data at a minimum.

[Artem.SPb]

---

@altenbach wrote:

---

@Artem.SPb

You cannot replace elements in an empty array. The SR need to be initialized with a 2D array of strings at the full final size.

---

altenbach, don't be a bore.
This is just an example.
And formally there are no mistakes. I replace the ZERO elements in the EMPTY array. Everything is correct.

[altenbach]

---

@Artem.SPb wrote:

And formally there are no mistakes.

---

I disagree. "Formally" (whatever that means) the code does not provide any functionality that is useful to answer the question. Code that replaces nothing in an empty array has little practical use. You might as well post an empty diagram. Same difference, less effort. 🙂

It is a disservice to post broken, non-functional code. Users that need the example will not be able to get it to work  because there are too many things wrong. Users that could fix it, don't really need it.

Examples must be runnable and exhibit the desired functionality, or require detailed explanations if that's not possible.

[Artem.SPb]

Altenbach, I see you have a lot of time for idle talk.
You teach Sidkay ask questions, teach me how to answer, but in fact did not do good examle. And I just showed an example of HOW to update the data in the table.
Keep up the best work, and I continue to work.
And yes, you can also criticize my English, I'm sure there are also a lot of mistakes.

[Sidkay]

yes every loop iteration adds a row at the bottom with the same no of columns.... ur provided VI was actually helpful, thank u... i have removed all the set cell value method nodes and have edited the 2Darray before it enters the table... the loop rate had improved alot... but still not ideal enough to pick every data packet with every loop iteration... i used producer/consumer design pattern and worked absolutely perfect thank u 🙂

[altenbach]

---

@Sidkay wrote:

yes every loop iteration adds a row at the bottom with the same no of columns.... ur provided VI was actually helpful, thank u... i have removed all the set cell value method nodes and have edited the 2Darray before it enters the table... the loop rate had improved alot... but still not ideal enough to pick every data packet with every loop iteration... i used producer/consumer design pattern and worked absolutely perfect thank u 🙂

---

Your image is not very helpful to give further advice, because you don't even show how the table is built. I try anyway :D. Again we see blatant overuse of local variables and the least interesting (empty!) case of a case structure. What's in the TRUE case? If you want to keep the data at a certain size, you should probably operate on the array inside the shift register. This case structure runs in parallel to everything else in that loop and we cannot know if it occurs before or after the table has been updated, a clear race condition! Why is the indicator for the number of rows called "elements 2"? Give it a better name for readability. Why is the same formatted HEX string still split to 6+ different locations? Couldn't some of these operation be combined? I am sure we can help you to significantly improve large parts of your code further if you would just show it to us! From the small section visible, It looks very difficult to expand, maintain, and debug.

Yes, you at least show parts of the the two-loop producer/consumer architecture, but even here we can give recommendations for improvements. It is customary to arrange loops running in parallel vertically. Side-by-side should be reserved for sequential execution. Why are wires from one structure disappearing below the other structure? Why are you piping an empty string through the entire analysis procedure if there is a queue error? You can probably skip most of the code if that occurs. If you would wire the boolean coming from the bottom through the "no error" case and shared with output from the "error" case, you could eliminate the OR above. etc. etc. Just some random talking points. 😄