Preamble

This topic includes:

▪Basic Concepts

▪Using MADRIX RADAR Software & Differences Between MADRIX 5 And MADRIX RADAR

Basic Concepts

MADRIX RADAR packs and organizes RDM into an easy-to-use software tool. That means that most of the functionality is based on the RDM standard and the possibilities it does and does not provide.

RDM stands for Remote Device Management, which already describes it very well. It is about changing the settings, organizing, monitoring, and working with devices from afar. Lighting fixtures can be RDM devices, but not all RDM devices are necessarily lighting fixtures. There are many more types of RDM devices.

RDM [ANSI E1.20] is built on the DMX512 standard [DMX512-A – ANSI E1.11]. It only functions on the DMX line.

In order to be able to use MADRIX RADAR and any of its features, all involved devices on the DMX line need to support RDM. If devices do not support RDM, RDM cannot be used and devices cannot be managed with RADAR. Do not expect any lighting fixture [or any other device] to automatically support RDM. It also does not mean that all DMX512 devices automatically support RDM.

It depends on each device which RDM features are supported [such as sensors, DMX start address, DMX personality, etc.]. RDM only requires a few details as the minimum that should be reported back upon receiving a request. In this way, actual RDM support could be severely limited. On the other hand, there are many features a manufacturer could implement. RADAR relies on the data and settings a device provides via RDM. It can only work with the information it receives from the device. Such data is only provided by the device upon request.

Again, RDM is built on DMX512. DMX512 itself has its own limitations. Nowadays and especially for large projects, the Art-Net standard is often used to overcome some of those major limits. That still means that RDM itself only works on the DMX line. But Art-Net makes it possible to forward it on an Ethernet-based network. RADAR uses RDM over Art-Net. This data tunnel is referenced as the ArtRdm subcategory within Art-Net.

1] MADRIX RADAR's role in the world of RDM is that it sends commands and data requests to RDM Responders via ArtRdm [Manager]. Requests are queries sent out to receive back information from RDM devices. Commands are used to remotely set parameters and settings of RDM devices.

2] The role of MADRIX STELLA, as an example of a DMX controller, is that it transmits commands and requests to RDM Responders and back [Art-Net Node / RDM Controller]. In this way, STELLA supports ArtRdm as well as DMX RDM.

3] The third major component is the RDM device itself, which acts on commands and replies to requests with data via DMX RDM [RDM Responder].

There could be additional RDM devices in this line of communication, such as DMX512 RDM splitters on the DMX line, which are called in-line devices.

All involved devices [such as software, controller, and device] need to support RDM. Otherwise, it will not work.

MADRIX RADAR does not support any other protocols, only RDM and Art-Net, and more specifically RDM over Art-Net [so-called ArtRdm].
Learn more »Technical Standards

Using MADRIX RADAR Software &
Differences Between MADRIX 5 And MADRIX RADAR

Overview

If you have used MADRIX 5 before, you will have noticed that both software applications 'feel' very differently. That is because they are. We are trying to explain some of the key differences here.

Live Control

MADRIX 5 is built for live control. Interactions with the software [such as changing a color] should be doable as quickly as possible [with minimum possible wait time, and without requiring unnecessary confirmations]. It provides the possibilities to instantly create, manipulate, and design. It was built for Lighting Control. MADRIX 5 is much more about actively initiating a desired outcome.

Device Management

In comparison, MADRIX RADAR works completely differently. It is made for Device Management. It mainly shows the current status of your devices. For example, you can manually change many settings with the help of buttons and usually a small LCD display on your lighting fixture itself, such as the DMX start address, right? Those are the settings you can possibly change with RADAR with remote access. You can perform any configuration conveniently from your computer; instead of requiring direct access to the devices themselves in the truss, in the ceiling, or on the facade. And the software always informs you how these settings are currently set. RADAR is about changing configurations, but much more about passively monitoring the current situation.

Database

The user interface of RADAR shows the current status of your devices as reported back by those RDM devices, with information that has been received [there could be inquiries and responses that were lost], with data that has been stored in the database. Working with a large amount of information in a database, sending out requests, and receiving back responses simply takes time. That is why RADAR is not designed for extremely fast interactions. All those settings that can be managed usually do not require immediate changes anyways. It is much more important to receive information, and to reliably and consistently show the devices' status in a timely manner of seconds, minutes, hours, and days; not milliseconds. It is a much more asynchronous workflow.

