how to update table control at a faster rate in a state machine

[shaunmarsh123]

Hello, i am working on a bus analyzer application where i am doing serial data parsing at a baud rate of 115200. i am using state machine to achieve this task , after extracting multiple information from the incoming packets, i need to display it on the table control in different columns.I am testing my application by sending fixed amount of packets from the hardware to my application. The problem which i am facing is , that if i test my application on a smaller number of packets , lets say 5000 , then my program runs perfectly and information coming from all of the packets is displayed on the table control, but when i am increasing the packet count to lets say 10000 , then i am missing out a large number of packets. The problem lies in updating the table, which makes my code slower and then i miss out on some packets. As soon as i disable updating my table control , my code is able to capture all 10000 packets.Please help me, is there any faster way to update table control so that it doesn't create a bottleneck when i am testing my application for a larger number of packets.

[altenbach]

How many fields in the table control? Displaying at a fast rate is pointless, because you won't be able to read it anyway.

You only give the number of packets, but no timing information. How many per second?

The UI thread (tables, etc.) are updated in the UI thread, not synchronous to the rest of the code.

Why does it need to be a table control? How are the fields formatted?

Can you show us some simplified code?

[shaunmarsh123]

The delay between each of my incoming packets is 1 ms . I am attaching screenshot of front panel view and block diagram implementation , where i am updating the table after verifying checksum.

[altenbach]

It's hard to tell form a heavily cropped picture, but you seem to grow the array without upper size limit (now sure why you are using "insert into array" instead of "built array", not very natural). You also seems to be a fan of local variables, typically a sign of poor code structure. Where are the terminals?

We probably could give better advice seeing the entire VI.

How big does the table get? Does it grow without limits?

Typically, a much better approach would be to use a fixed size 2D array and replace rows with new data. You also only need to update the visible elements, not the entire table.Use a separate scroll control and pick the rows to display based on it.

[shaunmarsh123]

 The number of rows of the table need to grow without limits. Can u kindly help me how can i implement your method which u mentioned in the last paragraph. I'm very new to labview , so can u please post a screenshot or post a VI of your mentioned technique.

[altenbach]

---

@shaunmarsh123 wrote:

 The number of rows of the table need to grow without limits.

---

That will only work if you have unlimited memory. Do you?? (nobody else has!) Your specifications need to be reasonable!

---

@shaunmarsh123 wrote:

Can u kindly help me how can i implement your method which u mentioned in the last paragraph. I'm very new to labview , so can u please post a screenshot or post a VI of your mentioned technique.

---

As you saw from your picture, screenshots of code are useless. We typically work on VIs. The method should be quite clear and simple, but I don't have time at the moment to program it up. Too late here. Maybe somebody else can help?

[GerdW]

Hi shaun,

is there any faster way to update table control so that it doesn't create a bottleneck when i am testing my application for a larger number of packets.

Well, sure.

Most programs I work with use this kind of technique: they only update the display once or twice a second, but not for each new data element they receive!

So keep collecting your data in this 2D array, but limit it's size to reasonable amounts. Display that array at a regular interval in the table indicator (and only when there is new data available…)

I was hoping you learn from all the answers you got in your other threads, but to me it seems your VI is getting worse and worse…

[Ben]

Been there done that!

1) Reduce the amount of data displayed with a reasonable limit. Let the user stop test and back if needed.

2) Reduce the frequency of updates, let them pile up and apply updates as a group.

3) DO not ignore what others have posted above.

4) Use "defer.FP.Update" to defer redraws before updating the table and then under-defer after.

5) Develop code to make it LOOK like you have full table. After all there is a limit to how much can be seen at one time.

The last time I had to do one of these types of apps, I used an Action Engine to cache the data and only took a small portion of the buffer to update the display.

Ben

[altenbach]

If you want to extend the "unlimited size" to work for a little bit longer, pad the "packets" to a fixed length delimited by \n and stream them to disk.

Instead of a "table", use a plain string indicator (configured with a fixed width font such as e.g. "consolas"). Use the fake scroll control (as already suggested earlier) to random access a small fraction of the file data to fill the indicator. (since the packets are fixed width, the file offset for any particular packet can be calculated directly. Similarly, the length can be calculated from the number of packets you want to retrieve. Never needs to be more than what's the visible area of the plain string indicator!