Does LabVIEW support hardware interrupt?

[FightOnSCTrojan]

LabVIEW Gurus:

I have built a hardware interlock box that is connected the parallel port. The interlock box will send a “high” to one of the bits in the parallel port when there is a need to run a emergency stop (a case in the main case structure) in the LabVIEW program currently running. Since the LabVIEW program is used to control 2 laser devices, it's imperative that the program stops the laser ASAP. Co-workers have suggested me to write an interrupt routine to handle the event, as opposed of my current polling (while loop) method. So far I have no luck.

So I guess my questions are:

-Does LabVIEW itself support interrupt events?
-If we call DLLs from other programs (C++, VB...etc) known to support interr
upts, wouldn't we run into the same problem (The interrupt will be detected and notified to LabVIEW, which in turn will detect the occurrence from a while loop)?
-Is there anyway to set execution priority within the same LabVIEW vi? (Say I want to detect this particular bit in the parallel port, and when that happens, I want to give priority of the CPU to executing the case of Emergency Stop routines of the lasers).

I will immensely appreciate any comments or tips that you can provide me!

Santiago

[waldemar.hersacher]

From the context of your text I see you use Windows as operating system.

If you use interrupt what type of interrupt do you mean? If you mean hardware interrupt from the parallel port you have to write your own kernel mode driver to get it and a DLL which waits for the event. There are some toolkits which will do this for you. One of my customers uses that from Kithara. This toolkit consists of a kernel mode driver and a DLL. You will call a function in that DLL which waits for the interrupt. If the interrupt occurs the function ends and you can stop your lasers.
With some Win API programming you can raise the priority of your LabVIEW thread to high priority which will not interrupt it from other user mode applications but kernel mode drivers will alway
s have a higher priority than user mode applications. Moving your mouse, network traffic and other kernel activities will cause an undefined delay in the reaction. This is by design of windows because windows is not designed for real time processing.
If you have control what is running on the machine when your application is used this should not be really a problem for you.
Waldemar

[Randy_H]

Santiago,

You could write a DLL that handles interrupts. You could also link this DL to LabVIEW by using Occurrences inside of the DLL. In LabVIEW, you would have a VI that does an infinite wait for an occurrence to fire. You can then fire this from inside of your DLL once the interrupt goes off. See the following as a starting point:
http://zone.ni.com/devzone/taskdoc.nsf/2d17d611efb58b22862567a9006ffe76/c6bcca5d09c7e9a886256802007b903f?OpenDocument

Randy Hoskin
Applications Engineer
National Instruments
http://www.ni.com/ask

[Rachana]

Hi! Santiago,

I am having a similar problem of using interrupts to handle the data from the hardware. Were you able to create and dll and make the application interrupt driven using LabVIEW?
If so, could you please tell me how?

In my application, the hardware used may generate an interrupt when there is a error condition. Say for example, the voltages are out of tolerance.I am using serial port where the serial communication or GUI action may occur in parallel to any interrupt generated.I then have to monitor the interrupt and as per perform the required action(could be exit application).

Hope I have made myself clear,
Thanks,
have a nice day,
Rachana

[KileenC]

Hi Rachana,

LabVIEW does support hardware interrupt monitoring. LabVIEW provides VIs called InPort.vi and OutPort.vi. These can be found on the Functions»Advanced»Port I/O palette. Basically, you provide these VIs with a port address and they will either read from or write to that address. If you want to write to the parrallel port, you would send a character to hex address 378.
There are many books that describe the addresses used for interrupts, masks to disable or enable interrupts, and which memory locations are used by which processors. This information can be found in most Assembly language books for the Intel processor (or whatever processor you are using).
As an example, you can turn off certain interrupts by writing to a certain address. For some time critical applications, it is helpful to turn off mouse interrupts. These are the steps for the 8259 Processor:

1. Use the InPort VI to read the current status byte of the Master IRQ Mask Register at address Hex 21. It is essential that you do this since you do not want to affect other IRQs.
2. Set bit 4 to HIGH.
3. Use the OutPort.VI to write that new value to address Hex 21.
4. Make sure you set bit 4 back to LOW to allow the mouse interrupts when you need them.

Note: This assumes your mouse is a serial mouse, and it is on COM1 (IRQ4). If your mouse is on COM2, then change the bit to the value for IRQ3. If your mouse is a bus mouse, find out what interrupt level is being used. If the IRQ is 8 thru 15, the IRQ Mask Register is at a different address, Hex A1. (IRQ8-15 is on a different 8259.)

As long as you have determined which hex address affects which interrupt, you can read from and write to that address using the aforementioned VIs.

Hope this helps. Best of luck.

Kileen

[michael bsc]

we push buttone on some device and we have some dll than gives one the problem we alwayes ask if it is one and then some program starts the other way can we implements some interrupt?

[AnalogKid2DigitalMan]

Why are you relying on software to poll an ESTOP to shut down the lasers?

This is not ideal, you may want to think through some of the ramifications.

I work with moderate power Class IV IR CO2 and UV Excimer lasers that are used in systems controlled by LabView. The automation stations are purposely designed with the ESTOP wired to a contactor that directly disconnects the 220VAC mains to the lasers whenever it is activated (also disables all motion controller hardware too). An auxilary contact on the contactor is wired to a digitial input on a DAQ card to allow LabView to sense that the ESTOP button has been activated and displays appropriate messages and commences other cleanup operations.

What if software or the OS were to lock up and the user were relying on the ESTOP to shut down the lasers in an emergency situation? Is the parallel port hardware wired to register an ESTOP condition if it is not connected to the PC? THINK ABOUT LIABILITY AND PERSONAL INJURY. At a minimum, wire a second contact set on the ESTOP to disable the laser power supply directly if that is an option. But optimally, drop the AC mains directly with the ESTOP button!!!

First hand experience is worth 10E6 wires of LV code.

[DFGray]

I want to second AnalogKid2DigitalMan's suggestion. I am currently an NI employee writing LabVIEW based software, but my previous experience as an industrial physicist include years as a laser safety officer. I worked with lasers from milliwatt diode and HeNe lasers to 200W industrial CO2 and Nd:YAG systems. All had one thing in common. The ESTOP did not rely on any sort of software for operation. This is because software, especially software on a Windows machine, is inherently more unreliable than a hardware disconnect. There may also be legal requirements, depending upon the laser power. Check with your laser safety officer.

Do yourself and your coworkers a favor. Create an all-hardware ESTOP for your system. It usually isn't very hard.

Damien Gray, PhD
Senior Software Engineer
National Instruments