Showing results for 
Search instead for 
Did you mean: 

LabVIEW Touch panel Alarm Engine (TAE)

Re: LabVIEW Touch panel Alarm Engine (TAE)

I figured out that my problem. I used the TAE 1.1.1 instead of the TAE 2.0 (, which is the latest at this time.


Ricksor, thanks for checking. You may not have experienced my symptoms if you had not uninstalled TAE 2.0 (assuming it was previously installed) before installing TAE 1.1.1.


Incidentally, I think the naming of the downloads for all of the Reference Architecture modules could be better. It is not immediately apparent from the names that the versions are 1.1.1, 2.0, etc. Nor are the posted downloads always in chronological order (like the TAE).




0 Kudos
Message 11 of 19

Re: LabVIEW Touch panel Alarm Engine (TAE) application

It seems to me that some alarms will require that the machine controller (e.g. cRIO) take notice and handle the event. For instance, if the material runs out on a hopper, the machine controller will probably need to stop the line.


The TAE takes care of advising the operator via the HMI, but how is this supposed to mesh with the machine controller? Is the machine controller code expected to duplicate the function of detecting the alarm and handling it (in which case, why not just pass the alarm up to the HMI via a tag)? Or is the HMI code supposed to detect the code via TAE and notify the machine controller (this sounds like we're defeating the Real-Time aspect of the machine controller)?



0 Kudos
Message 12 of 19

Re: LabVIEW Touch panel Alarm Engine (TAE) application

Hi Nate,


This Alarm Engine was meant to be used in an HMI to solely report events and alarms in a user interface.  What you want is an alarm/event engine that can run in an RT system (cRIO) and that reports this alarms to the machine controller.

That been said, you can use parts of the TAE to build this RT Alarm Engine. If you open the block diagram of the you will see that there is the Alarm Engine VI at the top and then there is a loop that contains the Alarm/Event logging and status.  This bottom loop is used as the consumer (on a producer/consumer architecture) from an event.  In other words, the Alarm Engine VI at the top is the event producer loop that keeps monitoring for an alarm condition and then generates an event by wrtiting an alarm to the alarm queue.  The bottom loop then reads that alarm from the alarm queue and performs an action.  In the TAE that action is to log the alarm and to display it in the UI. In your case you can replace the Alarm Log and Alarm Status VIs with the logic responsible for handling that alarm condition.  You can either write to another tag and have your controller loop handle that condition or make this bottom loop be another control loop responsible for handling alarm conditions.


Another thing to keep in mind is that the TAE was written for an old version of the Touch Panel module that back then was lacking of many features.  There are several things in the code that can be replaced to make the code more efficient and RT friendly.


What type of application are you building? 





National Instruments

Systems Engineering

0 Kudos
Message 13 of 19

Re: LabVIEW Touch panel Alarm Engine (TAE)

I just installed and already have stm_2.0 installed. When I go to open the I am missing the following vi's:
-CVT String
-CVT Double
-CVT I32
-CVT Bool
-CVT Enum



Is the latest version?

0 Kudos
Message 14 of 19

Re: LabVIEW Touch panel Alarm Engine (TAE)

Hi Steve,


TAE 2.0 is the latest version we did for the Alarm Engine.  Unfortunately the TAE is based on the first version of the CVT (version 1.0).  Although we tried to preserve the API between the two CVT versions, we did some changes like renaming some VIs and removing ENUM support.

What you can do is downgrade the CVT to version 1.0 or modify the TAE to support the new CVT.  

The GetLabel VIs can be replaced with the GetDescription VIs.

Unless you need the ENUM data type, you can delete although adding the CVT support for ENUM should be very simple on your side.



 Sorry for the inconvenience.



National Instruments

Systems Engineering.

0 Kudos
Message 15 of 19

Re: LabVIEW Touch panel Alarm Engine (TAE)

Hello Ricardo:


I've also run into this situation recently while I was trying to set up my development environment for LabView 2010.


You mentioned to Steve that if you want to use TAE 2.0 and CVT 2.0 GetLabel VIs could be replaced with GetDescription VIs and deleting the ENUM data type.  A problem arises when trying to follow this advice because the Alarm Engine ( requires modification but that can not be done by a mere mortal because it requires a password.


Any suggestions?



0 Kudos
Message 16 of 19

Re: LabVIEW Touch panel Alarm Engine (TAE)

Dear Sir,


the TAE is great, but is there a chance to use it under labview 7.1?

Sure it is better to use the latest labview version, but for customers wishes it is often necessary to downgrade

to certain versions.

I got the same problems with the amc, cvt ... libraries but with these I managed to downgrade them by myself, because there

are no password protection.


So thanks for thinking about it Smiley Wink

0 Kudos
Message 17 of 19

RE: LabVIEW Touch panel Alarm Engine (TAE)


I have a problem about install.


Installation Summary

No software will be installed or removed.


How can I Uninstall or solve it ?


thnx reply

0 Kudos
Message 18 of 19

Re: LabVIEW Touch panel Alarm Engine (TAE)


I am trying to use the TAE reference library example code to try and understand how it works, and if it may be of use to me.

I have downloaded and installed all the ref libs for the Local machine architecture, but I canot get the TAE example to run,

The first problem is when loading the project, an error pops up stating that vi's cannot be loaded and will be removed from the project. clicking 'cancel' just cancels the whole load, 'Delete' allows you to continue loading, but having to delete loads of vi's from the project, although the project does load, and all required vi's are in the user.lib folder.

I have replaced the CVT's with the newer CVT's to solve the missing vi errors.

but that still leaves an error in the, and because it is password protected, I can't debug any further.

the following error is displayed:

You have connected two terminals of different type.

These cannot be wired together because their data types (numeric, string, array, cluster, etc.) do not match. Show the Context Help window to see what data type is required.
The type of the source is string.
The type of the sink is long [32-bit integer (-2147483648 to 2147483647)].


waiting in anticipation!



0 Kudos
Message 19 of 19