LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Value (signaling) and runaway event structure

Solved!
Go to solution
Highlighted

Hi, I'm hoping yall can help me figure out an issue I'm having with some code.  I've simplified my vi and removed everything that doesn't impact the issue.  Please see the attached vi.

 

 

When I change "Logging?" from true to false, the buttons on my front panel becomes unresponsive and the while loop just runs over and over.  I know this has to do with the way the Value (signaling) propery and the event structure work, but I would think that the event should only trigger once.  It behaves as expected if I use the Value property, but I need the signalling property to trigger the event structure to refresh some indicators on the screen..

 

Take a look at the vi and let me know what I'm doing wrong!

 

Thanks,

 

-Kevin

0 Kudos
Message 1 of 10
(1,400 Views)
Solution
Accepted by topic author gintree78

You've created an endless loop because the event cause you are causing is firing the Value signalling event which causes the same event to run again.  That coupled with the setting on that event case where it is set to lock the front panel until the event completes means you never have a chance to turn off that boolean button to stop the value signalling.

 

The quick fix is to uncheck the Lock Front Panel setting.  But that is just a bandaid because the event calling itself is kind of an awkward architecture.

0 Kudos
Message 2 of 10
(1,390 Views)

Thanks for the quick reply.  That makes sense about the locked FP, but I'm a little confused on the value signaling event.

 

Is the value signaling event considered a "value change" by the event structure regardless of the previous value?  It seems like it should only trigger the event once (when the radio button selection is changed). All the subsequent loops, the radio button value doesn't change.

 

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

Yes, Value(Signaling) is always a value change event, regardless of whether the value actually changed or not

Message 4 of 10
(1,368 Views)

Your problem is that you have all of your Events in the same Event Case.  Walk through the logic:

  • Start with Logging off (False).
  • Loop starts running, there are no Events (since nothing is yet changed), so it "hangs" waiting for an Event.
  • Push Logging On (True).  Event loop fires, Current Run gets enabled.
  • Event loop "hangs", waiting for Event.
  • Turn Logging Off (False).  Event loop fires, Run 1 Radio is set with Value Signalling.
  • Event loop fires (Run 1 Radio), Logging still False, Run 1 Radio is (again) set with Value Signalling.
  • Now we are in an endless loop.  You only have one "Event" bit of code that everyone influences.

In reality, you have three controls (Logging, Run 1 Radio, and Close/Stop), each of which does one thing.  Put each in an Event Case of their own.  Ask yourself the following question(s):

  • What (one) action do I want to do when Logging is turned on?
  • What (one) action do I want to do when Logging is turned off?
  • What action do I want to do when Radio changes to Log File?
  • What action do I want to do when Radio changes to Current Run?
  • What action do I want to do when Close is pressed?

Program each of those cases.  Note that you should (probably) avoid Value Signalling if practical (you can easily fall into a hole, as you've seen).  What is the purpose of the Radio button?  Why is there a Logging button, if all it does is turn on the Radio button?  Seems to me there are too many controls (and no obvious "Start" button).

 

Bob Schor

0 Kudos
Message 5 of 10
(1,358 Views)

Thanks for the feedback everyone.  I've attached an updated vi that resolves the issue.  Basically, I only call the value (signaling) event the first time after "Logging" is changed from true to false.  

 

That being said, Bob I agree that this is probably unnecessarily complex.  I'll play around with making an event case for each event.  To answer a couple of your questions:

 

-The radio button is allow the user to change the output displayed to them on the FP.  In this example it's just a simple string, but the the actual vi it is different data sets in an XY graph.  They can either view data from a log file or view data from a process that is currently being run on the system.

 

-The logging button in this example is to emulate a value that is passed into the vi from the main vi.  When the system is actually logging data from a run, it's true.  If they system is idle and no data is being collected, it's false.

 

The idea behind all this is to disable the "Current Run" radio button when the system is not in process collecting data.  If they were looking at Current Run data and the process ends and stops collecting data, the display kicks over to historical data and disables the "current run" radio button until another run starts.

 

Thanks for all the help!

0 Kudos
Message 6 of 10
(1,344 Views)

@gintree78 wrote:

That being said, Bob I agree that this is probably unnecessarily complex.  I'll play around with making an event case for each event.


I'll say it's overly complex.  Take a look at the enclosed (this is a LabVIEW Snippet -- open a blank LabVIEW 2015 Block Diagram and drag this image into it -- it will automagically become LabVIEW Code).  I simplified disabling the Radio Button Control (I disable the entire control, much simpler).  Why do you think I put the extra Value Signalling property node outside the While loop?  And what's with that error line, anyway?  [Did you see the word "Display" in your Display indicator?  Extra points for figuring out how to see it ...].

Event Demo.png

Bob Schor

0 Kudos
Message 7 of 10
(1,317 Views)

Oops.  There's a subtle logic flaw in my demo -- a prize to the Original Poster when he (or she) finds it.

 

BS

0 Kudos
Message 8 of 10
(1,315 Views)

@Bob_Schor wrote:

Oops.  There's a subtle logic flaw in my demo -- a prize to the Original Poster when he (or she) finds it.

 

BS


Oh, oh, oh! *waves hand* could it have to do with ordering? Btw i've had issues with using the control in the event structure like that a couple of times, and had to use the NewVal instead.

/Y

G# - Award winning reference based OOP for LV, for free! ADDQ VIPM Now on GitHub
"Only dead fish swim downstream" - "My life for Kudos!" - "Dumb people repeat old mistakes - smart ones create new ones."
Certified-LabVIEW-Developer
0 Kudos
Message 9 of 10
(1,309 Views)

@Yamaeda wrote:


Oh, oh, oh! *waves hand* could it have to do with ordering?


No fair!  You were not the Original Poster!  

 

I also almost always use New Value, but wanted to keep it as basic as possible to focus on (what I see as) the "best use" of the Event Structure.  In my experience, having an Event case handle one Event and do one thing (more and more, that "thing" is to send a message to a Message Handler/State Machine loop) leads to cleaner, leaner, and "more likely to (a) be correct and (b) do what I want it to do" code.

 

Bob Schor

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