LabVIEW
how to speed up Labview code
Solved!
In addition to the things altenbach pointed out several others should be considered.
- You appear to have at least two different typedefs for the state enum. This could cause problems if one gets changed and the other does not.
- All the indexes should be I32. For loops and arrays cannot be larger than the maximum value of an I32. The extra coercions take a small amount of time.
- Local variables are much slower than wires.
- Move any calculations which do not change to the outside of the loops. For example #of Steps - 1 is calculated inside the while loop in the "first step" case but it cannot change after the program starts running.
- Use only one Threshold constant. If you ever need to change the value, it will be very tedious to find all the places it is used. If you miss one, the program could do some very strange things. If you have just one and wire everything to that, then making a change becomes simple.
- Move all indicators outside the loops. If the loop iterates faster than about 5 times per second, a user cannot keep track. More importantly, the time it takes to update indicators can significantly slow the code. (Note that if this is a subVI which runs with the front panel closed, LabVIEW is smart enough to not update those indicators).
- Indicators should never be used just to create local variables.
- The code in the for loops with Index Array, >=?, conditional terminals, followed by array size can be simplified. The code on the right can be ~5 times faster depending on the values.
- Code like the loops shown above which is duplicated several times should be made into a subVI. One subVI can be used to handle several variations in that code. Some places the start index is always zero. In those places that input to the subVI can be left at the default. Some place only the length output is used. Some use only the boolean. Others use both. One subVI can handle all those situations.
- The "state" = comparisons in several places can be simplified by wiring the state output to the case selector of another case structure. Set one case to select the "=" state and use Default for all the others.
And probably other things as well.
Lynn
It also seems that you only do simple threasholding on the complex magnitude squared. You could probably eliminate all subVIs to the left of the main case structure by simply taking the absolute value of the complex array and adjust the threshold value accordingly.
Yes, as Lynn said, all your integers should be I32. Make the terminals the correct representation, and you would not even need to convert later.
@Al-rawachy wrote:the problem is that there is no synchronization between these two chassis which makes RFSA start at different time from RFSG which casues as attached in figure 2(f2). Thus, this menioned vi is being used to auto correct the widow.
You should supply your code. This is a simple thing to synchronize at least close enough, especiallyl since it looks like you are just dealing with CW signals. I just finished up a power sweep for a customer doing something similar. I went through some 35 RF levels over 20 frequencies with NI-RFG and an NI Power Meter. The entire sweep took 46 seconds. I would expect similar results with NI-RFSA.
`Some of your manipulations could be greatly improved. As an example lets look at this section with buffer allocations shown:
Those black squares show where LabVIEW needs to allocate blocks of memory. Tools>>Profile>>Show Buffer allocations is very handy.
Here we see that the array subset allocates a largish array that isn't used except to create a large arry of bool- cast to a large array of U8 Cast to a large array of I32 just to get a count of elements above threshold
This is equvalent and a lot less memory is used
