Local variable icon NOT visible for tab control

[murchak]

I right-click on the Tab Control icon on my block diagram, then go to create -> local variable, but when I drag the mouse to drop a local variable, I can't

see anything. All I see is the blue connector, which follows my mouse, but I don't see the icon. Any ideas?

But when I go to programming palette -> structures -> drop an empty local variable, then click on that to connect to the tab control, then I see it.

But then when I click on that to create a constant input, then I can't see the constant created. This is really strange.

[P@Anand]

Can you restart LabVIEW and check it that happening again?

[johnsold]

After you have attempted to create the local variable and it does not appear, try right-clicking on the tab control terminal and look at the Find sub-menu. Are local variables listed and does selecting that "find" the local? 

One other thing comes to mind: If your front panel or block diagram is very large (multiple screens), sometimes weird things happen.

Lynn

[murchak]

Neither re-starting, nor finding local variable through submenu helped. 

However, I tried one more time and noticed that something was created way far to the right of the block diagram. I followed

the wire but still didn't see the local variable. Except this time I was able to create a visible constant. Then I went to programming

structures and dropped a local variable and linked it to my tab control icon, and connecte the constant to it. Strange.

Sometimes when I create a control or indicator, or even copy controls and indicators, why does LabVIEW place them way to the right

or left of where my code is. The object is created so far from the rest of my code that I have to drag it for a whole minute before

it appears where I wanted to?

My front panel has a tab structure with 7 tabs, really not that many. But my block diagram uses a flat sequence with a dozen frames. Is that bad?

[P@Anand]

---

@murchak wrote:

My front panel has a tab structure with 7 tabs, really not that many. But my block diagram uses a flat sequence with a dozen frames. Is that bad?

---

Yes, its time for you to restructure your code with case structure instead of frames. Do you have a lot of controls as well in FP? Can you show the code?

[murchak]

Hi Anand,

Over the last two years, I have made several modifications to my code, but I think you are right, I need to rethink the whole structure of it. Before posting any long codes here, maybe you

could help by offering some suggestions. Technically, my code is very simple. It asks the user to select some files, then it derives other files from the given files, does some linear regression

on the data, formats it into a table, and generates about 30 plots or so. The table and the plots are then exported into MS PowerPoint. My coworker has written LabVIEW codes that control

the tester, and generate the test data. I use LabVIEW to post-process data, just for the routine daily tests. I actually use JMP and sometimes Minitab for heavy data mining, statisitcal analysis,

historical trends, etc. (I work in the disk drive business). 

For each one of those plots, I have an XYGraph. Basically, the plots are grouped into 4 different types. When they are the same type, I put the references to each plot into a array and feed that

into a for loop that has property nodes. I have tried to user for loops as much as I could to reduce the bulk in my code, but there is still too many plots and properties that need to be formatted.

Also, the code has options to get rid of outliers before plotting the data, and a bunch of other things. 

Is there a way to automatically generate a reference to each XYGraph that I have on the front panel? For example if I have ten plots, do I need to generate 10 different references to each plot

or can I generate one generic reference where through a for loop or something it's link to different XYPlots?

Also, I am using frames to help organize the code and maybe control the execution (I know I can do that though error wires as well). Is this a bad idea? I would tell you that speed is not that

important to me. Whether the codes takes 4 seconds to do what I want it to do or 2 seconds is really of no practical consequence to me or my work.

[P@Anand]

It looks like the State machine design pattern works perfect for your requirement. Also check here how you can build a state machine step by step.

Regarding XY graph, you can take the reference of the XY graph and access each plot by setting the Active plot value in the property.

[johnsold]

I agree completely with the suggestions provided by P@Anand. Your program sounds like a good candidate for a State Machine architecture.

Regarding the question you asked about the placement of controls and their terminals: There is some correlation between positions on  the front panel and on the block diagram, but NI has not stated the algorithm publicly as far as I know. There seems to be a tendency for objects to be placed at of beyond the visible boundaries of the panels under some circumstances. As the panels get larger the problem seems to get worse.  In general duplicating a control by option-drag (or whatever the key combination is on your OS) will move the terminal in a similar direction and distance on the block diagram. Duplicating at the BD terminal will move the front panel copies similarly. Creating a control or indicator from a BD conpane terminal is harder to predict. The location seems to depend on what is already on the panel and where on the BD the function or subVI icon is.

If either the FP or the BD is much larger than one screen, or if the objects already present are far from the origin of the panel, things may go to places hard to find.

Maybe this is a subtle plot on the part of the LV developers to try to get programmers to keep panels to the size of one screen.

Lynn

[murchak]

Thanks Anand and Johnsold.

I actually attempted the state machine approach a few days ago, but was unable to figure out how to move from state to state. But then I 

tried to write a simple program and it worked using the state machine. I will convert my code to a state machine format and then give an update.

Thanks both for the suggestion.

[johnsold]

State machines use a typedefed enum or a string (usually) to pass the name/value of a state to the next state via shift register. One of the last things done in each state, on each pass through that state is to determine what the next state should be.

For example the file selection state will choose the next state on the basis of the result of the selection. If one or more valid files are selected, it goes to the state which processes the data in the files. If no files were selected, it would go to a state where the user is prompted to select files or to exit the program. If some kind of file error  occurred, then it would go to an error handling state.

Recent versions of LV have good examples of state machines. 

Lynn