The first time the user loads a file, the graph does not display the high and low targets

[daniel1211]

The first time the user loads a file, the graph does not display the high

 and low targets.   On subsequent loads, the targets show up. I am trying to work out some bugs on this program but i am have some difficulties with this problem. i have attacthed the program and one of the files we were using

[xseadog]

Hi

the spagetti is making me hungry !

Clear up your coding- Dataflow is from left to right.

Draw graph vi missing- Suspect problem is that you are not initialising a default value before you start. After you havre run one time memory remembers !

Nah time for a snack attack

Xseadog

[daniel1211]

haha thanks yeah that's the other thing that im trying to do i was given this and told fix it so it has been pretty interesting

[RavensFan]

One possibility is a lack of data flow because a lot of local variables are being used.  Look in the Display files VI, top loop.

A local variable of Display is used.  The cluster is unbundled and sent to numerous indicators.  This whole chunk of code has no dependence as to what is going on inside the event structure.  So it may execute before or after the code in the event structure that updates the "Display" by way of the sub-VI and a local variable.  You may want to eliminate some local variables (especially for the "Display" cluster) and wire them through.  Use shift registers in that top loop so that changes to the Display cluster can be maintained from one loop iteration to the next.

One local variable you should definitely get rid of is on the far left where you wire the cluster into the indicator and a local variable of the indicator at the same time right out of the first draw graph VI.

Also "paths" in the bottom For loop.  Get rid of the indicator/local combination.  Wire it into a shift register in the For loop so that you don't need to use local variable reads and writes to keep adding to the array.

Definitely try to straigthen out and clean up wires as you code.  Doing this as you work will prevent a lot of trouble doing it later, and will certainly make the code easier to read.

Message Edited by Ravens Fan on 08-03-2007 12:09 AM

[altenbach]

You are having race conditions due to overuse of local variables and lack of data dependency

The Code in the upper right of the while loop has no data dependency with the event structure, thus it will execute right away, reading from the "display" local variable before the event structure has a chance to write updated values to same.

Use wires and get rid of the hidden controls that have the sole purpose of acting as local variables. Things will flow properly!

There is also way to much unecessary code. In several places you write to a control and to a local variable of the same control in parallel. This is certainly not needed. A local variable is just a second way to access the control, so you basically write the same thing twice in a row.

[altenbach]

Here's a quick attempt to clean up some of the most glaring problems. I cannot test (missing subVI), so there are probably some bugs left. You should also check if the file dialog has been canceled and skip the rest of the code in this case. Mnay things can be optimized further, but this should get you started.

• It seem silly to use "open file" just for its file dialog functionality. There is a "file dialog" function.
• Don't use convoluted string operations on paths! Instead use "built path" and "strip path" for simplicity and platform independence.
• Use autoindexing instead complex "initialize arrays"+"shift registers"+"replace array subset", etc.
• Don't use overlapping wires, overlapping objects, wires that flow right-to-left, etc.
• Align related operations horizontally.
• ...

(I edited under 8.0 and saved for 7.1, so there could be some downconversion issues that need to be addressed. Take my code as a collection of ideas)

[daniel1211]

wow i can't thank you enough... still working on it but you guys have been alot of help

[altenbach]

It is never fun to fix somebody else's code. Weeding to 10x too much convoluted spaghetti code to figure out what it actually is supposed to do can be a challenge. ... then we need to find the simpler alternatives.

You'll be glad to hear that some of the original code constructs made it to the "Rube Goldberg Code" Hall of fame: 😄

http://forums.ni.com/ni/board/message?board.id=BreakPoint&message.id=3995#M3995

As mentioned quickly elsewhere, you can set the file dialog to select folders instead of files. Doing so will even eliminate the "strip path" function. 🙂