How do I use interrupts?

[Itamar]

Hello,
For the past few days I have been searching the web for an explanation how to use interrupts. I didn't find anything useful.
All the code bits I have seen untill now talked about a timed loop.
Is it possible to use interrupts to execute a certain VI the second a microswitch is clicked? If so, please tell me how.

Many thanks,
Itamar.

[Ether]

Originally Posted by Itamar

Is it possible to use interrupts to execute a certain VI the second a microswitch is clicked? If so, please tell me how.

You don't want the interrupt service routine to run your VI if it contains any delays or a non-trivial amount of code. You will mess up the system's latency.

You want to let the RTOS (vxworks) handle asynchronous events that require non-trivial amounts of processing.

Can you describe in more detail what you are trying to accomplish, and why it can't wait 20ms for the next teleop iteration?

[Greg McKaskle]

Is it possible to use interrupts to execute a certain VI the second a microswitch is clicked?

You probably don't really mean the same second, as in within a second, but what time do you mean?

If you open the Periodic Timing VI, there is a loop that defaults to run once every 100ms and another that defaults to run every 10ms. You can add more loops or change those to run faster, if that is what you need.

As a way to bound the problem, calculate how far the thing your are measuring will move in a millisecond. Use that to scale your timing needs.

As for actually using interrupts, I didn't see an example, but it looks like you'd bundle together the Digital info for the digital channel monitoring the switch, then loop handling the interrupts as they are returned, then cleanup at the end. Determin if this is the correct transition for your digital line, or if you want to interrupt on both open and close and update the Booleans on Open accordingly. Note that the attached image doesn't have the rest of the framework or the watchdog in place and assumes that you will incorporate this into the framework.

[Ether]

Originally Posted by Greg McKaskle

If you open the Periodic Timing VI, there is a loop that defaults to run once every 100ms and another that defaults to run every 10ms. You can add more loops or change those to run faster, if that is what you need.

... or just put it in teleop (20ms), if that is fast enough and it doesn't need to run concurrently with your other teleop code.

Is the 2011 FRC LabVIEW Framework still under development? If so, would it be possible to add support for event handlers? That way, folks who ask about interrupts could be directed to the event-handler feature of the Framework instead, where the OS could provide the proper priority and concurrency management.

[Greg McKaskle]

Since you had already mentioned the teleop timing, I didn't cover it. I listed ways to get other timing values that aren't driven by the FRC protocol and how to connect to the interrupts raised by the FPGA.

Can you give more info as to what OS event handling or Framework event handling means to you?

Do you want to use the LV event structure? Registered callbacks? Asynchronous VIs that wait for a condition?

What is the concurrency management that you refer to?

Basically, can you give more info on what you have in mind.
Greg McKaskle

[Ether]

An event handler, as I was using the phrase, is application-level code that gets executed when an external asynchronous hardware event occurs. The execution of this code is "managed" by LabVIEW/vxworks in the sense that resources are allocated to the handler based on time-sharing and priority of other tasks concurrently competing for resources.

The 2010 FRC LabVIEW Framework had explicit support for periodic tasks. These periodic tasks are time-based, not event-based. You could put code in there to poll for an external event of interest. You could even change the default 10ms task to 1ms, although that would waste CPU resources if the event you're polling for occurs much less frequently than that.

I don't know what "Asynchronous VIs that wait for a condition" are, but that sure sounds like what I have in mind when I use the phrase "event handler". Perhaps the 2011 Framework could include a shell or template for something like that, as was done for the periodic tasks, to make it more accessible.

I make a distinction between "interrupt service" code and "event handler" code. To me, "interrupt service" is what happens from the time the interrupt occurs until the code ACKs the interrupt (if required by the hardware) and re-enables global interrupts. During this period everything else is locked out: There is no concurrency management (time sharing) because there is no concurrency. I'll go out on a limb here and say that for the purposes of FRC programming, interrupts should be serviced ONLY by LabVIEW/vxworks/FPGA: There should be NO need for teams to be writing their own interrupt service code.

So when I see a poster asking "how to use interrupts" two thoughts come to mind: 1) what is this team doing that is so time-critical that it cannot properly be handled in a fast periodic task, and 2) do they really mean they want to write an interrupt service routine, or do they want to write an event handler.

[Mark McLeod]

Would the LabVIEW Event Structure fit what you're looking for? It's available on the Programming->Structures palette and would use robot-side events rather than front panel events.

[Ether]

Originally Posted by Mark McLeod

Would the LabVIEW Event Structure fit what you're looking for?

Yes and no.

This part sounds good:

When your OS detects that an event has occurred, it notifies applications so they can react by executing any code written specifically for that event.

But this part not so much:

the event structure responds to every registered event detected by the OS and executes those responses synchronously in the order the events occurred.

In LabVIEW, periodic tasks can be prioritized, and tasks with the same priority can run concurrently via time-slicing. Is there a way in LabVIEW to treat event handlers the same way?

[Itamar]

To tell you the truth, I'm a bit lost with all of your comments... After reading Ether's comment, I'm pretty sure that what I need is an event handler.
So... is there an option to use events for a microswitch?

[Ether]

Originally Posted by Itamar

To tell you the truth, I'm a bit lost with all of your comments... After reading Ether's comment, I'm pretty sure that what I need is an event handler.
So... is there an option to use events for a microswitch?

Can you tell us what function the microswitch serves? What activates the switch, and what do you want to happen when the switch is activated?

[Alan Anderson]

Originally Posted by Itamar

To tell you the truth, I'm a bit lost with all of your comments... After reading Ether's comment, I'm pretty sure that what I need is an event handler.
So... is there an option to use events for a microswitch?

For really quick response to a digital input, interrupts are likely the simplest choice, but the rest of the context is also important to finding the "right" solution. What do you intend to make happen when the switch activates?

[Joe Ross]

Originally Posted by Ether

An event handler, as I was using the phrase, is application-level code that gets executed when an external asynchronous hardware event occurs. The execution of this code is "managed" by LabVIEW/vxworks in the sense that resources are allocated to the handler based on time-sharing and priority of other tasks concurrently competing for resources.

I had assumed that the code the Greg posted worked this way and not that everything in side the while loop was running inside the ISR.

[Ether]

Originally Posted by Joe Ross

I had assumed that the code the Greg posted worked this way and not that everything in side the while loop was running inside the ISR.

Perhaps Greg could confirm?

If so, back to my original suggestion: the 2010 Framework had "placeholders" for periodic tasks. Perhaps doing the same in the 2011 Framework for event handlers would be helpful. Users asking about "interrupts" could then be directed to the Framework's support for event handlers.

[Ether]

Originally Posted by Itamar

I'm pretty sure that what I need is an event handler.
So... is there an option to use events for a microswitch?

Yes, you could use an event handler http://en.wikipedia.org/wiki/Event_handler to respond to the microswitch.

Using LabVIEW, you can set up the circuitry connected to the microswitch to generate an interrupt http://en.wikipedia.org/wiki/Interrupts when the switch closes (or opens, or both). When the interrupt occurs, the operating system immediately responds and queues up your event handler for execution.

The 2010 Framework doesn't contain any template or example code for event handlers. See Greg's and Mark's earlier posts for suggestions how to do this.

Before you do that though, if you tell us what you are trying to accomplish http://www.chiefdelphi.com/forums/sh...0&postcount=10 there might be a better way to handle it.

[Mark McLeod]

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.

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...

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.