Initialization Problems

[dnorman]

Hey all,

I'm having some problems when opening sub vi's within my main vi. In particular with initializing. These problems don't occur when I open the sub vi's on their own, only when they are called from the main vi.

The problem in the file below named configuration is with the position property nodes, which position the controls/indicators based on a value that is coming from a spreadsheet. This only runs once when the vi is opened and, like I said, works fine when the the vi is ran by itself. When it is called from my main vi, it has to be opened twice in order for it to initialize properly. The first time it will stack them up in one location.

The problem in the file named test is with the combo box named # of test weights. It too loads the values from a spreadsheet and has to be ran twice by itself to work properly, but unless you have ran it by itself first, when it is called from the main vi the combo box hasn't been populated and is empty.

I'm very new to LabVIEW and stumped as to why this is occuring.

Thanks in advance for any help,

dnorman

[RENN]

hi dnorman,

1. the vis you posted are missing some subVIs. please include those missing sub vis.

2. i think you can really improve your coding style by going through this online documentation

http://www.ni.com/gettingstarted/labviewbasics/

3. about your code -

avoid using local variables

i've seen you are using shift registers to store data. you will find all the necessary information here

http://forums.ni.com/t5/LabVIEW/Community-Nugget-4-08-2007-Action-Engines/td-p/503801

and try to avoid coding outside the block diagram part visible on the screen.

just have a look at this link: http://www.ni.com/white-paper/4434/en

if you have any further questions, reply again in this forum

good luck

[altenbach]

(Just looking at configuration.vi at the moment)

It is hard to tell what is causing the problem, but there are definitely really bad coding practices and potential race conditions. For example the local variable for "recorded value 1" gets read from a local variable before it gets written by the code.

You are trapping an event structure inside a case structure than can potentially lock up your entire program (for example if you would press "record value 0" before pressing "begin new calibration"). The event will lock the front panel until it completes, but it cannot complete because the other case is executing.

The loop in the upper right spins like mad, potentially consuming all CPU if calibration is false. Why is there a 0ms empty timeout event case in the lower loop as well as a wait? both are not doing anything useful.

You are seriously overusing local variables, for example the "#of weight" is read in at leasts three different locations in parallel. Since this seems to be a constant for the duration of the run, you can delete the hidden indicator and wire straight to all locations where it is needed.

There is a huge multiple of identical property node instances in the right side of the lower case structure. All that differs between the inner cases are the booleans, so all these preporty nodes belong after the inner cases. A single instance each is sufficient. Make the tunnels to "use default if unwired" and all you need to do is wire thre TRUEs.

Can you reduce to problem to a manageable small example program that still show the problem. We cannot really debug your current code. Thanks!

I would recommend to re-architect all this into a standard state machine. Maybe the problem fixes itself. 😉

[dnorman]

Thanks for the replies. I've been working on the bad coding like the local variables and ensuing race conditions, but I'm taking it slow since I am trying to learn as I go.

As for the event structure, I originally had it inside the case structure because I wanted it dependent on the case, but I became aware of the possibility of lockup. I was contemplating moving it outside the case but make some of the buttons enabled by the case structure instead.

Does there not need to be a wait in a while loop that also contains a timeout from a event structure? The way I understood the timeout was that was how long it waited for another event before timing out. I didn't want it to wait for another event I just wanted it to timeout until the next event because I wanted the while loops to continue. That is why I set them to 0 ms.

I will work on improving the coding and if I still have problems I will repost here. I have heard state machine mentioned on the forums some, but I don't know what they are. I will look into them, thanks for the suggestion.

Thanks,

dnorman

[altenbach]

---

@dnorman wrote:

Does there not need to be a wait in a while loop that also contains a timeout from a event structure? The way I understood the timeout was that was how long it waited for another event before timing out. I didn't want it to wait for another event I just wanted it to timeout until the next event because I wanted the while loops to continue. That is why I set them to 0 ms.n

---

The lower event loop does not do anything useful in the timeout case, so there is no need to spin the loop. It is just pumping hot air. Delete the timeout case AND the wait!

The upper large while loop has no wait whatsoever if the upper case inside it is false.

Also, in the calling program, the two loops on the lower right spin like crazy if they are not doing anything. (place an indicator on [i] to see) They definitely need a small wait. (See also)