LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Best practice using clusters to create queue/notifier/bundles ?

Solved!
Go to solution

I have in a block diagram a queue, notifier and several instances of bundle cluster

that all use the same data structure.   There is a cluster typedef for the data structure.

Of course, each of these objects (define queue, define notifier, bundle)

need to know how the cluster is defined.


What is considered best practice?

 

1) create a dummy instance of the cluster everywhere the data structure

    definition is needed (and hide them all on the FP)

 

2) create only one instance and wire it to all the places it is needed

   But there is no data flow on this wire -- it's only the cluster *definition*

   that is being used, so this would seem to clutter up the BD unnecessarily.

 

3) Create only one control instance of the cluster and use local variables

    everywhere else the cluster definition is needed.  It's _value_ is never

    assigned or read so there's no issue with race conditions.

 

4) Some other way?

 

If you had to clean up someone else's code, how would you hope to

see this handled?

 

It occurred to me in the course of writing this that where I have

"unbundle... code ... bundle" I could wire the original bundle to 

both "unbundle" and "bundle" -- but would this be too confusing

and clutter the BD with unnecessary wire ?

 

Thanks and Best Regards,

 

-- J.

 

 

Message Edited by JeffBuckles on 11-06-2008 03:17 PM
Message 1 of 9
(6,029 Views)
Solution
Accepted by topic author JeffBuckles

Hi Jeff,

      I think this question is regarding how to "share" the typedef and not how to share data(?)  If the cluster control is saved as a typedef (or strict typedef) but NOT SIMPLY AS A CONTROL, then when a diagram-constant of the typedef is created, it will be updated when you update the typedef .ctl !  (and there's no FP control to hide Smiley Wink )  Of course if the typdef is already available "near" where needed, you may be able to use that instead - saving some diagram spacer.

 

Cheers.

Message Edited by tbd on 11-06-2008 04:40 PM
"Inside every large program is a small program struggling to get out." (attributed to Tony Hoare)
Message 2 of 9
(6,011 Views)

I use a typedef of

 

cluster of three refnum arrays:

1. queues

2. notifiers

3. user events

 

I open all of necessary refnums on the begin of my programm, pass this cluster to all VIs, which need them and close all refnums on the end of my programm.

0 Kudos
Message 3 of 9
(6,000 Views)

tbd wrote:

      I think this question is regarding how to "share" the typedef and not how to share data(?)

....a diagram-constant of the typedef is created....


Yes, your understanding is correct.

That is exactly what I was looking for!  So I can just change all those 

control instances to constants, and they'll retain the link to the typedef.

No amount of book-larnin' can substitute for plain old experience.

 

Thanks!,

 

-- J.

Message Edited by JeffBuckles on 11-06-2008 04:56 PM
Message 4 of 9
(5,997 Views)

JeffBuckles wrote:

 

That is exactly what I was looking for!


It's nice to get one right once in a while - thanks for the Kudos! Smiley Happy

 

(Speaking as a CS aficionado, Kudos to you for asking the question... Smiley Wink )

 

Cheers!

"Inside every large program is a small program struggling to get out." (attributed to Tony Hoare)
0 Kudos
Message 5 of 9
(5,989 Views)

Discovered a rather unpleasant side-effect of using the typedef constant cluster this way. Since I'm using the typedef cluster constant only to communicate the definition of the cluster--not for dataflow--I resize it to the same size and shape as a control terminal.  This is shown in the first image, clean_cluster.jpg.   I was also careful to set "Autosizing->None" on all instances of the constant.   However, when I updated the typedef, all instances of the constant resized!  That's dozens of instances across many different VIs.   Why was "Autosizing->None" not respected?  Is there a better way to do this so that my BD doesn't get messed up if I have to update a typedef such as this one?

 

Thanks and Best Regards,

J. 

 

Download All
0 Kudos
Message 6 of 9
(5,896 Views)

One way is to put the typedef cluster in a subVI.  Connect the indicator to a connector pane.  To save block diagram space make the icon for the subVI very small (the size of the connector pane element).  Put it on the diagram of your main VI and any subVIs as required.  The typedef will update, but the subVI stays the same size.  This has been discussed in the Forum, possibly as a 

Nugget.  I do not recall who first published the idea, so I cannot give proper credit at the moment.

 

Lynn 

 

 

Message 7 of 9
(5,892 Views)

Hi Jeff,

      Yes it's a pain when deliberate formatting is wiped-out when the type-def is updated - I often show the labels of each cluster element so that it's clearer what values the cluster-constant is contributing to the diagram.  In this case where you're using the typedef-constant in many places and customizing each use, I'd consider following Lynn's suggestion.  However, in general, I feel this technique makes the diagram slightly more work to understand and adds another VI (which needs to be maintained.)  If the compiler were "smarter" - retaining formatting where possible - then the .ctl VI might be sufficient!Smiley Wink

 

Cheers! 

Message Edited by tbd on 11-17-2008 09:41 PM
"Inside every large program is a small program struggling to get out." (attributed to Tony Hoare)
0 Kudos
Message 8 of 9
(5,866 Views)

johnsold wrote:

One way is to put the typedef cluster in a subVI.  Connect the indicator to a connector pane.  To save block diagram space make the icon for the subVI very small (the size of the connector pane element).  Put it on the diagram of your main VI and any subVIs as required.  The typedef will update, but the subVI stays the same size.  This has been discussed in the Forum, possibly as a 

Nugget.  I do not recall who first published the idea, so I cannot give proper credit at the moment.

 

Lynn 

 

 


 

I remember!  Smiley Wink

 

In this Nugget I offered this approach.

 

 

See that Nugget for more discusion.

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 9 of 9
(5,834 Views)