01-25-2006 03:05 AM
Nishant wrote:
Hiiii,Ayman
I think this will work for you, and another thing is you can't implement 2 loops simul, coz as per ur vi, if u press the button for stopm, control will go in that loop and it will rotae in that iteration upto which you wont stop it. i am attaching the vi with this.
Thanks,
Nishant
Thanks alot Nishant,
But I'm afraid it doesn't work for me .. But I really appreciate your reply .. Thanks and dorry for the late reply.
01-25-2006 03:11 AM
@tst wrote:
I couldn't look at Nishant's code as it's 7.1, so attached is an example of what I meant. Note how much simpler it is and how it is less likely to go wrong. This is what I mean when I refer to going for the simple solutions. The same thing could be done with an event structure and a timeout case.
01-25-2006 04:16 AM
If you had used the timeout case I suggested, you might have found it easier (see attached example).
Some other notes:
You should always place some sort of waiting mechanism in loops to avoid starving the CPU (the timeout function does that in the event structure).
To fire a value change event, you can't use a local variable. You need to use the Value(signaling) property. Note that I changed the code to only change the value when the value of the second button changed. Without doing that, the event would have been constantly fired, even if you wire the same value into it.
In truth, using an event structure for something like this is not necessarily recommended. At the moment, the event structure is mostly a UI device and as such should be used to process UI events, not to control code execution. You can use the VIs in the Advanced>>Synchronization palette to get more control over this. You can look at examples like queued state machines and a producer-consumer architecture to see how this is implemented.
01-25-2006 05:14 AM - edited 01-25-2006 05:14 AM
Thanks again tst for your help and helpful notes.
"To fire a value change event, you can't use a local variable. You need to use the Value(signaling) property", That's what I was missing.
And I also like your way to fire a case structure only when transition from False to True (sensing positive edge only), The thing that I like is using the "not equal" .. I used to use And and Not the signal to sense this, the two methods are equivalent .. But your method is more readable by eyes.
Thanks again
Message Edited by Ayman_Metwally on 01-25-2006 05:16 AM
01-25-2006 05:46 AM
I actually prefer to use the attached library. This is a modified version of a popular change detector (it's included in OpenG, which you should get if you don't have) which also returns the previous value.