Should I make cluster into a Typedef

[crossrulz]

---

murchak wrote:Is putting all the constant controls in one cluster an incorrect use of a cluster?

---

I could be shot here for what I am about so say.  This sounds like a good use case for a Global Variable

...yes, I already feel the guns cocked and loaded, pointed at me, with fingers starting to pull the triggers...

Here me out here.  Global Variables are excellent ways to hold CONSTANTS that you will need everywhere in your code.  Notice that capitalized word.  CONSTANTS.  This means that you are not changing the values.  They are set.  But you can just get the value by calling the global.  It is quick and very efficient.  What I like to do with my globals is read the settings from a configuration file as soon as the program starts and put those values in the global.  From then on out, they are constants.

And for those who are still about to finish squeezing that trigger:  Constant = no race condition

[murchak]

Thanks. Below is the code architecture that I have:

A few questions:

1. Just for the learning purpose, I put my "format the table" state as State 2 which is where I format the entries of the tabe (for example, negative values would show as red). Do I feed

the output of State 1 (table) into State 2 via a shift register?

2. If my Cluster of properties is constant, does it make sense to keep it ouside of the While Loop, like I have shown below?

3. Finally, I have been learning about State Machines and everyone would argue in favor or using it. But if the purpose of the code is to execute all 4 states, irrespective of the outcome

in the previous states (no decision), why would State Machine be good to use aside from keeping the BD compact and maybe code readability?

To make my point lucid, my code must create the table, format it, then make different plots. Period. This task must be done whenever the user runs the code and select data files.

In this case, what is special about using State Machines? Not arguing against it, but merely trying to understand its usefullness here.

4. Finally, anything you would change about the diagram below?

[Dave_Brandt]

A Global would require a code change, Why not Just use a file for constants? If the file is in xml or a csv format the constant value could be changed with notepad or any simple text editor. I think you should use clusters but the data in the cluster should relate to each To be logically grouped. Do not have one big cluster so there is only wire in your block diagram.. This could slow your program because labview would not be able to parallel process data but would follow the wire path through your code through each sub vi.

[murchak]

Good, we are getting to the crux of the problem. So if I put my constants (color boxes, color arrays, etc.) I would then have to convert those quantities to

some kind of string representation. Then everytime I use the file, I have to open it and convert back to color type, and so on. Wouldn't that really add more code

to my already bulky BD? 

[Dennis_Knutson]

Why do you think there is any string conversion required? Have you even looked at the ini file option I mentioned?

[Hooovahh]

And the OpenG ini accepts variants for reading and writing, no conversion needed.

[crossrulz]

---

murchak wrote:

:

1. Just for the learning purpose, I put my "format the table" state as State 2 which is where I format the entries of the tabe (for example, negative values would show as red). Do I feed

the output of State 1 (table) into State 2 via a shift register?

2. If my Cluster of properties is constant, does it make sense to keep it ouside of the While Loop, like I have shown below?

3. Finally, I have been learning about State Machines and everyone would argue in favor or using it. But if the purpose of the code is to execute all 4 states, irrespective of the outcome

in the previous states (no decision), why would State Machine be good to use aside from keeping the BD compact and maybe code readability?

---

2. Yep.

1 & 3. I've been known to make a VI for each step of what you have in your state machine and then just sequence the VIs.  Yes, this work quite well.  That is until something gets changed and you have to reorganize your sequence.  That is when you will be happy you have a state machine.  It is a lot easier to just change the case you go to or an array constant (FOR loops work well in this instance) than to have to delete wires move VIs around and rewire.  And anything that can be passed from one state to the next should be put in a shift register.

[murchak]

This is what I was reading when you mentioned ini file:

http://zone.ni.com/reference/en-XX/help/371361H-01/lvconcepts/creating_configuration_files/

Seems like more work just to read a color constant. My aim is to make the code simpler. I'll continue reading to better understand it.

[Dave_Brandt]

There are no free lunches with a computer.  It does exactly what you tell it to do.your Program initialization does not have to be bulky. Use a sub vi to initialize your clusters at start up. At shutdown a sub vi to save those clusters when you close your program. Evan a simple program should have 3 parts - Startup/Initialize , Logic Execution/Error Handler and Exit/Shutdown.

[Dennis_Knutson]

And when someone objects to your choice of colors/point styles/any other highly objective aesthetic choice, you'd prefer to edit the VI? What if more than one user with different preferences?