Clusters and shift registers

[VeeJay]

Hello,

To clean up many shift registers, that have inputs as arrays, I want to make use of clusters to bundle the arrays and pass them on. How would I accomplish combining the two array I have on the jpg into a cluster which is the input to the shift register and hence ON passing cluster values to shift register as program loops. I know what we can create a cluster constant and add array constants etc. But, I want the arrays in the cluster initialized to a certain length with a value 1. How do I do that inside the cluster? Thanks!

V

[GerdW]

Hi V,

just include a "Bundle" node between your InitArray functions and the shift register!

[VeeJay]

Oh that was way too simple than I expected. Thanks! 😉

[VeeJay]

Is it good to send data to subvi's through cluster all the time and in every depth of subvis?

[NitzZ]

Hi VeeJay,

Sending data to subVIs through clusters depends on the number of parameters being passed to the subVI. If it is just 2 or 3 parameters being passed, you can directly pass it to the subVI and avoid the bundling and unbundling processes. But if the number is high, it is always good to bundle it into a cluster and then pass it to the subVI.

Regards,

Nitzz

(Kudos are always Welcome;)) 

[Mark_Yedinak]

Clusters should not necessarily be used to simply combine data to eliminate extra wires. Clusters should be logical groupings of related data. As a bundle the data should be meaningful. That is if you have two completely unrelated data elements and you simply want to reduce the number of wires running through your code, I would not recommend creating a cluster. The elements within a cluster should naturally "flow" together. That is when you are accessing elements within the cluster there is a very high probability you will need the other data as well. If the likelihood for using the other data is very low than they probably shouldn't be bundled. While it may seem like a good idea you will probably find that you are passing lots of unused data via that wire simply in an effort to avoid wires. This will obfuscate the code since someone looking at the cluster will wonder why these pieces of data have been bundled.

For example, let's say you have an IP address of some device you communicate with and a path to a log file. The log file does not contain any data related to the device and the device does not need access to the log file. However you decide to put them into a cluster to save some wires on the BD. Now someone else comes along and looks at the code. A very logical assumption from looking at the code would be that the log file is associated with that device because this data is bundled together. While this seems trivial lots of time can be wasted trying to understand the relationship of the data and the code itself is not clear. If the data elements were large (images, wave forms, etc.) why chance unnecessary copies of the data being made when the wire branches to areas these elements will never be used.

One last comment is that it is always a good idea to create a typedef for your bundles. This will help to make using and maintaining the clusters much easier.

[VeeJay]

Hi Mark,

Thank you for the details. There is a fine line between a clean code and logical bundling. My application is a large one and there are many parameters being passed to subvis. Now for example, a daqmx read or write has a task IN and error line. Since there are already many parameters going into the subvi, I thought it would be ideal to bundle all the daqmx lines so that both the taask and error lines are sent as a bundle. Apart from logical inconsistency, will bundling into a cluster result in code malfunction?

[aeastet]

---

@VeeJay wrote:

Hi Mark,

Thank you for the details. There is a fine line between a clean code and logical bundling. My application is a large one and there are many parameters being passed to subvis. Now for example, a daqmx read or write has a task IN and error line. Since there are already many parameters going into the subvi, I thought it would be ideal to bundle all the daqmx lines so that both the taask and error lines are sent as a bundle. Apart from logical inconsistency, will bundling into a cluster result in code malfunction?

---

Bundling in a cluster will not cause code malfunction unless you do not program it correctly. I use this method all of the time. You do need to be aware of memory management and what data you are passing through the shift register. Do not pass large data file through using this method. An action engine is a much better way to do this. Bundling things together so it it easier is great. I may some times have a cluster with different grouping inside one big cluster (i.e. A DAQ cluster, parameter cluster, output cluster, profile cluster) all grouped into one cluster that has to run into many different sub vi's. You need to be clean and methodical so that it dose not get messy or hard to read.

[Mark_Yedinak]

Is the subVI doing too much? Is it performing unrelated tasks? Creation of subVIs falls into the same category as clusters. A good rule of thumb is that a subVI should have a siingle function or responsibility. Of course this sounds easier than it is is reality. However, keeping functionality limited to a single task within a subVI (I am not referring prohibiting parallel processes in a subVI. I am referring to a logical task.) helps to foster code reuse as well as make testing and debugging easier.

As for your question will the bundling cause a malfunction or not that answer is probably not. You may encounter performance issues if you have very large data elements. Other than that though you code should execute properly.

[VeeJay]

My code is condensed such that there is nesting of vis. i.e. subvi's within subvi's. Since, my MAIN vi is the one that provides parameters to all subvis and subvi's update information on MAIN, I have to send controls through clusters. Now, I don't mean to put them all in one cluster. I have couple clusters to maintain logic. Like cluster for daqmx lines. cluster for inputs to subvi and an output from subvi cluster etc. It is just that the vi looks a lot cleaner 🙂