LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Weird behaviour when entering a subVi for the second time.

Hi all,

 

My program consists of a producer/consumer design pattern that is used to control a user database of a test machine. The main program is called Users.vi and it is used to call other functions such as UserAdd and UserDelete. My problem comes from the UserAdd function. This function askes for a user name, then checks if this user exist and after that you get the option to delete said user. If you want to exit the function you press cancel. The first time I call this function from Users.vi everything works as expected until I want to close and press cancel. When I press cancel the program freezer. Until I press on another task like task manager, then when I go back to the labview program I can control Users.vi again. The problem gets worse when I try to open UserDelete multiple times. Then UserDelete just stops working and most of the times the program just complete freezer and I have to restart labview.

 

All of the files to make this function work are in the appendix.

0 Kudos
Message 1 of 10
(1,092 Views)

Hi Ongelofeloos,

 


@Ongelofeloos wrote:

All of the files to make this function work are in the appendix.


Nope, there still are missing subVIs and ctl/typedefinitions!

We cannot run the UserAdd routine…

 


@Ongelofeloos wrote:

If you want to exit the function you press cancel. The first time I call this function from Users.vi everything works as expected until I want to close and press cancel. When I press cancel the program freezer.


  • I guess this is related to heavy overuse of local variables and placing several loops hidden within cases. Using a sequence frames doesn't help here as you could easily use DATAFLOW to reach your goal…
  • It also doesn't help to use the "stop on FALSE" loop condition: usually you end UI handler loops with "stop on TRUE".
  • Do you really need to set several property nodes as fast as possible in those loops?
  • What's the point of outputting a FALSE in both cases of a case structure? (Why do you output a FALSE constant in one case and "NOT TRUE" in the other case?)
  • Why are there controls in your VIs without a label? What's the point of a hidden boolean control wired to a stop condition of a loop?

 

Did you debug your VI?

Where does the VI "freeze" when you press cancel? What happens inside the VI in this case? (As there is no event structure in the subVI it should not "freeze"…)

What about refactoring that UserAdd subVI into using an event structure to handle UI actions?

 

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
Message 2 of 10
(1,084 Views)

@GerdW wrote:

Nope, there still are missing subVIs and ctl/typedefinitions!

We cannot run the UserAdd routine…


I didn't want to send all of the subVI, but I forgot about the typedef, my bad.

 


@GerdW wrote:

We cannot run the UserAdd routine…



  • I guess this is related to heavy overuse of local variables and placing several loops hidden within cases. Using a sequence frames doesn't help here as you could easily use DATAFLOW to reach your goal…
  • It also doesn't help to use the "stop on FALSE" loop condition: usually you end UI handler loops with "stop on TRUE".
  • Do you really need to set several property nodes as fast as possible in those loops?
  • What's the point of outputting a FALSE in both cases of a case structure? (Why do you output a FALSE constant in one case and "NOT TRUE" in the other case?)
  • Why are there controls in your VIs without a label? What's the point of a hidden boolean control wired to a stop condition of a loop?

 


If these bullits are regarding the UserAdd function, this was written by someone else. I am still getting to that.

 

I seem to have fixed my UserDelete problem by only having one state that contains the event structure to monitor button presses.

0 Kudos
Message 3 of 10
(1,075 Views)

@Ongelofeloos wrote:

