LabVIEW
Is there a way to ignore Value Signaling event in event structure?
Solved!
Could you go into a little more detail? This sounds a little strange, and there might be a better way to do it... Code (not a picture) would be helpful as well.
Why are you using a while loop to continuously read your input and set Value Signaling property when the Value Change event will trigger by itself once your input change it's value?
All you need is a Event Structure with Value Change case on your input...
Hi linu,
@linu95k wrote:
I have an input control which needs to be monitored continuous and the value change event needs to do something in response to it. They way I am implementing the code is by using a while loop which continuously reads this input and then a value signaling property not to generate an event. I need to however ignore the event under special conditions. Is it possible to ignore a value signaling event?
Please explain "what" you want to achieve and not "how" you actually implemented it…
@linu95k wrote:
They way I am implementing the code is by using a while loop which continuously reads this input and then a value signaling property not to generate an event.
Why do you generate an event using ValueSignalling when you don't want to generate an event?
@linu95k wrote:
I need to however ignore the event under special conditions. Is it possible to ignore a value signaling event?
You can "ignore" the event using a condition and a case structure. What is your "special condition"?
Again: why do you create the event in the first place when you don't want to handle it?
Again: what do you want to achieve, not how…
Hi linu,
@linu95k wrote:
However I am getting a light curtain interruption even though nothing is interrupting it. And this occurs randomly. Hence I considering to disable it and monitor it in some other way. With altering my existing functionality.
So the problem already starts in the DAQ loop? (You should start by logging your DAQ data to be able to examine them!)
Have a switch in the DAQ loop for debugging. Use that switch for a case structure, where the ValueSignalling is in one case and a Value property node (or local) is in the other case…
@pitol wrote:
Why are you using a while loop to continuously read your input and set Value Signaling property when the Value Change event will trigger by itself once your input change it's value?
All you need is a Event Structure with Value Change case on your input...
Events are primarily for user interactions. No, a programmatic value change (writing to a terminal, local variable, or value property) will not trigger a value change event. That's why we also have the (often misused) signaling value property.
@linu95k wrote:
Unfortunately I cannot share the code as it is confidential. However this is what I am trying to achieve - I have a light curtain which acts like a sensor and results in output voltage value change when something is interrupting it. It is like a safety feature. The output of the light curtain along with output from other sensors is connected to a DAQ input channel. So my while basically has the DAQ read VI which reads the input and generates value signal event for the control.
Since the value change occurs programmatically using a local variable or assigning value using value property node would not generate the event.
My code works fine however i am facing a certain bug.
The light curtain value change only needs to be evaluated when the test is running and needs to be ignored in other cases. Which is handle using boolean logic. And the logic works fine.
However I am getting a light curtain interruption even though nothing is interrupting it. And this occurs randomly. Hence I considering to disable it and monitor it in some other way. With altering my existing functionality.
I agree that this is completely backwards. Why is it a "control" if the user never interact with it? (note, a signaling value change can also be linked to an indicator, but please don't!)
Instead of writing to a signaling property of a front panel element, just e.g. write to a queue and have the queue handler loop decide to either act on it or ignore it (empty case), depending on program state. The data should not even involve the front panel in any way.
Let me get this straight.
You are polling a condition to generate a Value Changed (Signaling) Event?
