There are some dangers to beware of when using the Interrupt palette.
P.S. Since this is for use with a mechanical switch, it can be done, but you'll get pretty erratic results until you learn how to debounce a switch.
What will happen is you'll get multiple interrupts all within a fraction of a second, as the switch makes and breaks contact several times before settling down to a firm contact. In the example attached, throwing a delay into "React" will effectively debounce the switch, but releasing the switch will probably cause the action all over again.
Mechanical switches also operate slowly enough for polling to be a possibly more effective alternative.
Quote:
|
Originally Posted by LV Help
...the robot program might hang if no interrupts occur when you shut down the robot. Instead, specify a finite time for the CompactRIO device to wait for an interrupt. When the CompactRIO device times out, check if the robot is shutting down. If the robot is not shutting down, return to the Wait VI.
|
This issue is probably moot in normal operation, because your robot program is typically shutdown by powering off the robot. Let's see an interrupt handler survive that!
on the other hand...
Quote:
|
Originally Posted by LV Help
Specifying a finite time to wait for an interrupt can introduce jitter into the interrupt handling process. The CompactRIO device might be handling a timeout at the same time an actual interrupt occurs. Therefore, the CompactRIO device takes longer to recognize and handle the interrupt. The smaller the Timeout (ms), the greater the likelihood of introducing jitter.
|
There appears to be a limit of 8 of these interrupts available for use by us.
I've attached a variation of Greg's interrupt example that puts it in terms of the 2010 framework.
You can use an Analog Trigger instead of a Digital Input if you'd rather.