Triggers are the core unit of user-definable logic in the Tulip system. Triggers wait for events to fire then they check various values and compare them inside clauses to determine whether to perform actions. This document describes triggers as they relate to Apps; Refer to Machine Triggers for triggers as they relate to machines.
Name | Description |
---|---|
Event | The event that triggers the execution of logic (i.e. 'When' in the App Editor). See below for possible events. |
Clauses | The conditions that control the execution of logic (i.e. 'If', 'If/Else', 'Then'). See below for more details. |
Values | Existing data inside the Tulip system such as 'Part Count' or 'Order Number'. See below for possible value types. |
Actions | What the trigger does. Many actions are possible in the Tulip system. See below for possible actions. |
An event can be triggered from multiple sources. Possible sources and examples below:
Trigger Event | Description |
---|---|
On Step Enter | A new step has been displayed to the user |
Timers | Repeated at some interval, e.g. every 30 seconds |
Machines and Devices | A signal has been received from a device or machine |
On Step Exit | The user is navigating away from a step |
App Started | Run once when the App starts before other logic |
App Completed | Run each time the App is completed |
App Cancelled | Run if the App is cancelled |
Button is Pressed | A user has pressed a button object in the App |
A Row is Selected | A user has selected a row in a table widget in the App |
Clauses allow users to define a series of boolean logic expressions (if/then statements) that must all evaluate to true before a given action is performed in response to a trigger event. A user can define a series of comparisons and then decide to execute a number of actions if one of the statements evaluates to true of if all of the statements evaluate to true.
Values can be any data-store that is maintained in the context of an App execution. Values can come from a number of sources, including:
There are two categories of actions that triggers can cause: transition actions and regular actions. Transitions are changes to the flow state of the App. Transitions can occur by changing the current step, canceling the current App (resetting completion data) or completing the App. In a trigger there can only be one transition per action section. Once a transition has been executed by the App, any triggers for that same event will not fire. For example, if a user defines two separate triggers for a barcode scan and they both contain a transition, only the first to execute will be run.
DEPRECATION NOTICE: A deprecation notice will be shown as of LTS11 for apps that use the previous transition runtime for triggers. This only applies to apps that were created before 2022 and have not yet been migrated with the provided tool. Apps with this message should be updated immediately. Apps that have not been migrated will no longer run in the Tulip Player as of LTS12. After LTS13 (fall 2024) it will no longer be possible to migrate the apps and they will be automatically archived. Refer to the Tulip Knowledge Base for more details: https://support.tulip.co/docs/a-guide-to-app-transitions .
Data Manipulation
Logout Current User - Logout the current user and cancel the current App execution.
When more than one trigger exists on an app, step or widget in the same group (e.g. On Step Enter, Timers) a configuration option will be available per group. This allows the user to decide how triggers will behave when an error occurs (e.g. a connector does not return the expected data). In this configuration, a group of triggers can be defined to 'Stop remaining triggers on error':
ID | Name |
---|---|
QA-T57 | Variable Widget : 02 - Record View: Compound variables can be used with triggers |
QA-T62 | Variable widget : 07 - Testing variables and compound variables in app |
QA-T98 | Record Placeholders : 04 - Load Table Records Trigger, and Table Record Widget |
QA-T99 | Record Placeholders : 05 - Create and Load Table Record Trigger |
QA-T100 | Record Placeholders : 06 - Table Data Tab |
QA-T116 | Machine Monitoring : 06 - Machine Outputs |
QA-T148 | SQL Connectors : 02 - Add Function to SQL Connector |
QA-T183 | Triggers - Print Using System Dialog Trigger |
QA-T235 | User Table : 01 - User Table |
QA-T240 | HTTP Connectors : 02 - Add several functions to HTTP Connector |
QA-T258 | Machine Monitoring : 08 - App Triggers For Machines |
QA-T305 | Configuration and Apps : 05A - Apps can use Vision Cameras and Regions |
QA-T352 | Triggers - Basic Triggers App |
QA-T399 | Table Links : 03 - Linking Records via App Triggers |
QA-T404 | Configuration and Apps : 12 - Test Jig Enter/Exit region and Appear/Disappear events |
QA-T469 | Schedules and Shifts : 02 - Applying shifts in apps |
QA-T497 | Expression Editor : 01 - Create an expression in an app trigger |
QA-T501 | Copying Triggers : 01 - Copying and pasting triggers between buttons |
QA-T502 | Copying Triggers : 02 - Copying and pasting triggers between image widgets |
QA-T504 | Copying Triggers : 03 - Copying and pasting triggers between Interactive Tables |
QA-T505 | Copying Triggers : 04 - Copying and pasting Step Triggers |
QA-T506 | Copying Triggers : 05 - Copying and pasting App Triggers between apps |
QA-T515 | Base Layout - Widget triggers |
QA-T516 | Base Layout - Step and App Triggers |
QA-T521 | Expression Editor : 02 - Running the "Expressions" app |
QA-T679 | Triggers - Sleep Trigger |
QA-T728 | HTTP Connectors : 05 - Non-2xx Responses |
QA-T814 | Table Links : 05 - Linking Records via App Triggers |
QA-T1063 | Triggers - Default value for 'Stop remaining triggers on error' toggle |
QA-T1064 | Triggers - Functionality of 'Stop remaining triggers on error' toggle |
QA-T1093 | Triggers - Open Link |
QA-T1140 | Machine Monitoring : 11 - Activity fields |
QA-T1348 | Settings - Player toast duration |
ID | Requirement |
---|---|
PLAT-8859 (121) | Ability to define procedural sequences with relevant process information that can guide an operator through task execution. |
PLAT-8916 (803) | All records shall be Accurate. there must be the ability to build accuracy checks into the design of the system or configure verification for manually entered data as necessary. |
PLAT-8948 (805) | All records shall be Consistent, ie capture and recorded in the same manner and in the correct sequence of the acitivities or action being recroded. |