This topic includes:
Interoperability options include various settings to decrease errors, problems, issues, or obstacles you may encounter when working with your interfaces, RDM devices, and MADRIX RADAR. In practice, standards and communication protocols can be interpreted in different ways or be implemented only partially or incorrectly into interfaces and RDM devices. In order to increase interoperability between such hardware and MADRIX RADAR software and to increase the chances for successful communication with them, you can try the options provided here.
▪Go to the menu Preferences > Options... > Interoperability
[Keyboard shortcut: Ctrl + Alt + O > Interoperability]
▪Set up the options as explained below.
▪Restore the default settings via Defaults.
▪Confirm any changes with OK or Apply. Discard any changes via Cancel.
The settings below may facilitate the interoperability of MADRIX RADAR with third-party interfaces and devices which deviate from official standards. Please note that these settings are not intended for regular use! After all, if temporary usage is really necessary, please also contact the third-party manufacturer for troubleshooting. This may include firmware updates and revisions, or further support.
▪Process incoming ArtPollReply packets regardless of the reported RDM capability - The software still sends an ArtTodRequest to RDM devices, even if ArtPollReply:Status:Flag2 or ArtPollReply:OutputStatus:Flag8 are not set by the devices. Should the software then receive a response to the ArtTodRequest, the RDM communication can be started.
▪Force RDM discovery by sending ArtTodControl.AtcFlush to the interfaces - If enabled, an ArtTodControl (AtcFlush) packet is being sent to the node to manually force discovery of connected devices. Please not that this increases RDM discovery times, as nodes with an active discovery background process are also instructed to drop their Table of Devices (ToD) an redo the RDM discovery.
▪Process incoming RDM packets with incorrect checksums - The software does not discard packets it receives from devices, which include an incorrect checksum.
▪Process incoming RDM packets regardless of the transaction number - The software does not discard packets it receives from devices, which include an incorrect transaction number. Normally, a reply should include the same transaction number as the request sent out by the software; but running into timeouts may cause a reply to be received after a repeated request, which then already included a new transaction number.
▪Process incoming RDM packets regardless of the destination unique ID - The software does not discard packets it receives from devices, whose Dst-Uid [destination identification number] are not set to the corresponding Src-Uid [source identification number] of the packets previously sent by the software.
▪Pad RDM packets with null characters up to the maximum packet size - The software fills packets it sends with 0x00, since some devices might expect maximum-sized packets for a successful communication.
▪Pad RDM text fields with null characters up to the maximum string length - The software fills DeviceLabel packets it sends with 0x00, since some devices might not clear the memory/label before writing it anew.
▪All Generators options will be saved locally on your computer.