How do I execute one last structure in case a LabView throws an error?

[Marco_f124]

Hello,

I am writing a LabVIEW-Script to operate a high intensity laser. For safety reasons, I included an "Abort"-button that shuts the laser down in an emergency.

Now I encoutered the problem that if LabVIEW throws an error dialog, I have no control over the laser while the dialog box is opened, which could be potentially dangerous.

I am aware that the best solution to this is to simply don't let any errors happen, but I can't guarantee for that.

Does anyone know how I could send an instruction to the laser to shut in case a LabVIEW-dialog is opened?

Thanks in advance,

Kind regards,

Marco

[mcduff · Accepted solution]

---

@Marco_f124 wrote:

Hello,

I am writing a LabVIEW-Script to operate a high intensity laser. For safety reasons, I included an "Abort"-button that shuts the laser down in an emergency.

Now I encoutered the problem that if LabVIEW throws an error dialog, I have no control over the laser while the dialog box is opened, which could be potentially dangerous.

I am aware that the best solution to this is to simply don't let any errors happen, but I can't guarantee for that.

Does anyone know how I could send an instruction to the laser to shut in case a LabVIEW-dialog is opened?

Thanks in advance,

Kind regards,

Marco

---

To get around this problem, you need to do the following:

1. Catch all of the errors so no automatic dialogs open, wire all of your error clusters.
2. If there is an error, do no use the standard LabVIEW dialog, it is a blocking function.
3. Write your own dialog window such that it is floating, non modal. If you do this you will have access to your Front Panel and abort button.

I have written some programs for laser and have done the following:

1. Wrote my own dialog window.
2. If there is an error in the Laser Control loop, then close laser shutter, turn off laser, etc, then open a dialog window explaining the error.
3. If monitoring an interlock switch and it triggers, disable controls to the laser. The interlock is a hardware switch and foolproof, disabling controls in the software is just to let the user know something is wrong. Software should not be used in place of hardware interlocks.

mcduff

PS The bold is key, do not use standard LabVIEW dialogs.

[jcarmody]

---

@Marco_f124 wrote:

[...] For safety reasons, I included an "Abort"-button that shuts the laser down 

Thanks in advance,

Kind regards,

Marco

---

For safety reasons, your "Abort" button should be part of your hardware, not your software.

[mcduff]

Class 4 lasers need to have a hardware "Panic Button" that will shutdown the laser if needed. Class 3b lasers do not need the hardware button.

That being said, depending on the OP's situation, there may be reasons to shutdown the laser due to a software error.

1. Software is controlling the laser power, get an error, want to close shutter. If the users are wearing goggles, following safe practices, etc, there may be no danger to them, but you may destroy something that the laser is firing at.
2. Software is triggering/firing the laser, get an error, want to close shutter. If the users are wearing goggles, following safe practices, etc, there may be no danger to them, but you may not hit the target you were intending to hit.
3. Etc.

ALL INTERLOCKS SHALL BE HARDWARE. For example software can monitor if the door to the lab if it is opened, but a hardware interlock should disable the laser, not software.

A lot this depends on the laser class.

mcduff

[cbutcher]

Hi Marco,

As others have already mentioned, safety interlock systems should be implemented using hardware, not software (i.e. if the door opens, cut the laser using hardware, not by reading the "door status" on a computer and then outputting a "turn off laser" message to the laser control system. This is of course in part to avoid exactly the situation you describe (software blocks/locks up, doesn't check door status promptly, laser remains on).

Assuming that you're trying to implement a software button for another reason (I feel like something is going wrong etc, I want to kill the laser just in case (and my worry over the situation is greater than my worry over the status of the laser following a hard shutdown)), you could probably implement an asynchronous process to handle your laser communications. This could insulate it from the remainder of your application.

Another possibility would be to implement some sort of "watchdog", which communicates with your application but runs in a separate thread, and if it doesn't receive a message/response in a timely manner, shuts down the laser. This could be fairly brutal - ensure that this is really what you want (for example, if you make the timeout too short, you might kill the laser because your antivirus started running, or whatever).

If the problem is related specifically to error dialogs, then the chosen solution (handle errors without the default dialog, ensure errors are all handled) is a more appropriate solution (because it likely requires less changing).

Maybe if you can describe the situations in which you would use this button, along with a little more about your application, it would be possible to make further suggestions?

[Marco_f124]

Hallo all,

thanks for your advice so far.

The "Abort"-Button has the function to shut the system down immediately, but in a controlled manner. It sets the pumping power to zero and shuts the shutter of the laser.

The reason is that the laser will keep operating as long as LabView doesn't explicitly tell it to turn of, or the interlock is triggered.

Because of the way the lab is set up, it would be quicker to hit the Abort-button than to reach for the interlock, and especially if other people operate my system I would like to have a simple method of stopping the programm under all circumstances.

Could you specify what you mean with "asynchronous process"? English is not my mother tongue.

Thanks again in advance,

kind regards,

Marco

[cbutcher · Accepted solution]

---

@Marco_f124 wrote:

Could you specify what you mean with "asynchronous process"?

---

An "asynchronous process" is a process that runs unrelated in time - i.e. not before or after, just not forced to be connected. You might also use "parallel process" to describe a similar idea (although parallel describes at the same time, which might or might not be the case for an asynchronous process).

---

@Marco_f124 wrote:

The "Abort"-Button has the function to shut the system down immediately, but in a controlled manner. [...]

Because of the way the lab is set up, it would be quicker to hit the Abort-button than to reach for the interlock, and ... I would like to have a simple method of stopping the programm under all circumstances.

---

The problem you might have here is that "under all circumstances" is difficult to guarantee in software. For example, if the computer crashes, hitting the abort button will do nothing...

However, the idea you're describing is clear enough.

Probably you can get close to what you want by having the laser controlled by a process that only controls the laser (i.e. an "asynchronous process"), nothing else (you could consider the use of an Actor, for example as in Actor Framework, but this isn't a requirement) and then it is less likely this process will be broken/upset by another system. Then, send a "Shutdown" message (controlling the shutter and laser pumping) when the Abort button is clicked. So long as you're aware that this might not work (for example, because the PC crashes) then it should be more or less what you're looking for.

Asynchronous processes are usually started in LabVIEW by using the Start Asynchronous Call Node and a VI reference (Actor Framework uses this within the framework, other systems may do this more visibly). A more detailed description is available here: Asynchronously Calling VIs.