LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Event Structure in Sub-VI not triggering when I write to Sub-VI's control.

Solved!
Go to solution

I am writing some code to control a process and I need the progrom to register events from HW inputs (selector switches wired to DI module). All the events will be triggered based on HW I/O with my application running headlessly (no GUI) on a cRIO.  Since this is a process, the control sub-routines are linear and occur sequentially. Which means I cant have timeouts holding up my application.

 

Basic sequence of how my top level VI is going to functions

 

while loop[

Read cluster from shift register from previous iteration--> Read inputs and update cluster values --> Have sub-vi's do stuff based on value change events to front panel controls that are update from cluster (multiple sub-vis sequentially)--> Write values from output cluster to HW outputs--> Write Cluster to shift register for next iteration.

]

 

The event structure in the sub-vi's Reads/Writes to data cluster that is then passed on to other sub-routines.

 

Think of it as

"If a thermal switch #1 trips (value change, if new value is true) turn pump 1 off"

or

"If boolean value changes on the front panel control, do something based on the New Bool State".

 

The reason I chose the event structure is because I dont want to continuously pole current values and compare them to stored previous values to identify a change in input state. In the event strucutre, I set a low time-out value so that if an event hasnt occured, its will execute the default logic in the time-out event and then move on to the next sub-vi.

 

Im not sure I am using the event structure properly. A few things that I am not clear on-

 

1.Does the event structure recognize changes if the event happens between iterations after it has timed out (and executing other code)?

example- Say the event structure times out in the sub-vi. On the next loop iteration, mode code reads the inputs (in a different sub-vi) and updates the data cluster read from the shift register that is passed to the sub-vi. The data cluster is written to the front panel control of the sub-vi which have changed since the previous loop iteration. Will this trigger an event if a specific element in a cluster has changed value?

 

2.  I have read that event structures have a "queue" to record multiple events and respond accordingly. If the event structure works as described in #1, how does this work when used in a sub-VI (event are based on changes to the front panel control where multiple changes can trigger multiple events) and multiple events are triggered simultaneously between iterations? Will the queued events execute in the next few iterations? or Execute in the same iteration? If they happen in the same iteration, how does this effect the reading/writing of a single cluster that is shared by all the events without a shift register?

 

I have attached a reduced version of my code that should illistrate what im trying to do how the front panel changes to the subvi arent registering as events.

 

0 Kudos
Message 1 of 9
(3,153 Views)

Unfortunately I can't view your code (best practice is to back-save it several versions so more people can see it).

 

However, it sounds like you don't have the correct idea of how an event structure responds. I don't believe a changing input fires a value change event. If you need to detect a changing value externally from the SubVI, you have a couple of options:

  1. Detect it where it happens, and tell the SubVI what action to take (with an enum for example), or run a different SubVI altogether.
  2. Use a feedback node inside your SubVI. The first iteration you run should run a different case to "initialize" the feedback registers (with "first call?" for example)
  3. If your SubVI and it's caller are meant to execute in parallel, you can use the oddly named "User Events". Think of this as a "Custom Event" which you can configure to your liking. It works very similarly to a queue.
0 Kudos
Message 2 of 9
(3,142 Views)
Solution
Accepted by srs14

@srs14 wrote:

Im not sure I am using the event structure properly.


A cRIO with no GUI, then you are not.  The only thing that can register on an Event Structure in this situation is User Events.  Even then, Event Structures will not tell you if an input to a subVI changed.  For that, you need to use a Feedback Node (to hold the previous value) and a Not Equal (to do the comparison between the current value and the current value).


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 3 of 9
(3,121 Views)

Thanks for the reply.

 

Just to be clear-

 

1-the event structure is inside the sub-vi

2-the event structure is triggered (atleast I intended it too) from changes made to the front panel control of the sub vi (front panel control is wired to a external cluster from the main loop).

 

The main reason I tried to do it this way is because it's simpler to code the logic. Using a feedback node and conparison logic seems clunky and archaic. Instead of weeding out the possible conditions for every combination of inputs every loop iteration (feedback node with comparison), I can define specific behavior only when a specific set of conditions. Then if no change is detected, execute default logic while if no event occurs.

 

An example would be resetting a timer and unlatching some pump relay outputs only when the off mode is selected (mode value change event, mode= off?, reset timer and lockouts) yet only executing it once (as opposed to continuely executing/comparing with the feedback node, mode=\=prevmode?, mode=off?,  if true, reset timer and lockouts.

 

i also didn't want to detect the changes at the "read inputs" portion of the code because this would link some dependence in behavior between the "read inputs" sub VI's and the "execute logic based on inputs" sub routines/VI's. I wanted to decouple the behavior between sub-vis as much as possible. For easier troubleshooting.

0 Kudos
Message 4 of 9
(3,103 Views)

@srs14 wrote:

1-the event structure is inside the sub-vi

2-the event structure is triggered (atleast I intended it too) from changes made to the front panel control of the sub vi (front panel control is wired to a external cluster from the main loop).


That has never been how Event Structures work.  Event Structures key off of users interacting with GUIs.  You programmatically changing a value does not trigger an event unless you use the Value Signaling property, that but will trigger the event even if the value did not actually change.


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 5 of 9
(3,081 Views)

@srs14 wrote:

 

1-the event structure is inside the sub-vi

2-the event structure is triggered (atleast I intended it too) from changes made to the front panel control of the sub vi (front panel control is wired to a external cluster from the main loop).

 


You might not understand the Principle of Data Flow, which governs how LabVIEW works.  Each time you call a sub-VI, you pass it a single Value to its Front Panel control.  If this Value comes from a Control on the Top Level VI, where the User can "see" and push it, then it get the Control's value at the time it is called, and (correctly) ignores any changes you make on the "visible" Front Panel Control until the sub-VI is called again (and the potentially-changed value is passed in to the sub-VI).

 

If, on the other hand, you pass a reference to the Front Panel control to your sub-VI, your sub-VI will have to periodically use the reference to see if the Control has changed, effectively "polling" the Control (something it is good to avoid).

 

A Solution is to put a Value-Changed Event case in the Top-Level VI.  When it sees the Control changed, it can call (as appropriate) "SubVI Turn On", "SubVI Turn Off", or "SubVI Changed (On-Off Value)" (the last being a SubVI with the value of the Control passed as a parameter to the subVI to handle both On and Off cases, up to you).

 

Bob Schor

0 Kudos
Message 6 of 9
(3,069 Views)

I have attached my program down graded to LabView 2012.

 

0 Kudos
Message 7 of 9
(3,065 Views)

@Bob_Schor wrote:

A Solution is to put a Value-Changed Event case in the Top-Level VI.  When it sees the Control changed, it can call (as appropriate) "SubVI Turn On", "SubVI Turn Off", or "SubVI Changed (On-Off Value)" (the last being a SubVI with the value of the Control passed as a parameter to the subVI to handle both On and Off cases, up to you).


Bob, read through the thread again.  cRIO with no GUI.  Front Panel events will not work.


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 9
(3,057 Views)

@crossrulz wrote:

@Bob_SchorBob, read through the thread again.  cRIO with no GUI.  Front Panel events will not work.

Oops, missed that ...

 

BS

0 Kudos
Message 9 of 9
(3,051 Views)