Using a database also means that there is no setup file to be saved or similar. RDM devices and their information are all stored in the database. And it depends on which database management system you have selected in the options, how the data is stored. For example, the default setting is SQLite In Main Memory, which means that the data is lost once you close the software. In contrast, SQLite File and PostgreSQL Server are options for permanent storage.
Learn more »Database

Visual Feedback For Edits

RADAR reports back the current status of any changes you made to an RDM device via the GUI with the help of colored labels. It is not showing live data per se, but uses yellow to indicate that the request has been sent to the RDM device. It uses green in case the device reported back that settings have been changed successfully and red if the changes could not be set or if the request timed out. That means you might need to wait shortly before your changes are applied. Also, make sure to confirm any changes by clicking away from the selection or simply use the Enter key on the keyboard.

Features Of RDM Devices

There are many types of RDM devices. Devices report back which features and settings they offer. If a device does not support identification, you will not able to highlight it with RADAR. Such visual identification is a mode that the device needs to offer as one of its settings. Highlight Device in MADRIX 5, on the other hand, is a software feature that simply sends DMX value 255 on all color channels [full-on white]. Because MADRIX 5 is about using lighting fixtures to control their color and intensity output, it is something the software can offer. RADAR cannot offer software features for RDM devices they are not offering themselves, since the manufacturer needs to have the features implemented on the devices' hardware level and firmware level.

That means that different views of RADAR [Parameters, Sensors, Status Messages, Slots, Presets] might not contain any information or data because the device does not support it.

DMX Universe

RDM does not know about the DMX universe. RDM works on the DMX line. And a single line does not know about the DMX universe either. That is why you may only set up the DMX start address on a lighting fixture, for example. Only when using more DMX lines, the concept of several lines evolved into DMX universes, which then became a setting of the DMX controller. That is why you cannot change the DMX universe within RADAR. With MADRIX nodes however, such as MADRIX STELLA, you can call up the web configuration to change it there [Interfaces view > Right Mouse Click on an interface > Open Interface Configuration Via HTTP...].

Lists

RADAR possibly needs to manage a lot of devices and therefore a lot of data. The main method to organize and present this information on the user interface is lists. You can customize how these lists look like, by changing which column is used for sorting, plus changing the order from ascending to descending or vice versa. You can also decide which columns to show or hide. And you can use the Search bar as filter to quickly find what you are looking for.

List Of Devices

The main view of RADAR is the list of Devices. In order to add your devices to the list, RADAR needs to send out a request [menu Devices > Discover Devices]. Once they show up in the list, this also means that they first had been added to the database. The user interface represents these data entries.

If you want to remove a device, you will have to do it manually. There is value in knowing when devices have not been found or do not respond anymore. When using RADAR, you surely want to know if that is the case, because this often means that something is wrong. Removing items from the list automatically would remove them without your knowledge, and this important information would be lost. But knowing about such issues is why RADAR is used in the first place.

If you have physically removed devices from your project, you can remove them from RADAR and its database as well [Devices view > Right Mouse Click on a device > Delete].

Devices

RADAR uses the connection path to distinguish between different devices [Network – Node – Universe – ID]. For example, if you have connected the same fixture to two different RDM controllers or to the same controller with two different universe assignments and let RADAR search for the RDM device in each case, the same device shows up twice in the list of Devices. If only the unique ID would be used, they would only show up once since the device's ID is already in the list. But as explained above, this would not suffice, since devices are not and should not be removed automatically [or removed and re-added in this case].

Patch And Patch Editor

The Patch Editor of MADRIX 5 and the Patch Editor of RADAR also work very differently. The Patch in the Patch Editor of MADRIX RADAR only represents the logical order of DMX addresses. It does not show the physical layout of the lighting setup, for example. This is an information which RDM devices do not and simply cannot provide. The Patch Editor in MADRIX 5, in contrast, defines how the fixtures should be arranged or it represents how fixtures are already physically arranged. Here is a tip: Make sure to select the correct universe and correct network device in the Patch Editor of RADAR first or you may be confronted with many warning messages that might only apply to the current view options, but the settings are correct nevertheless.

Log

The log itself is much more prominent compared to MADRIX 5. Messages and errors in the log might only be for your information. It could show what a device might not support, but creates an error since it may be required by the RDM standard as default information to provide. Any information provided in the log needs your careful inspection and reasoning to determine how relevant it is for you. The Events view might offer much more actionable insights.
Learn more »Events