latch until realased-switch

[Kolos]

Hi!

I have an external (real-physical) push button, which works like latch until released buttons... I watch with a Daq-assistant,if it's pressed or not (the Voltage will changed...) . I wan't to begin to send a signal, if i pushd the button, and i want to stop it, when i pushd it once more... But i have no idea how to do it... my program now send signal until my button is released ...

Any idea? 

[RavensFan]

Your description of what you want the button to do is not that clear.  But I am going to guess you actually want either the switch when pressed or switch when released button actions.

Don't confuse the term "latch" in LabVIEW with a mechanical latch.  In LV, "latch" means the buttons holds its value until the terminal is read in the block diagram,  at which time the button returns to its default state.  The "switch" buttons are the ones where the button will hold its value until the user goes and hits the button again to release it back.

[Kolos]

Yes, i wan't a switch when pressd button-action...But i don't want any LabView-button in my program... I wan't to make it with my own phisycal button... I have a  battery, and my button...when i push the button, my daq-assistant sense that, the Voltage changed from 0V to 5.28V. When i release my button, the Voltage will be 0V again...

My project now send a signal, if the Voltage is 5.28V.

But i wan't different. I wan't to send the signal after i pressd until i didn't pressd it once more...

Here is a picture from my program: 

[RavensFan]

It is hard to debug a screenshot.  What is going on in the right hand DAQ assistant?  What is the output it is doing?

Forget the output for a minute, does the boolean indicator on your front panel behave the way you want it to?

Your physical push button, is it a momentary type of push button, or is it a maintained contact?

By the way, you should create a stop button for your program instead of using a true constant on the loop's continue terminal.  Right now the only way to end the program is to abort it.

[Kolos]

In the right hand daq assistant now i send a sinus signal to my daq, and in my daq there is a megaphone, so it make a bip-noise... But there can be a led too or anything else... 

The indicator now light, when i push the button, and hold it. When i release it, it's blow out... 

My physival push button is a maintained contact. Until i hold it, there will be a contact. When i released it, there will be no contatc. 

[RavensFan]

Are you sending a sine wave or a sinus wave?  They are two different things.  A sine wave is the classic oscillation.  A sinus wave is a heartbeat rhythm.

I'm still not clear on how you are using the button.  Your English is failing me

"My physival push button is a maintained contact. Until i hold it, there will be a contact. When i released it, there will be no contatc."  

Do you mean "While I hold it, there will be contact"?

If you push your physical button then let go, does the button stay pressed in, or does it immediately pop back out?  The former is a maintained  switch, the latter a momentary switch.  With a maintained swtich, you would press it again and let go for it to return to its original position.

[Kolos]

Sorry for my english...

I think its a sine wave, but it dosent matter... 

Yes, i mean, while i hold it... 

my button pop back out, if i release it...

[RavensFan]

Okay, so you have a momentary contact push button.  The first time you press it, you want your boolean to go from False to True.  The next time you press it, you want it to go from True to False.

You will need two shift registers, one to hold the value of the input from the last loop iteration so that it only acts on the False to True transition.  The implies function on the boolean palette helps with this.  The other that is your boolean of interest and it uses an XOR to toggle its value.

One thing you may have to worry about is debouncing the signal coming in from the switch.  A hardware switch may stutter on and off in fractions of a section when it is first pressed.  If this becomes a problem, you may need to set up a debounce filter in on your digital input circuit.

Message Edited by Ravens Fan on 06-29-2009 10:05 AM

[Vaibhav]

Hi Ravens Fan,

Kolos hasn't replied if he got his answer or not.

I am surfing the forum to for some answer to the behaviour "Switch Until Released" and saw this thread.

Just out of my curiousity, does your above mentioned diagram differ in "any" situation from the one given by Norbert here?

I have made two programs from both of these diagrams, and they work the same. So just curious to know when these two will differ, if at all. Any advantages/disadvantages over performance, if on a big scale?

[RavensFan]

I'd say Norbert's code is a little bit cleaner, but I was happy to get the boolean logic working on my example.

I think there is one main difference between our two examples.  When I answered the question, the person looking for a way to have this behavior based on an external push button.  Since I didn't have hardware to test it on, I had to use a software button inside the code.  I couldn't use an event structure because the even is actually based on an external event rather than a software event such as a FP button press.

Norbert's example was answering someone's question who wasn't using an external button, but was asking about making a software button work the way he wanted.  So Norbert had a different starting point which lead him down a different path where an event structure is more logical.

In general, an event structure makes for a better program than a polling method. But since I was starting from an external button, I needed to do something in a way that continually checked the status of that digital input.  There may be a way to use Norbert's method using an external button if the event structure can be configured to act on a DAQ event.  (Probably, but that is a discussion for a different thread.)  His method could also be used along with a bit of a hack to read an external button.  I could have a separate parallel loop reading the digital input and have it directly feed to a front panel boolean using the Value(signalling) property node.  Then his event structure could be used to react to that front panel indicator.

In summary, I think either method is valid.  They were just two different methods to have the same program behavior that was acting on two different types of inputs (hardware button vs. front panel control.)