LabVIEW
FGV freezes in the middle of execution
@RavensFan wrote:
@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?
It's TOO clean for me. There is not a single scrap of ducumentation to tell us what the various cases do. BUT, I do get what this is doing. If -1 (can't find a match) add the data to the arrays, otherwise do nothing. As for the "Index Array", I'm guessing it is dead code and was never removed. But we'll never know because there's no documentation to let us know what is going on. You can never have "too much" documentation, but you'll always have "not enough". Guaranteed.
I would also make "Operation" a typedef because you never know when you are going to add another operation. If you didn't make it a typedef, you would have to manually go to each instance of this VI and replace the enum. Which takes me to another point. Get rid of the "Default" for your FG case structure. This will force you to create a new case (or add to an existing one) upon updating the enum, assuring that you are running the correct code, and not some "default" case.
This how it would look if I constructed this VI. As a contractor, I try my best to document things well so there will be few questions for the next person that needs to modify it. It's a good way to get good references. 😄
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.
[edit] oops, I would have the controls outside the loop as well. [/edit]
@flowschi wrote:
- Is the usage of colors known to slow down or make LabView freeze?
No, but coloring the diagram background with a color typically used for the front panel causes confusion and adds a few hundred milliseconds whenever the programmer needs to look at it. It is a no-no, similar to writing in all caps (see the usability section). It is a subtle hint to us that the programmer sets priorities for odd random cosmetics over rigorous coding and we can assume that other things are not quite what they seem at first glance. The outside background is irrelevant if the diagram window is sized correctly, so it also could tell us that the programmer is a friend of maximising all windows to the screen, another annoying habit to some of us. Of course there are other possible reason for the darker background selection. If the programmer has problems with glare from the white background, he should see an opthalmologist, because ther could be problems such as cataract or worse (or maybe he should clean his glasses more often :D)
Sorry, I cannot help with the original problem unless there is a way for us to reliably reproduce it. Maybe there is a bug in LabVIEW. Can you boil it down to an absolutely minimal set of simple VIs that still show the problem?
