12-31-2021 05:22 PM
Hi Everyone,
I'm writing a general purpose data acquisition engine. Speed is important for this project, and I'm targeting a 100Hz frame rate [or faster].
Previously, I created a nice process that grabbed references to all of the controls in the VI stuffed them into an array, and passed the array to a sub-vi that iterated through them, pulled their values, and wrote them to a cluster reference. Controls and cluster elements shared identical names so I used that as a map to determine which control's data goes to which cluster element.
The problem is that if include even a single property node in my main frame, my execution time tanks hard.
In the snipped I've attached [WIP]; this seems to be the fastest way to grab data from the controls and bundle them up into my cluster, but it takes up so much space and makes this VI very large. This flat sequence's first frame is going to get larger and larger as I implement more of my requirements. I want to get ahead and find a better way to do this that helps me keep this top-level VI compact.
My only requirements here are speed, and that the cluster be updated at the same time in each frame. I don't want the cluster's value to update arbitrarily during the frame's execution.
If anyone has a better method, I'd love to hear it.
Thank you in advance for any help! Happy New Year!
12-31-2021 06:18 PM
Just form a quick glance at the picture ... (will look at the snippet later in more detail)
01-01-2022 01:59 PM
Altenbach this is all good info, thank you. I apologize, I'm new to LabView and I'm using a lot of this stuff for the first time.
I will respond to your comments one-by-one:
01-01-2022 04:23 PM
I just realized that I do in fact have two property nodes in this VI, both are values for two software triggers. How come these don't affect performance, but when i use property nodes that require a control or variable reference, everything slows down dramatically?
01-01-2022 04:34 PM
@cslowa wrote:
- All these "reinit to default" property nodes for booleans are just plain silly. Can't you simply use latch action instead?
They actually are set to latch. I've noticed that sometimes they do not go back to their original state on program exit so i did this to ensure they do. Not sure if this is something I'm doing wrong or...?
Latch action booleans will reset next time they are read by the code. If yours don't reset, it means the terminals are placed wrong. For example for events, the terminal typically belongs inside its respective event case so it resets when the event fires. If you would place the terminal on the toplevel diagram outside the main loop or inside a rare case structure frame, they might never get read again by the code and thus will never reset.