LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Program unresponsive after a dialog box input

Background:


I have built a program that utilizes a state machine to step through different functions and scenarios. I use an event structure to move from one state to the next. One of my states is for settings, where the user presses a settings button and tab control box pops up using property nodes to make any changes the user wants and then disappears and enables the main portion of the program again. I recently decided to use some dialog boxes to clean up the interface and code a bit. I use a two button and a three button dialog box because it is only for confirmations if the user wants to erase data, so all I need is basically a yes and no button. The output of that dialog box goes into a case structure that makes the appropriate changes based on the input from the user through the dialog box.

 

Problem:

 

The issue I am running into is, when the dialog box executes, the changes are made correctly but my program becomes unresponsive afterwards. I can no longer click on any of the buttons or controls on the front panel and I have to use the abort execution to halt the program since I can't click the stop button to cancel my while loop anymore.

 

I know it is not my original program because it worked perfectly before, when I was just disabling/enabling and changing the visibility of different tab controls, so I know that the dialog box is the problem.

 

 

I feel like this should a pretty easy fix but I just can't seem to figure it out. I can always revert my code to go back to the tab controls but the dialog boxes are much cleaner and nicer so I would like to use them.

 

Any suggestions/answers/hints on how to solve this issue would be immensely appreciated.

 

Thanks,

 

Bronson

0 Kudos
Message 1 of 12
(4,337 Views)

seems that the dialog is not exiting your loop...is it wired to a stop terminal? please post your vi

0 Kudos
Message 2 of 12
(4,335 Views)

The main VI is the "D-Key Cycle Tester 2"

 

To simulate the error from the front panel:

 

>start VI

>Press Settings Button

>Press Clear Graph Button

>Press any of the dialog box inputs

 

 

To find my dialog box code on the Block diagram:

 

>go to the "Settings" case of the case structure

>go to event [6] "<Clear Graph>: Value Change" of the event structure

 

 

To observe my previous method with the tab controls:

 

>start VI

>Press Settings Button

>Press Count Reset Button

>Press either of the buttons on the prompt

 

 

I am still a beginner with LabView and this is really my first program that I have made, so I apologize if the code is hard to follow.

 

Thank you for looking into this,

 

Bronson

0 Kudos
Message 3 of 12
(4,321 Views)

The main problem is your use of dynamic events (change all to regular events) and you will see the difference. The minor is property nodes....your architecture is called an "event driven state machine."

0 Kudos
Message 4 of 12
(4,292 Views)

I originally tried to use regular events to drive the state machine but I had a problem with that too. If a button was pressed, the event structures would keep executing as if I was continuously pressing that same button. I couldn't make a button press execute only once without using dynamic events. Is there a way around this?

 

Also, I am not sure what the problem is with the property nodes, could you expand upon that?

0 Kudos
Message 5 of 12
(4,229 Views)

I woudl recommend reading up on event structures.  It sounds like you might be missing something.

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 6 of 12
(4,225 Views)

I have already read most of the NI pages on event structures and I still can't pinpoint why it doesn't work. The regular events still freeze up my front panel.

 

You can see this for yourself by changing the "play button" or "settings button" event cases to regular eventsin the "Ready To Cycle" state.

0 Kudos
Message 7 of 12
(4,211 Views)

Why so many Event Structures?  No wonder you are getting double events.  You should have ONE event structure.  You should have a case just to read the events.  There is no need for the dynamically registering for the events.  That just adds too much complexity.  And where you are writing to your DIO, make a single 8-bit port to write to instead of the many lines.  Then you can pass around a U8 instead of an array of 8 booleans (that would use 1/8th the memory).


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 8 of 12
(4,197 Views)

@bronsonmock wrote:

I have already read most of the NI pages on event structures and I still can't pinpoint why it doesn't work. The regular events still freeze up my front panel.

 

You can see this for yourself by changing the "play button" or "settings button" event cases to regular eventsin the "Ready To Cycle" state.


What you probably didn't read was LabVIEW help for event structures, "caveats and recommendations for using events."

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 9 of 12
(4,193 Views)

@billko wrote:

       What you probably didn't read was LabVIEW help for event structures, "caveats and recommendations for using events."


 

Thanks, That one was helpful. I think that article is pointing to what Crossrulz is hinting at.

 

 


@crossrulz wrote:

Why so many Event Structures?  No wonder you are getting double events.  You should have ONE event structure.  You should have a case just to read the events.  There is no need for the dynamically registering for the events.  That just adds too much complexity. 


crossrulz, I believe what you are saying is to have a case that handles the events, executes the other cases based off the events, and then returns back to the case that contains to the event structure to wait for the next event. Correct me if I am wrong in that description, but as is, that makes sense. The only thing that I am getting hung up on is in some cases I need to use the timeout feature of the event structure because it is timing based in that part of the program. I am unclear on how to accomplish this if I only have one case that handles the events.

Any suggestions?

0 Kudos
Message 10 of 12
(4,187 Views)