Interrupts in Labview

[Clint_Eastwood1000]

I am using LV2013 to test my UUT.  The GUI is 3 buttons that select an event in the Main Program..ie Functional Test, Self Test and Calibration.  One of the safety features is that if a UUT door is opened during testing something is suppose to happen like the test gracefully shuts down.  I monitor the door sw thru a DIO on a DAQ card.  If the door is opened the signal goes HIGH and vice versa.  Is this a parallel process??? Monitoring the door switch and at the same time running say the functional test??  The functional test is a subvi in the Functional Test Event structure.  Would I put the door monitor of the DIO and the subvi in the same event ??  If the door is opened during functional I want the current code to stop where ever it is and now the code to gracefully shut down to "take over"..

Would  producer/consumer architecture work better?

Thxs..

[Bob_Schor]

Is your Main program using an Event structure in a parallel loop?  Without seeing your code (why do so many people post questions and not show code??), I can't tell, but it is not uncommon for a Main Program to have an Event Loop running in parallel with a Queued "Reader", which is a form of Producer (Event loop)/Consumer (Queued Reader) pattern.

If you have this, you can create a "Door Open" indicator.  Pass a reference to this indicator to the sub-VI that monitors the Door Open switch, and when the Switch goes High, use the Value(signalling) property of the Door Open indicator and wire True to it.  Now back in your Event loop, put the Door Open indicator inside the Door Open:Value Changed case and generate a "Shutdown" request to the main loop.

Bob Schor

[natasftw]

Interrupts are handled with the Event Structure.

Keep in mind interrupts don't stop code immediately.  They stop code at the next stopping point where they are checked.  You'll need to write your code in a way that allows for checks often enough to make it appear immediate. 

It'd help to see your code to offer advice about your code.  If you're wanting to use the Producer/Consumer, take a look at the Queue palette to see the options you have available for your Producer loop to send data to the Consumer loop.  You should be able to use these to determine how to keep your code working in a way that behaves as you wish.

[nathand]

---

Bob_Schor wrote:

If you have this, you can create a "Door Open" indicator.  Pass a reference to this indicator to the sub-VI that monitors the Door Open switch, and when the Switch goes High, use the Value(signalling) property of the Door Open indicator and wire True to it.  Now back in your Event loop, put the Door Open indicator inside the Door Open:Value Changed case and generate a "Shutdown" request to the main loop.

---

Please don't abuse "Value(signaling)" this way. If you want to trigger an event, use a User Event. It's weird to have an event on an indicator, and references to front panel items are an inefficent way to pass data between VIs, especially if there's no other need for the front panel item.

---

@Clint_Eastwood1000 wrote:

I am using LV2013 to test my UUT.  The GUI is 3 buttons that select an event in the Main Program..ie Functional Test, Self Test and Calibration.  One of the safety features is that if a UUT door is opened during testing something is suppose to happen like the test gracefully shuts down.  I monitor the door sw thru a DIO on a DAQ card.  If the door is opened the signal goes HIGH and vice versa.  Is this a parallel process??? Monitoring the door switch and at the same time running say the functional test??  The functional test is a subvi in the Functional Test Event structure.  Would I put the door monitor of the DIO and the subvi in the same event ??  If the door is opened during functional I want the current code to stop where ever it is and now the code to gracefully shut down to "take over"..

Would  producer/consumer architecture work better?

---

Generally you shouldn't be putting any logic that takes a substantial amount of time to execute inside an event structure, because that will block the event structure from handling other events. If an event triggers a long-running action, it should hand off that action to a separate loop, as in a producer-consumer architecture. In this case it sounds like your Functional Test, Self Test, and Calibration should each be a collection of states in a consumer loop, and the event structure should trigger the appropriate state. The consumer loop should constantly check for new commands even when running one of those sequences so that it can receive an abort command.

The door monitor can be a third loop, that checks the switch at regular intervals and if it detects a transition from low to high, it sends an abort command to the consumer loop.