LabVIEW
FGV freezes in the middle of execution
Hello,
we are dealing with a very strange issue here.
We have EOL-Tester which uses LabView to operate, so quite a lot of VIs are running. From time to time the whole system seems to freeze. What I found out so far, is that one of our basic-VIs gets stuck somehow. See this screenshot:
It stays here forever. I was not able to put probes there before the error occures, but I was able to walk down the called VI hierachy until I reached that point. It's just a simple FGV. The arrays in the FGV contain ~90 entries all the time. It's just Queue Refnums and Strings.
Are there any ideas how this can happen or what we can do to solve it?
Thank you!
@flowschi wrote:Hello,
we are dealing with a very strange issue here.
We have EOL-Tester which uses LabView to operate, so quite a lot of VIs are running. From time to time the whole system seems to freeze. What I found out so far, is that one of our basic-VIs gets stuck somehow. See this screenshot:
It stays here forever. I was not able to put probes there before the error occures, but I was able to walk down the called VI hierachy until I reached that point. It's just a simple FGV. The arrays in the FGV contain ~90 entries all the time. It's just Queue Refnums and Strings.
Are there any ideas how this can happen or what we can do to solve it?
Thank you!
No ideas from the scant information you posted, but if you attach the actual FGV (meaning the VI itself), so we can examine all of the code in addition to the single case shown in your picture, we might be able to suggest where the problem lies.
[Why do so many posters come to the LabVIEW Forums asking "What's wrong with my code", and expect useful and intelligent answer when they don't show us the code in a form useful to us, namely by attaching the VIs in question?]
Bob Schor
@flowschi wrote:
We have EOL-Tester which uses LabView to operate, so quite a lot of VIs are running. From time to time the whole system seems to freeze. What I found out so far, is that one of our basic-VIs gets stuck somehow.
Who wrote the code? Why is the diagram background creatively colored? What's in the other cases? What are the reentrancy and priority settings of the subVI? The number of VIs and the fact that they are running under LabVIEW is not correlated, so why mention it? Why is the VI set for execution highlighting? That will definitely slow it down.
And a picture of a VI is like a picture of text code with all the functions collapsed. Neither does anyone much good. 😄
@flowschi wrote:Sorry for the poor Information in the first post, I will try to deliver it now.
Who wrote the code? Why is the diagram background creatively colored? What's in the other cases? What are the reentrancy and priority settings of the subVI? The number of VIs and the fact that they are running under LabVIEW is not correlated, so why mention it? Why is the VI set for execution highlighting? That will definitely slow it down.
- The code was written by us.
Very clean block diagram. A couple of comments. One thing to clean up is that in the Add then Default cases of the case structures, you have the array of queues wire running underneath the Index Array. It makes it look like the output of that function is the array of queues wire. That index array needs to be moved down and a wire cleanup done. Is there something missing? You don't seem to do anything with the queue references you add to or get from this VI. Should you have a terminal that outputs the retrieved queue reference?
Also, I prefer using Build Array when I know I'm adding an element to the beginning or end of an array rather than Insert into Array. But that shouldn't be causing you any problems here.
Also, I don't understand why you'd capitalzie the M in "ReMove".
- Is the usage of colors known to slow down or make LabView freeze?
No. But it makes LV programmers slow down or freeze when they need to deal with the headache they get from looking at the block diagram.
- I will attach the VI
- The VI (FGV) is not reentrant and normal priority.
- Sorry for mentioning useless information for you...
- Execution highlighting was of course set to make it visible where the VI is waiting/stuck at the moment
The VI is beeing called frequently from different places.
The screenshot I posted in the initial post showed the calling VI with having the Operation "GetList" wired. But the frontpanel of the FGV showed the control set to "Add". So I assume, that this is the case it got stuck and that the calling VI from the screenshot was just waiting for it and not actually executing it.
This is very interesting. I'd take the recommendation of others and move the controls outside of the while loop. I know there can be issues at times if the controls aren't on the top level of the diagram. (Search for the "Clear as Mud" thread for an explanation.)
The VI Analyzer shows some helpful items, but I don't see any problems related to this issue.
