SubPanel

[MikaelH]

I have an issue with a Sub Panel in a generic GUI VI we use as part of our company's OO based application framework.

Most often the SubPanel behaves like it should.

But sometimes after the application has stopped, the VI that was last inserted into the SubPanel, is still inserted according to LV.
When this happens (and I start the application again) I can't insert that VI into the SubPanel again, I can insert other VIs, but if I try to insert the last Inserted VI, LV says:
Error 1145: Cannot open VI because it is already in a subpanel control.

If I try to open the VI's FP, LV opens the FP of the GUI VI that has the SubPanel (just like it should if it was inserted), but the SubPanel is Empty.
And LV behaves the same, even after the SW stopped?!?!
When LV stops all SubPanels should be emptied (i.e.all inserted VIs should be thrown out.)

 

Has anybody else experienced this strange behavior?

Our framework is doing something that LV doesn't like of, but I haven't figured it out yet.

We do see one strange behavior as well.
We start up the framework with a VI that kicks off some processes (just like you do in Actor Framework), and when the framework starts up and starts inserting stuff in the SubPanels, the Top VI becomes broken, but it's still running.

Have you guys seen this as well?

 

 

[JKSH]

1 hour ago, MikaelH said:

Most often the SubPanel behaves like it should.

But sometimes after the application has stopped, the VI that was last inserted into the SubPanel, is still inserted according to LV.
When this happens (and I start the application again) I can't insert that VI into the SubPanel again, I can insert other VIs, but if I try to insert the last Inserted VI, LV says:
Error 1145: Cannot open VI because it is already in a subpanel control.

If I try to open the VI's FP, LV opens the FP of the GUI VI that has the SubPanel (just like it should if it was inserted), but the SubPanel is Empty.
And LV behaves the same, even after the SW stopped?!?!
When LV stops all SubPanels should be emptied (i.e.all inserted VIs should be thrown out.)

When you say "LV stops", I'm guessing you mean you stop your VI and return to Edit mode? Note that LabVIEW itself doesn't stop.

Anyway, are you talking about cleanly shutting down your VI, or aborting it?

• If clean shutdown: Does it help if you make your framework explicitly un-insert subpanels during shutdown?
• If abort: I'd guess it's a reference that wasn't released properly.

 

1 hour ago, MikaelH said:

We start up the framework with a VI that kicks off some processes (just like you do in Actor Framework), and when the framework starts up and starts inserting stuff in the SubPanels, the Top VI becomes broken, but it's still running.

Have you guys seen this as well?

I haven't seen this, but it looks like a bug.

As @Aristos Queue said in https://lavag.org/topic/20315-xnodes-prevent-inlining/#comment-123550 -- "Only squeaky wheels get grease", so do submit a reproducible example to NI if you can! 

[MikaelH]

Yes, I mean when the VI finish, and it goes back to edit mode.

I do stop all the VIs in a clean way, and ask them to be remove from the sub panels before the Vi finish.

I will try to create a small application that shows the issue to NI.

[shoneill]

Yes, I see this "Running but broken".  I also see cases where a VI LV thinks is deployed is a different version from the one actually deployed.  Or VIs bein broken because of errors in VIs which aren't even used on the target..... I've had RT VIs claim they were broken due to an error in a VI which is only used on our FPGA targets..... Something somewhere is very weird with the whole handling of these things.  I've been harping on about it for years and I'm glad (please don't take that the wrong way) that others are starting to see the same problems.  Maybe eventually it'll get fixed.

 

Of course, the problem is tat in making a small example, the problem tends to go away nicely. NI really should have a mobile customer liaison (a crack LV debugger) who travels around visiting customers with such non-reproducible problems in order to get dirty with debug tools and find out what is going on.  There are so many issues which will never be fixed because the act of paring it down for NI "fixes" the problem.