LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

What is the most elegant method of storing all panel control values into a cluster without affecting execution time?

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!

 

 

0 Kudos
Message 1 of 5
(762 Views)

Just form a quick glance at the picture ... (will look at the snippet later in more detail)

 

  • All your value property nodes should be replaced with locals. (property nodes execute synchronously and typically force a thread switch)
  • If you would place the control terminal labels to the left of the terminal, your vertical space requirements would be half and things could nearly align with the BundleByName terminals. (compare what you do with the indicators)
  • Some of your sequence frames could be merged.
  • You have a lot of representation mismatches between the controls and the cluster (coercion dots!)
  • Not sure why you constantly go out and back into the flat sequences. Looks just very convoluted!
  • All these "reinit to default" property nodes for booleans are just plain silly. Can't you simply use latch action instead?
  • ...
0 Kudos
Message 2 of 5
(748 Views)

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:

  • All your value property nodes should be replaced with locals. (property nodes execute synchronously and typically force a thread switch)
    I have no more property nodes in the architecture. I gutted all of that and replaced it with what you see in the "Get Software Input" Frame. I will look into this, however because I don't know anything about local variables in LabView. If this route allows me to re-implement what I did with my property nodes it would make this code base much easier to re-use in the future.
  • If you would place the control terminal labels to the left of the terminal, your vertical space requirements would be half and things could nearly align with the BundleByName terminals. (compare what you do with the indicators)
    Going to do this now. I don't know why I didn't think of this!
  • Some of your sequence frames could be merged.
    I think you are right, and will continue to be right even as I implement more of my requirements.  I liked the idea of separate frames for each step of my engine, I thought it would help me organize myself better. I will look into merging frames if possible in the future! Thank you!
  • You have a lot of representation mismatches between the controls and the cluster (coercion dots!)
    This was...on purpose. Originally my SystemRecord was going to consist entirely of double values - I was going to develop a separate tool to programmatically create the SystemRecord cluster based on entries in a CSV file to make development of future projects faster. When I saw how much additional overhead (by this I mean constantly checking for a variant's data type, casing to the appropriate data-type, converting to a 1 or 0 if Boolean) was needed when dealing with variants, I decided to make the record doubles (for all numeric values) and booleans. Is there a reason I need to worry about representation mismatches assuming I'm always dealing with double-precision?
  • Not sure why you constantly go out and back into the flat sequences. Looks just very convoluted!
    A lot of the stuff outside the frames is just for debugging and benchmarking purposes. It will be gone by the time the project is done.
  • 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...?
  • ...
    I couldn't agree more!
0 Kudos
Message 3 of 5
(699 Views)

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?

0 Kudos
Message 4 of 5
(689 Views)

@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.

Message 5 of 5
(686 Views)