Slow down issues

[Michael_22]

I have a program, which I use to control mirrors in order to align a laser beam. The beam is observed with a camera. The problem is that while I move the mirrors the FPS of the cameras drops significantly. I found out that this is not a hardware problem. I attached two pictures with a small part of the code. The first one shows the code I usually use. The array generates the input for the mirrors. It’s inside a while loop. This input goes into the mode of a case structure I call „automatic“, which is also inside the while loop. I use the other mode of the case structure, which I call „manual“, for troubleshooting. The FPS drop appears in both modes. The second picture shows the code, which helped me to find the problem. If I use random numbers as an input, everything is fine and the FPS do not drop. But of course it’s pointless to use an automatic mode with random numbers. I understand that in general random numbers can be generated quickly, but all the slower calculations preceding the array(not shown) are still in the code with the random numbers. Therefore, the random numbers are generated as slow as the array. Also, this input is not connected to the manual mode, but the manual mode is still somehow affected by the input. I also added indicators in both codes at the same spot. Nevertheless, the speed at which the numbers are generated in the indicators is different depending on the code, if I move the mirrors (pic1: slow, pic2: fast) and the same in both codes if I don’t move the mirrors (both fast). I hope you have some advices for me. Please don't mind the Japanese characters in the pics.

[Kevin_Price]

Advice: post all code. The part you posted is very unlikely to be the culprit, unless those arrays you add are regularly large, growing, and unequal in size.

My crystal ball guess is that your decision to take a camera snapshot depends on completing the motion, and that the travel distance is very much smaller when the 4 inputs are random numbers restricted to the (0,1) range.  Shorter travel equals shorter time equals faster loop.

-Kevin P

[Michael_22]

Thank you for your reply. I am sorry but I cannot post the whole code. This code belongs to the company I am working for. It was not written by me, but I am trying to improve it. What do you mean by arrays which "are regularly large, growing, and unequal in size"? Also, what do you mean by "completing the motion"? You might be right with your guess, but I also tried to use numbers which are generated earlier in the code and the result was the same. But maybe the travel distance was still too long.

[Kevin_Price]

Keeping this very brief b/c it's too speculative to chase after for long.

1. Array comment:

    IF the two arrays being added are large & growing, LabVIEW may need to periodically allocate a new larger chunk of memory to contain the result.  If they are unequal in size, LabVIEW may resize the smaller one to match the larger while filling in the new elements with 0 values.

   My guess is that this is probably *NOT* happening.  The arrays are probably better behaved than that. But there's no way to know for sure from the minimal info you showed.

2. "Completing the motion"

    You mentioned that you're controlling mirrors.  I guessed that you might be commanding motion to the mirrors and then waiting for the motion to complete.  Again, I have no way of knowing if that's a good guess or not.

-Kevin P

[Michael_22]

Thanks again for the reply. I attached a greatly simplified code. There might be some sub VIs not visible for you. They are provided by the camera maker and can be downloaded here if necessary: https://www.theimagingsource.com/support/downloads-for-windows/extensions/icextlvi/

If there are still some missing VIs and they are important I will try to find out where to download them.

The mirror input has no practical meaning anymore. It now only serves to simulate my problem. By the way I also noticed two other things. If I choose a large step size for the mirrors, the FPS do not drop. In other words driving 1000 steps is much faster than driving 100 steps 10 times. Also if I remove the image processing AND data type conversion part the problem disappears. Previously, I only tried to remove the image processing part and did not realize that data type conversion is also time consuming.

A problem could be that the mirror control and the image processing use the same while loop. I just found out today that the speed can be increased by using separate while loops and queues. This probably sounds trivial to you, but I just started LabView recently.

I also want to ask if there is a way to read out the FPS of the processed image. Until now I only judged with my eyes.

[James_W · Accepted solution]

Hi Michael,

without the Vision toolkit installed, I can give you this simple feedback ...
1) Tidy the VI before  you post - theres far too much wasted BD Space

2) You are using a local for Reading Value - Use a Shift register to read the value from the previous loop, (or a wire to read from this loop). Currently you are reading the previous loop value, so use a Shift register to make it more clear and remove the race condition.
3) Why the conversion from U8 > DBL for the array subtraction? (I16 would do you fine, take up less memory, be faster and give a safer >=0 comparison result)
4) you only need to use a dbl at the point you multiply array max by 0.135 to get Value (which if thresholding in I16 would not be a decimal!)
5) opening and closing Image3 each time you loop is costing you precious time, open it outside the loop and pass the ref in Shift registers, then close outside the loop too.
6) IMAQ Dispose could be killing you here, you might want to pass the data array out of IMAQ to Array into a Queue and process it in a seperate loop to the dispose.

(Remember NI's basic Aquire, Analyse, Present)
you want to Aqcuire in one place, Process in another and Action/Present in another to ensure that your 3 core functions don't slow each other down.

James

[Michael_22]

Thank you for your reply. I could solve the problem thanks to your advices. The code became much faster after I put the mirror controller into a separate loop. Thanks a lot!