02-10-2010 01:17 PM
I figured out that my problem. I used the TAE 1.1.1 instead of the TAE 2.0 (tae20_installer.zip), 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).
02-10-2010 05:26 PM
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)?
02-11-2010 11:14 AM
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 TAE.vi 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?
02-23-2010 02:24 PM
I just installed tae20_installer.zip and already have stm_2.0 installed. When I go to open the TAE_Example.vi I am missing the following vi's:
-CVT String GetLabel.vi
-CVT Double GetLabel.vi
-CVT I32 GetLabel.vi
-CVT Bool GetLabel.vi
-CVT Enum Read.vi
Is tae20_installer.zip the latest version?
02-24-2010 01:33 PM
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.
09-30-2010 12:28 PM
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 (tae_Process_Events.vi) requires modification but that can not be done by a mere mortal because it requires a password.
01-20-2011 02:57 AM
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
08-08-2012 11:23 AM
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 xxxxx.vi's with the newer CVT xxxxGetDescription.vi's to solve the missing vi errors.
but that still leaves an error in the tae_CheckForAlarm.vi, 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!