LabVIEW
reload data from first iteration while loop
Solved!
Hi LvL,
I want to let the user press a boolean button to reload the original data.
And what's your problem to implement just exactly this code?
The "original" data is available just in front of this WHILE loop - all you need is a button, a Select function and some wire…
I prefer not having to add more loops.
You don't need to if you would implement a state machine…
(What's wrong with an additional loop? Are you paid by how many loops you use???)
Hi LvL,
I didn't want to use more loops because I think it makes the code look messy.
Only when you use them without planning.
I think I already mentioned this sheet of paper… 😄
In addition to what has been said already, there is plenty more horribly wrong with this code:
- Of course we are not sure what happens in the "clipping" subVI, but most likely your loop spins millions of times per second,repeating the same thing over and over while keeping a CPU core 100% busy. Place a reasonable wait in that loop!
- You should not have a shift register at all because clipping presumably changes the data and re-clipping the new data over and over again seems unpredictable. Is the number of points in the array fixed?
- If the number of points in the graph does not change, all you need is a plain tunnel, wire the array through the clipping VI, and then to the graph. Now you always operate on the original data.
- And yes, if you design your program as a reasonable state machine, you don't need a loop and "clipping done" boolean. Is this a subVI or part of the toplevel code?
- Can you attach your actual code so we can take a closer look?
I think you should start from scratch. You can do all that with 5% of the code.
- All you need is a single set of graphs and inputs and simply select what row to display and operate on. (You can even place a very shallow tab structure above and display different data depending on the tab state.)
- Get rid of the sequence structure. Don't force the operator to do things in a certain order.
- Don't use multiple controls all with the same name. Makes the code impossible to debug.
- Still none of your loops have any waits.
- You index inputs to the subVI seem to have the wrong representation.
- Operate on one row at a time and also recalculate the "edit" graph while you pick thresholds.
- There is lots of incorrect code, for example the loop that replaces zeroes with NaN spins once for each element instead of once per each zero. All you need is an autoindexing FOR loop and a select node.
- ...
You said something about event structure. I cannot find it.
So:
Use an event structure with events to (1) load a new file, (2) select a certain data row, and (3) process the current row using the cursors and other controls while updating the edit graph (cursor change event, value change event). Go back to wait for user input using 0% CPU.
OK, that already looks better. last night I spent a few minutes and modified a version using some of my stated ideas. (note that it will only process one subset per column, but it can easily be expanded to incrementally allow selection of multiple ranges per column. Just needs a bit more code :D)
@LvL1995 wrote:
- I'm not sure what you mean with ' a single set of graphs' . What I've done now is using a single graph to clip the data, and let that send to a next graph. Is this what you meant?
See my code example. If you want to output the processed array at the end, place an indicator after the while loop and tap into the 2D array after the processing.
@LvL1995 wrote:
- I don't understand what you mean by the index inputs of my subVI seem to have the wrong representation.
Indices are integers and should be blue (I32). Yours are DBL (several places, also the "select row" control). Right-click...representation" will fix it. Of course DBL (orange) will also work correctly, but the compiler needs to internally coerce, causing extra memory allocations and potentially (unlikely here) incorrect results. Noticeable whenever you see a red coercion dot :D).
LvL1995 wrote:
- I have no idea what you mean with 'recalculate the "edit" graph while you pick thresholds'
You can update the final graph at all times. pretty cheap. I do it outside the event structure whenever something has changed then wait again for user interactions. With event structures, indicators hidden inside other event will not update unless that event gets triggered. Thus I update everything outside.
Attached is some simple code. It loads the available columns into a listbox (no limit on the number) and you can process any one of them by selecting. Every time you switch columns, updates the controls, cursors, etc. to the last setting for that column.
Modify as needed. It is definitely not polished, but should give you some ideas. I also simplified some other things and added a few diagram comments.
