Troubleshooting

This topic includes:

▪Overview

▪Missing Responses From RDM Devices

Overview

Refer to the topics below to troubleshoot occurring issues.

Missing Responses From RDM Devices

Due to the underlying technologies, you may be experiencing that an RDM device could not successfully apply a setting changed by you [i.e., a new value] or that the request timed out.
This is likely due to a missing response, which means that MADRIX RADAR did not receive information back from the device or that the device did not even receive the initial request in the first place.

There are a number of reasons why a Set-Command might not reach a device or why a response may be missing:

▪Timeouts Of RDM Responders
- In the Options of MADRIX RADAR, a Transaction Timeout is defined. It defines the maximum time in seconds after which a pending response for an RDM request  is considered missing. See »Timing
- This option reflects the realities of working with RDM.
- An RDM Responder might receive too many requests, such as Set-Commands and Get-Commands, and might not be able to respond to all of them.
- In return, responses are missing.

▪UDP
- MADRIX RADAR uses RDM over Art-Net. This data tunnel is referenced as the ArtRdm subcategory within Art-Net. Art-Net is a communication protocol using Ethernet networks.
- Art-Net is using UDP, the User-Datagram Protocol. By using the simpler connectionless communication and not connection-oriented communication, UDP does not include mechanisms to monitor the state of sent packets.
- The protocol therefore does not include responses if a packet has been received by the recipient. Packets are simply sent out without maintaining a steady connection between sender and receiver as UDP was not designed for this.
- As explained above, MADRIX RADAR has implemented its own mechanisms to try to sustain the connection and assign responses to the corresponding requests. However, after a certain time responses need to be considered as lost. Otherwise, you would need to wait indefinitely for responses, which defeats the purpose of working with RDM devices productively.
- Due to the design of the protocol, responses therefore can be lost.
- One reason can be that there is too much data traffic on the network. [In this case, you can reduce traffic by temporarily switching off senders and by pausing the monitoring of MADRIX RADAR, for example.]
- Another reason can be that the used network switch does not have enough memory to successfully transmit all data packets. [More advanced professional networking gear can help meet the actual requirements of the network and its data traffic.]

▪Processing Timings Of Hardware Interfaces
- Hardware interfaces, such as MADRIX STELLA, need to process the RDM data packets.
- Thereby, certain timings are used for the communication between RDM Controllers and RDM Responders.
- Managers, such as MADRIX RADAR, in turn may use their own timings to send data to the RDM Controllers.
- A high number of data packets or aggressive timings can lead to the situation that RDM controllers cannot fully process incoming packets, since their buffer might not be large enough. Then, older packets might be discarded since new packets were already received.

Pending Generator Requests

You may find the following messages in the Log view or log files:

▪No parameter requests have been generated in the recent interval of <set generator interval> due to still pending requests! This may be caused by a temporary peak of other requests, or inappropriate generator settings.

▪No sensor value requests have been generated in the recent interval of <set generator interval> due to still pending requests! This may be caused by a temporary peak of other requests, or inappropriate generator settings.

▪No status message requests have been generated in the recent interval of <set generator interval> due to still pending requests! This may be caused by a temporary peak of other requests, or inappropriate generator settings.

This indicates a peak in queued requests referring to a temporarily fully occupied scheduler. If you are seeing such a message, work through the following steps:

1] How Often Is The Message Appearing?

▪Rarely - You may only run into this issue due to additionally triggered actions, such as Identify All Devices, or Discover Devices. In this case, probably no further action is required.

▪Often - You should check the settings under Preferences > Options... > Generators. You may need to reduce the intervals by increasing the settings.

2] Which Generator Is Mainly Affected?

▪Parameter Request Generator - Too many parameters, sensor values, and/or status messages are being requested in too small time intervals. You should check the settings under Preferences > Options... > Generators. You may need to reduce the intervals by increasing the settings of the generators.

▪Sensor-Value Request Generator - Too many sensor values and/or status messages are being requested in too small time intervals. You should check the settings under Preferences > Options... > Generators. You may need to reduce the intervals by increasing the settings of the generators.

▪Status-Message Request Generator - Too many status messages are being requested in too small time intervals. You should check the settings under Preferences > Options... > Generators. You may need to reduce the intervals by increasing the settings of the generators.

3] Was Changing The Timing Intervals Of The Generators Not Sufficient Or Cannot Be Applied?

▪Sending Frame Time (s) - Check the setting under Preferences > Options... > Timing. You may need to reduce the setting. But do not set it lower than the Frame Time of the slowest hardware interface in the installation!

▪How are lighting fixtures distributed among hardware interfaces and DMX universes? You may need to change the wiring and counterbalance the DMX lines more equally to reduce data traffic on each individual line.