Loop runs exremely slow when looking at large waveform

[toolman]

Hi everyone I hope I can explain this so everyone understands. I am grabbing an analoge signal from a hall effect sensor that is reading a gear (i.e. crankshaft sensor). My VI is setup to read x amount of revolutions on a 40 tooth gear. I need to grab 4000 teeth and then calculate rise time fall time, duration, and offset from the mechanical tooth edge. Everything works, however when I read the 100 revolutions, it takes about 20 minutes to get all my info. What I do is trigger my my app to grab the x amount of revolutions. Then I chart both the mechanical tooth (manually built signal), and the aquired analoge signal. After that is done I bring the waveform into a for next loop that has the iterations set to (# of revolutions X total teeh on the gear). So in this example the # of iterations is 4000. Inside that loop I use the pulse measurements vi to grab my pulse durations ( I bring i to the pulse number terminal). Then inside that for next loop, I have another loop that the # of iterations are set to 2. Inside here I use a transition measurement vi to check the rising and falling edges of each pulse to obtain my data. All of this data leaves the loops as arrays that sit outside the loop. Even if i elimnate the inner loop and just check the pulse duration in the outer loop (4000 times) it take about 10 minutes to complete, just way to long. I think I know why it is so slow, I have to look at this large pulse train every iteration to find the pulse number I am looking for and then grab the data, however I cannot think of a btter way to get data from this large pulse train. Any thoughts? If code needs to be posted I can do that, or if more explanation is needed let me know. I appreciate any help. Thanks!

[Don_Phillips]

I could be wrong from the textual description, but it sounds like each of your loops are all contained within one another so I think you are actually doing more processing than you think. For example: on the 50th gear tooth recorded it passed this to inner loops for processing. Next iteration (51st tooth) it does the same thing. I think its so slow (if I can visualize this correctly) because likely you are actually doing 100! calculations for the inner loops.

I would have one loop do all the aquisition and pass out an array with the waveform. Pass this into a seperate loop to do the processing...

[toolman]

In a way you are correct, but let me try to explain a little better. A wavefrom containing 4000 gear teeth (100 revs), sampled at 30000 pionts per rev comes into the loop. The outer loop has a pulse measurement vi in it, the loop iteration determines the pulse to measure, (i.e first iteration reads pulse #1, second iteration reads pulse #2 etc.), next I have to get the rising edge time and the faling edge time for each pulse(use transition vi for this), to do this I nested another for loop, the iterations are set to 2. I take the outer loop iteration for the pulse number for the transition block inside the nested for loop, and I use the inner iteration for the rising then the falling edge of that pulse(0 then 1). All of this data is auto indexed out of the loops to arrays that gather the information. Inside these loops I do nothing else (i.e. write to controls, indicators, graphs etc.). I mean the answer may be as simple as the fact that the vi's I am using are inherently that slow (if I just do 1 revolution which equals 40 teeth it takes 250 msec to complete, multiply that out to 4000 and you get 16 minutes or so). Now if I just take one pulse and bring it into the loop it runs the 4000 iterations almost instantly. It seems the problem lies with the fact that I am looking at a pulse train with 4000 peaks which have to be counted through each loop iteration to find the right pulse to measure, I just cannot see a way to run one pulse through at a time without using some sort of loop that has to look at the entire pulse train therefor slowing everything down. Maybe that makes a little more sense. Thank you for your time in answering my question.

[shoneill]

Are you displaying the results on the front panel, or is everything taking place on the block diagram? If so, the re-draw times for the front panel will slow everything else down.

It would be extremely helpful if you could post some example code (or even a picture of it). I'm sure then someone'll have the solution quickly.

Shane.

[toolman]

I do not think anything is being drawn to the screen in the step that is slow, I will attempt to attach the code now, the piece in question is about the third step in where you have a fo loop nested inside another with pulse measurment vi's and transistion vi's. Sorry if it is so messy we are trying everything over here to speed up the app. Thanks for any help in advance.

[johnsold]

I think your nested loops are the problem, but I have not been able to sort out exactly how to fix it.

I created a simplified program by taking the frame with the nested loops and making it a stand-alone VI. Using the indicator with the pulses as a signals source, I find (using the Profiler) that the Transition Measurements.vi runs 6*N times. SubVIs of the Pulse Measurement.vi and the Transition Measurements.vi run ~ 50*N times, where N is the number of pulses.

It seems to me that the Transition Measurements.vi should run twice per pulse. I am not sure where the other 4 runs per pulse occur.

My data sample was too small to tell, but I did not see any significant delay to find a later pulse. However, if that is a problem, you could segment your data into an array of pulses and use the index array function, which is optimized for efficiency to select the pulse you want to analyze.

When you get past the crisis of the moment, look into the state machine architecture. It would make your program more readable and more easily modified.

Lynn

[toolman]

Thanks for the reply Lynn, what you said makes sense, and I have been slowly gaining speed by small changes in my app. We are definately going to head towards a state machine architecture as we have many more tests that have to be run on the pulse train. I am just trying to get something up and running to show our customer. You are also correct when you say the transition measurement should only run twice (rising edge, then falling edge per pulse). I will try to see what is going on there. Thanks again! Robert