All of the files to make this function work are in the appendix.


  • If you still use LLBs, there is an option to mark the toplevel so we don't need to guess.
  • I recommend to get away from LLBs. They are somewhat antiquated and somewhat dangerous.
  • There is no need for greedy loops anywhere. You have many.
  • It is very dangerous to hide several event structures inside different cases of the same case structure (e.g. in "user delete")
  • +inf wired to an integer input seems a bit silly. "-1" is the correct input to read all rows.
  • How old is that code? (some of the file IO uses 90'ies style icon colors schemes 😮 ).
  • Except for the event structures and silver control styles, most code looks ancient. I.e. it predates the availability of "stop if true" for loops. It seems somebody overhauled the cosmetics without really improving the code (lipstick on a pig comes to mind 😄 )
  • I agree that this is not really debug'able. To do so, we need all VIs, a typical database file, and exact instructions how you use it. Tell us what you expect to see, and what you see instead.
Message 4 of 10
(1,030 Views)
  • If you still use LLBs, there is an option to mark the toplevel so we don't need to guess.
  • I recommend to get away from LLBs. They are somewhat antiquated and somewhat dangerous..

Is there a substitution for LLBs or should I just put all the subVIs in a folder structure?


  • It is very dangerous to hide several event structures inside different cases of the same case structure (e.g. in "user delete")

Yeah, that is what I discovered today :). I didn't expect it to be a problem since they were in different cases, but the problem for which I created this question is now solved.


  • +inf wired to an integer input seems a bit silly. "-1" is the correct input to read all rows.
  • How old is that code? (some of the file IO uses 90'ies style icon colors schemes 😮 ).
  • Except for the event structures and silver control styles, most code looks ancient. I.e. it predates the availability of "stop if true" for loops. It seems somebody overhauled the cosmetics without really improving the code (lipstick on a pig comes to mind 😄 )

I am working on it 😅. The last time someone worked on it was in 2004, I need to rewrite it all, and it is the first time I am using LabVIEW, besides some simple school assignments. I can tell you that this isn't even the worst part of the entire program, there are basically no design patterns used anywhere in the code, all the globals(of which there are a lot) are "read/saved" by a subVI, tons of loops into loops connecting to sequence structures connecting to loops and not a single event handler for UI.

Message 5 of 10
(1,010 Views)

@Ongelofeloos wrote:

 there are basically no design patterns used anywhere in the code, all the globals(of which there are a lot) are "read/saved" by a subVI, tons of loops into loops connecting to sequence structures connecting to loops and not a single event handler for UI.


Putting globals in a sub VI probably counts a s a design pattern. Globals kinda are SubVIs, so I don't really se the point (might as well make a FGV).

 

Pretty sure event structures where not there in 2004.

0 Kudos
Message 6 of 10
(977 Views)

A global in a subVI (with error terminals) would enforce dataflow just like putting it in a one frame sequence with error wires running through it.  You could enforce a write before a read in the same case, for instance.

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 7 of 10
(967 Views)

wiebe@CARYA wrote:


Putting globals in a sub VI probably counts a s a design pattern. Globals kinda are SubVIs, so I don't really se the point (might as well make a FGV).

 

Pretty sure event structures where not there in 2004.


That isn't what I was trying to explain. Every time a global in the global vi was changed, a separate SubVI was called to save all the globals to a .dat file. The file would first be read, then data is changed, and then the data is saved again to the .dat file. All the important data would be stored like this.

Capture.PNG

0 Kudos
Message 8 of 10
(958 Views)

@billko wrote:

A global in a subVI (with error terminals) would enforce dataflow just like putting it in a one frame sequence with error wires running through it.  You could enforce a write before a read in the same case, for instance.


Good point! (I don't use them, except in a class, made private. 😁)

0 Kudos
Message 9 of 10
(956 Views)

@Ongelofeloos wrote:

wiebe@CARYA wrote:


Putting globals in a sub VI probably counts a s a design pattern. Globals kinda are SubVIs, so I don't really se the point (might as well make a FGV).

 

Pretty sure event structures where not there in 2004.


That isn't what I was trying to explain. Every time a global in the global vi was changed, a separate SubVI was called to save all the globals to a .dat file. The file would first be read, then data is changed, and then the data is saved again to the .dat file. All the important data would be stored like this.

Capture.PNG


O, I don't mean it isn't silly. But you can't really blame them for not using event structures. 

 

LabVIEW programming style improved a lot in 20 years. Back then good code was code that 'worked'.

0 Kudos
Message 10 of 10
(954 Views)