System addresses and system variables are similar concepts - they both allow you to target and then create triggers.
System address
System addresses are special trigger targets that work independently of standard DALI address types. Unlike regular addresses that point to specific devices or groups, system addresses provide a way to send commands that aren't tied to any particular device location.
These addresses are particularly valuable when you need multiple application controllers to respond to the same trigger simultaneously. Since the trigger isn't meant for a specific device address, system addresses offer the perfect solution for broadcast-style commands where it doesn't matter if there are different group structures on the controllers.
You can create a system address in the Trigger section, when you select a trigger of type System Address. You will see the list of currently created system addresses as well as New system address, click on this to create your address
You can also create system addresses in the Assignment & Logic -> System Address view.
If you click in the empty label section, you will see a popup. Create your system address.
Once created, you can give absolute inputs, push buttons etc the target of the system address. You are free to target zones, other controllers or the local controller that the instance is on.
Once caveat with system addresses is they do not carry data - they are more like "notifications" for something to occur without logic. For something where you need to check a value, a system variable might make more sense.
System variables
System Variables
System variables are special storage locations that hold numbers your device uses to track and manage different types of information. Think of them like numbered slots that can store values such as temperature readings, power consumption levels, or equipment status codes. Pro controllers can store 148 system variables, non pro controllers can store 48.
They are also able to be triggered on (if the system variable changes). For instance, it is very common for an absolute input to have a system variable as a target for a zone. Each controller in the zone has a system variable change trigger for the system variable number which causes a sequence to run. A common sequence is one that which checks the value of the system variable moves in and out of the emergency profile for the building.
Adding a system variable
To add a system variable, go to the Assignment & Logic -> System Variable tab.
Click on an empty label and you'll get a popup for adding a variable.
You must add the system variable to all controllers you wish to act on.
You can also add the system variable when creating the trigger.
What Changed in Version 2.1
In version 2.1, we significantly expanded what these storage slots can hold. Previously, system variables could only store positive numbers from 0 to 65,535. Now they can store much larger numbers and negative numbers too, with a range from -2,147,483,648 to 2,147,483,647.
We made this upgrade because modern industrial equipment often works with very large values (like accumulated power usage over months) and negative values (like when power flows backwards or temperatures drop below zero). This is especially important when connecting to Modbus devices, which frequently send both positive and negative data.
Important Default Value Change
There's a crucial difference in how unused system variables behave between versions. In earlier versions, a never-used system variable defaulted to 65,535. In version 2.1, unused system variables now default to -1. This happens because of how computers store negative numbers - when all bits are set to 1, the system interprets this as -1.
⚠️ Action Required: Any sequence that uses system variables for counting (incrementing or decrementing) should include an action to set the initial value of the system variable to avoid unexpected behaviour.
Usage and Scope
System variables can be accessed by local or remote instances of any current instance type, though functionality and scope vary depending on the source. They're also useful for temporary storage within sequences, with actions available for testing values, incrementing, and decrementing as needed.
Live values can be seen in grid view for a system variable if you have purchased the relevant metric on your control systems.
Storage Options
When configuring system variables, you must select the appropriate storage type based on how often the variable's value changes and whether it needs to persist through system restarts. Choose from the following options:
SRAM Storage Use SRAM for system variables that change frequently, such as sensor readings like lux levels. SRAM writes data immediately with each update, ensuring the most current values are preserved during system restarts. However, SRAM has limited capacity. When SRAM fills up (you can have up to 48 SRAM backed variables), move less frequently updated variables to EEPROM storage.
EEPROM Storage Choose EEPROM when SRAM is full or for settings that rarely change, like sequence timing delays. EEPROM offers much larger storage capacity than SRAM but writes data less frequently (typically every few minutes). Important: Avoid storing frequently changing variables in EEPROM, as it has limited write cycles and excessive writing can damage the control system.
Volatile Storage (Do Not Store) This option means system variables aren't saved to the controller and will reset on reboot. Use this for temporary values like countdown timers or calculations that don't need to persist between system restarts.
Associated Target
Associated target can be used by cloud features (e.g. sequences, target lux) to look up a system variable. The associated target is NOT a DALI target for the system variable, changing the system variable value will not affect the target.
Tag
Tag is used in combination with associated target to allow multiple system variables to be looked up for each associated target.
For more information about using system variable in sequences, click here.
Comments
0 comments
Article is closed for comments.