LabVIEW
Exclusion of undesirable segments of splitted series
dan07 wrote:
We always learn the things by the worst way, in my next analysis I will not make the same mistake, I will take note of the results with at least 2 decimal places.
Even better, also save the U64 number containing the pattern, then you don't have to search at all. 🙂
dan07 wrote:
I need to append to the VI a control for the graphs scale. In other VIs I used to use a property node for the graph, with Maximum and Minimum... But I was working in the first VI that you sent me (that with the size of a Post Card, not the large and monster like that I sent first to you...) and I don't know where I should link the scale control.
It is somewhat buggy to change the scale of a graph that inside an array of clusters using a property node. In principle, all graphs should have the same scale but LabVIEW does not update correctly. In 8.0 it updates randomly one of the elements. In 8.5.1, it does the same, but the other graphs update once you move the cursor over them. I haven't studied this in detail to see if there is a workable solution with property nodes. Instead, I would suggest to just "enable" the graphs, so you can change the axis directly by clicking on the numbers of the scale. If you do it this way, all other elements will update immedately too. That's what I have done in the attached example.
Some comments to the faster code:
- I use two loops, one for the UI and one for the search. The search loop places found solutions in the queue, while the UI loop checks the queue at leasure. This has the advantage that you can inspect already found solutions while the search is still in progress.
- Since I use a FOR loop for the search, I needed to split the problem such that we loop over the first 31 bits and do the remaining bits inside in parallel. (A FOR loop can only do I32).
- The data in the UI loop is in shift registers so you can add a new event case to load new data if desired.
- You can no longer stop the seach after the first match. If you still want that, you would need to go back to a while loop. (never LabVIEW versions allow stopping a FOR loop prematurely). A while loop requires checking for the stop condition at each iteration and will thus be slower.
- The arrangement with the shift registers in the search loop allows some internal optimizations that is important for LabVIEW 8.2 and 8.5.1. All versions have about the same speed.
- It would be easy to wrap the search code into a subVI, e.g. with data, search pattern, and search range input. Make it re-entrant and you can launch a few in parallel, each working on a subrange of the possible solutions, and all writing to the same queue. This will be beneficial if your CPU has multiple cores. (I have not tried this).
- I have some other ideas to speed things up further, but I have other things to do. 😉
See if things make sense. Let me know if anything is not clear.
dan07 wrote:
1. How do you leave a default data inside the VI? Since that in this VI I don't need to load a file do see the graphs and perform the search.
2. I looked up in the cluster and container wired to cluster and I did not find where you specified that graphs will be generated from the data, where do you specified that?
- The default data is in the diagram constants to the left of the upper loop, initializing the shift registers with the data. Easiest to do so is attaching an indicator to the various wires between the shift registers, then run the program and read in your data files. Now stop the VI and turn these indicators into diagram constant (right-click the terminal... change to constant). (I did this on the old version that was able to read datafiles and then just copied the diagram constants over). Now move them out of the loop and hook up as needed. (I do this for the orange 2D array). The data for the purple cluster array is also a diagram constant, but written to a signaling value property outside the loop. This loads the data into the control and fires the event, thus forcing an update of all related calculations in that event frame. (In simpler cases, e.g. if the data does not need to be stored in shift registers, you can just stop the program with all indicators populated and do a "edit...make current values default", and save the VI. Be careful. If e.g. graphs contain a lot of default data, the file size of the VI could be huge.)
- If you look in the upper right corner, what looks like a cluster diagram constant is actually an array with the index terminal hidden. You can resize it to show all elements or show the index terminal to scroll it.
The diagram constat is an array of clusters. Each array element is a cluster of a boolean, a DBL array, and an integer number. Thes elements map to the displayed cluster array: the boolean maps to the LED, the array maps to the graph, and the number maps to the displayed index. As long as the dataypes match in the same cluster order, they are compatible. A DBL array is just data. How it is displayed on the FP (array container, graph, etc) depends on the type of indicator, all we care about is the data.
Yes, sorry the "raw data" array contains the default data for the lower parts, same as the diagram constant. You can right-click the terminal and do a "show control". This is just a shortcut. Once you modify to read in real data, you need to e.g. use a local variable to transfer it to the lower loop.
dan07 wrote:
I don't know what is happening with the LEDS, because when I moved the whole code to the While Loop, the LEDS stop working, they don't stay RED after clicked.
Whenever you write to the local variable of the cluster array, you write all TRUEs to the booleans, overwriting whatever you just entered. You need to read the current state of the booleans from the control and modify the graph only.
Even if you do this, it will not work well, because one of the slowest parts of the code is the FFT, so there is a near 100% chance that you modify the cluster while this FOR loop is already running, writing the stale value back to the cluster local. Going back to the event structure will fix this, of course. Even now, placing a 100ms wait in the loop will make things work better, because this race condition only occurs in a small percentage of cases. (This is only a bandaid solution and not recommended)
Overall, you still make coding mistakes that cause potential problems and complicate the code unecessarily. For example:
- I showed you how to get a slice out of a 2D array using a simple "Index array", so why did you go back to that convoluted combo of array subset and index array?
- Since all these array operations are the same with every loop iteration, they belong outside the while loop. It is sufficient to calculate these things once and not with every iteration of the loop.
- You have the "lenght of segment" terminal and still read from a local variable of the same. You need to eliminate the local variable and simply branch the wire from the terminal. You have a potential race condition and create an extra datacopy for no reason..
- You divide the "lenght of segment" by two in three (!) different locations. It is sufficient to calculate it once and branch the result to the other locations.
- I have no idea why you add zero at each iteration of the small FOR loop on the left. Makes no difference.
- Instead of nine shift registers with near identical operations (add something), use an array with 9 elements. Simpler code.
- Use a formula express VI is overkill for this.
- All the indexing, summing, etc in the inner FOR loop is only needed for the TRUE cases, so these operations belong inside the case structure. There is no need to do these operations if you discard the result anyway.
- ...
- Al lot of your code could be simplified further, for example that small while loop is probably not needed with smarter code. I have not bothered.
Attached is a quick rewrite implementing some of the ideas. The race condition is still present and there is a small chance that switching an LED will not "take" on the first try , but will fix itself once you go back to the event structure.
