labview vi slows down

[AndyN]

---

Mark Yedinak wrote:
Have you tried running the profiler? This may help you to narrow down what is taking so much time. You might also want to spend a little time cleaning up the code. When I opened it it was difficult to follow what was happening. The diagram is extrememly large (much large than my 1600 x1200 monitor), the wires are flowing in all different directions and you have hidden code (code that is covered by other structures or hidden inside a structure that was resized to a smaller size). Organizing and cleaning up the code may help you to uncover the problem area.

---

No, I did not. As for cleaning I am used to C code and when it comes to writing pure algorithms it is much cleaner. I already ported some portions to subvis but still it will never never be as clean as C. I am trying my best. I was developing it on two monitors 🙂 What could you suggest in terms of cleaning it. NI suggests to use lines as connections instead of calling variables from different places

The interesting thing about the slow downs is that it does not always happen. Keeping the mouse button always helps it. I have to check if there is a difference between normal and normal with mouse pushed operation.

[Mark_Yedinak]

A good place to start would be to look at some posts where folks asked for comments on their CLD practice exams. NI's style guides are also a good place to find useful information. The book The LabVIEW Style Guide is also a great reference. Here are a few general suggestions for good LabVIEW coding practices:

1. Try to keep your block diagram and front panel to a single screen size. Even with dual monitors it is best to keep BDs and FPs to a single screen. Remember larger BDs generally means more complex and less modular code. It is the equivalent of a 1000 line procedure in C or C++.

2. Try to minimze the number of bends in your wires and try to keep the flow running left to right and top to bottom. Avoid running wires all over the diagram or running them backwards.

3. Use wires instead of local variables or references. References and local variables will result in additional copies of your data. If your data is large this can be a performance hit.

4. As in C, make your code modular and keep subVIs simple and small. Try to keep them doing a single task.

5. Avoid using sequence frames to impose flow control. Use data flow. LabVIEW is a data flow language.

6.When staring an application take a look at some of the examples and templates. State machines are a very powerful tool in LabVIEW code. They are also easy to implement.

7. LabVIEW supports parallelism so use it. Separate out your task that can be to take advantage of the parallel processing. Do your reads and writes separately from your processing. This can help to improve your performance.

8. Avoid polling when possible. Use events instead.

9. Don't hide code. Don't place things on top of each other or hide code in structures like loops or case statements when you resize them.

These are just a few suggestions.

[RavensFan]

---

AndyN wrote:

 Could you be more specific as where the problem could be? I concate things more than once.  thanks

---

See the attached image.

As Mark said in his post, the diagram needs some serious cleaning up.  All of your loops and case structures should have Auto Grow turned on.  I fixed that and ran block diagram cleanup to fix the wiring issues.  I am not sure why you are showing the terminals on some of your subVI's.   I back saved to LV 8.2, attached.

[AndyN]

---

Mark Yedinak wrote:

A good place to start would be to look at some posts where folks asked for comments on their CLD practice exams. NI's style guides are also a good place to find useful information. The book The LabVIEW Style Guide is also a great reference. Here are a few general suggestions for good LabVIEW coding practices:

1. Try to keep your block diagram and front panel to a single screen size. Even with dual monitors it is best to keep BDs and FPs to a single screen. Remember larger BDs generally means more complex and less modular code. It is the equivalent of a 1000 line procedure in C or C++.

2. Try to minimze the number of bends in your wires and try to keep the flow running left to right and top to bottom. Avoid running wires all over the diagram or running them backwards.

3. Use wires instead of local variables or references. References and local variables will result in additional copies of your data. If your data is large this can be a performance hit.

4. As in C, make your code modular and keep subVIs simple and small. Try to keep them doing a single task.

5. Avoid using sequence frames to impose flow control. Use data flow. LabVIEW is a data flow language.

6.When staring an application take a look at some of the examples and templates. State machines are a very powerful tool in LabVIEW code. They are also easy to implement.

7. LabVIEW supports parallelism so use it. Separate out your task that can be to take advantage of the parallel processing. Do your reads and writes separately from your processing. This can help to improve your performance.

8. Avoid polling when possible. Use events instead.

9. Don't hide code. Don't place things on top of each other or hide code in structures like loops or case statements when you resize them.

These are just a few suggestions.

---

I think at some point I run through them altough I consider some of them contradictory. thanks I ll try to use them.

If you have to include an algorithm in your code, I mean like 2-4 pages in C how do you deal with it in Labview? You write it in C and combine with Labview or do something else. One line of C or any other langueage can take half the screen in Labview.

[RavensFan]

---

AndyN wrote:

If you have to include an algorithm in your code, I mean like 2-4 pages in C how do you deal with it in Labview? You write it in C and combine with Labview or do something else. One line of C or any other langueage can take half the screen in Labview.

---

That may be a little bit of an exaggeration.  I'd like to see an example of one line of C code that would take up that much screen space.

If you need to do something in a text based mode, you can use the Formula node.  In LV 8.6 and earlier, (or 2009 and later if you have it licensed) you can use the Mathscript node.  There are also options to call external C code, or use your own .dll.

But the pure G way of doing something would be to combine any section of code that takes up a lot of screen space and place it in a subVI.

[Mark_Yedinak]

---

AndyN wrote:

I think at some point I run through them altough I consider some of them contradictory. thanks I ll try to use them.

If you have to include an algorithm in your code, I mean like 2-4 pages in C how do you deal with it in Labview? You write it in C and combine with Labview or do something else. One line of C or any other langueage can take half the screen in Labview.

---

The first thing you need to do if you will be doing significant LabVIEW applications is to wrap your head around data flow programming. LabVIEW is not C and C is not LabVIEW. They both use two very different programming paradigms. Once you start thinking about designing your application to use data flow then things start to fall into place. As with any language you can write good code or you can write bad code. Like RavensFan said I find it hard to believe that a single line of C will consume half a screen when written in LabVIEW. The one area this may be true is if you are talking about algorithms. The solution for this in LabVIEW would be to use a formula node. This way you get the best of both worlds.

I'm curious about what you found contradictory though in my suggestions.

[AndyN]

I do not want this topic to turn into discussion on pros and cons of LAbview. I find it as a great software to do data acquisition, interface building and such but when it comes to writing algorithms with a lot of matrix, vector or scalar manipulation the fact that the plus , minus signs while loop or case structure sa take so much space makes it is hard to keep it in one screen.

I read somewhere before the suggestion about not using variables. In terms of execution performance it is a great thing but when it comes to use certain values in several mathematical operations in the beggining, middle and end of it, loops, case structures and such this becomes so unreadible. It is a visual language but with complex calcalations it is just hard to see what is going on on the screen. I am probably biased here but avoiding variables and trying to keep it to single screen size and making it self explanatory just does not hold up for me.

Anyway, that is nothing personal, I appreciate all your suggestions.

Anybody has any idea why Labview likes to slow down my application? I could not find any memory leaks. CPU is not too loaded  and it slows down at arbitrary occasions. It can be a day or 2 fine and then shows up again.

[Mark_Yedinak · Accepted solution]

Have you read through this post? It discusses global variables and race conditions. If you are using lots of variables you could be getting into a race condition where parallel parts of your code are becoming serialized because they are all trying to access the same variables at the same time.

With respect to the rest of your post that would be a topic for another thread. I will agree that text can be a much more compact and better way to represent algorithms. Complex mathematical algorithms can be difficult to represent in LabVIEW. As for using local variables I would disagree and say that it is possible to use a single wire to accomplish what you want. I think this becomes a matter of a better understanding of using data flow and some different approaches with the overall application architecture. Again though this is a topic for another discussion.

[AndyN]

I think you hit the right spot. I suspect that I might have some parts trying access the same variable or fighting over CPU. I 'll post when I find what it is. Over.

[AndyN]

I think it was caused by a race condition. It does not happen anymore after I cleared it.