REXGEN XML configuration: how it fits together

Write an XML configuration for a REXGEN logger, check it against the schema and load it onto the logger with REXDESK or your own code.

This series documents the REXGEN XML configuration format block by block. This first guide explains how a file fits together. The seven guides after it describe each group of elements.

When to write XML instead of using REXDESK

REXDESK builds a configuration through its interface and is the quickest route for one logger. Write the XML yourself to generate configurations from a script, keep them under version control or set up a fleet with small differences between loggers. REXDESK, REXDESK Convert and REXLIBRARY all read the same format.

One schema file defines the format: ReXConfig.xsd, in the ReXlibrary repository on GitHub. The schema is the reference. Where this series and the schema disagree, the schema wins.

The structure of a file

Every file has one root element, REXGENCONFIG, in the namespace http://www.influxtechnology.com/xml/ReXgen. The namespace is an identifier, not a web page. Its children can appear in any order.

VERSION-TYPE accepts only 1.0.1. That is the label of the file format. It stays the same even though the schema file itself is revision 1.1. The conversion library ignores elements it does not know.

Inside BLOCKS, each block type sits in its own list: CANINTERFACE blocks in CANINTERFACE_LIST, CANMESSAGE blocks in CANMESSAGE_LIST and so on. Leave out a list you do not need. The lists can also appear in any order.

Blocks, UIDs and links

Every block carries a UID attribute, an unsigned short (0 to 65,535). The schema states the rule that every UID in the file must be unique. Two of the published examples give CONFIG and a CAN interface the same UID 1. Give them different numbers in your own files. Blocks also accept the optional attributes Version, X and Y. They look like layout data written by REXDESK's editor. Leave them out when you write a file by hand.

Blocks connect by naming another block's UID. A link field set to 0 means "not linked", so never give a block the UID 0.

• Interfaces are the physical ports: CANINTERFACE, LININTERFACE, SDINTERFACE (internal storage) and USBINTERFACE (live data over USB).
• Sources produce values: an input CANMESSAGE, ADC, DIGITAL_INPUT, ACCELEROMETER, GYRO, GNSSMESSAGE and INTERNAL_PARAMETER.
• Signals (CANSIGNAL) read a value from a source and pack it into a message, or decode a value out of a received message.
• Outputs send or store data: an output CANMESSAGE, SDMESSAGE (record to storage) and USBMESSAGE (stream to REXDESK).

Each link field is named after what it points at. InterfaceUID points at an interface, InputUID at a source and MessageUID at a message. InputMessageUID points at the message an output copies and TriggeringMessageUniqueID at the block whose event sends a message.

A complete valid file

This file is ADC2CAN_Only.xml from the examples repository. It reads analogue inputs 0 and 1 every 100 ms. It sends both values in one message, identifier 298 (12A hex), on CAN 0 at 500 kbit/s. It needs a model with analogue inputs: REXGEN 2, REXGEN 2 IMU GNSS, REXGEN Air or REXGEN Pro.

<REXGENCONFIG xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://www.influxtechnology.com/xml/ReXgen" xsi:schemaLocation="http://www.influxtechnology.com/xml/ReXgen ReXConfig.xsd">
<VERSION-TYPE>1.0.1</VERSION-TYPE>
<CONFIG UID="1">
<GUID>4d65b13f-05f4-4e5a-85bd-e2273a10a9d4</GUID>
<InterfaceCount>14</InterfaceCount>
<Name>ADC2CAN_Only</Name>
<TimeStampSize>4</TimeStampSize>
<TimeStampPrecision>10</TimeStampPrecision>
<SleepMode>NO_SLEEP</SleepMode>
<ConfigurationVersion>2</ConfigurationVersion>
<CANPositiveTimeout>0</CANPositiveTimeout>
<CANSilentDelay>0</CANSilentDelay>
<CANReceiveTimeout>120</CANReceiveTimeout>
<EncryptType>No_Encryption</EncryptType>
<EncryptKey/>
<LockDevice>false</LockDevice>
<EncryptDataLog>false</EncryptDataLog>
<NTPServer/>
</CONFIG>
<BLOCKS>
<CANINTERFACE_LIST>
<CANINTERFACE UID="4">
<Type>CAN</Type>
<PhysicalNumber>0</PhysicalNumber>
<CANBusSpeed>500000</CANBusSpeed>
<CANFDBusSpeed>8000000</CANFDBusSpeed>
<CANFDNonISO>false</CANFDNonISO>
<TSeg1>0</TSeg1>
<TSeg2>0</TSeg2>
<SJW>0</SJW>
<TSeg1FD>0</TSeg1FD>
<TSeg2FD>0</TSeg2FD>
<SJWFD>0</SJWFD>
<SilentMode>false</SilentMode>
<Autodetect>false</Autodetect>
<WakeUpOption>NO_WAKE_UP</WakeUpOption>
<SleepOption>NO_SLEEP</SleepOption>
<SleepNoActivityTime>0</SleepNoActivityTime>
<Prescaler>0</Prescaler>
<PrescalerFD>0</PrescalerFD>
<UseBitTiming>false</UseBitTiming>
<FilterCount>0</FilterCount>
</CANINTERFACE>
</CANINTERFACE_LIST>
<ADC_LIST>
<ADC UID="8">
<PhysicalNumber>0</PhysicalNumber>
<Rate>100</Rate>
<ParA>1</ParA>
<ParB>0</ParB>
</ADC>
<ADC UID="9">
<PhysicalNumber>1</PhysicalNumber>
<Rate>100</Rate>
<ParA>1</ParA>
<ParB>0</ParB>
</ADC>
</ADC_LIST>
<CANMESSAGE_LIST>
<CANMESSAGE UID="10">
<MessageIdentStart>298</MessageIdentStart>
<MessageIdentEnd>298</MessageIdentEnd>
<Direction>OutputPeriodic</Direction>
<DLC>8</DLC>
<IsExtended>false</IsExtended>
<InterfaceUID>4</InterfaceUID>
<Period>100</Period>
<TriggeringMessageUniqueID>0</TriggeringMessageUniqueID>
<DefaultHex>0000000000000000</DefaultHex>
<CANFD_Option>NORMAL_CAN</CANFD_Option>
<InputMessageUID>0</InputMessageUID>
<Name/>
<isJ1939>false</isJ1939>
<J1939Source>0</J1939Source>
<J1939Destination>0</J1939Destination>
<Downsampling>0</Downsampling>
<Delay>0</Delay>
<NextOutputMessageID>0</NextOutputMessageID>
</CANMESSAGE>
</CANMESSAGE_LIST>
<CANSIGNAL_LIST>
<CANSIGNAL UID="12">
<InputType>COMMON</InputType>
<InputUID>8</InputUID>
<MessageUID>10</MessageUID>
<StartBit>0</StartBit>
<BitCount>16</BitCount>
<Endian>INTEL</Endian>
<DefaultValue>0</DefaultValue>
<ParA>0.01</ParA>
<ParB>0</ParB>
<SignalType>SIGNED</SignalType>
<Name>ADC_0</Name>
</CANSIGNAL>
<CANSIGNAL UID="15">
<InputType>COMMON</InputType>
<InputUID>9</InputUID>
<MessageUID>10</MessageUID>
<StartBit>16</StartBit>
<BitCount>16</BitCount>
<Endian>INTEL</Endian>
<DefaultValue>0</DefaultValue>
<ParA>0.01</ParA>
<ParB>0</ParB>
<SignalType>SIGNED</SignalType>
<Name>ADC_1</Name>
</CANSIGNAL>
</CANSIGNAL_LIST>
</BLOCKS>
</REXGENCONFIG>

Follow the links. Signal 12 takes its value from analogue input 8 (InputUID) and writes it into message 10 (MessageUID). Message 10 goes out on CAN interface 4 (InterfaceUID). Give every new file its own GUID.

Validate a file against the schema

1. Download the schema. Save ReXConfig.xsd from the ReXlibrary repository next to your file. Use the copy at the repository root (revision 1.1). The copy inside RXD/RxLibDemoLinux is out of date.
2. Run a validator. Any XML Schema 1.0 validator works. With xmllint (part of libxml2, included with macOS and most Linux distributions):

   xmllint --noout --schema ReXConfig.xsd my-config.xml

3. Read the result. If xmllint reports my-config.xml validates, the structure is right. Otherwise the message names the line and the element at fault.
4. Check the links. Each UID must appear once, and every link field must name a block in the file.

Load a file onto the logger

The logger does not run XML directly. The file is first compiled to a binary configuration (RXC) and sent to the logger. The logger then records RXD log files, or RXE files when log encryption is enabled.

With REXDESK

1. Connect the logger. Plug it into the PC over USB and open REXDESK. If REXDESK is not installed, see REXDESK: install the software and the REXGEN USB driver.
2. Open the external file command. Select Config > Run > Run Config Using External File.
3. Choose the file. Browse to your XML file and select Open. REXDESK compiles it and sends it to the logger.

From the command line or your own code

• REXDESK Convert compiles and sends configurations from a script. See REXDESK: convert, configure and reflash from the command line. For the installer, see Software downloads: installers, drivers and firmware.
• REXLIBRARY compiles XML to RXC with RxLib.XmlToRxc. The REXGEN Open API sends the RXC over USB with SendConfiguration.
  • REXLIBRARY: convert RXD logs and XML configurations in your own code
  • REXGEN Open API: control a logger over USB from your own application
• Over the air, REXGEN Air and REXGEN Pro pick up a new configuration from their upload server. See REXDESK: send a new configuration over the air.

Which blocks each model supports

A file can be valid against the schema and still name hardware a model does not have. Use only the blocks and channel numbers your model supports.

Worked examples

The Rexgen_XML_Examples repository holds nine ready-made configurations, each with its XML file and a matching DBC file. Every file validates against the schema. Two guides walk through them:

• REXGEN XML examples: GNSS, IMU, analogue and RTC data onto CAN, with and without recording
• REXGEN XML examples: route CAN traffic and signals between buses

Copy from the example files, which validate. Use the element names exactly as the schema spells them.

The reference guides in this series

1. How it fits together (this guide)
2. Device settings (CONFIG)
3. Cloud upload and mobile settings
4. Recording (SD) and USB outputs
5. CAN interfaces and bit timing
6. CAN messages and signals
7. LIN interfaces and messages
8. Analogue, digital, IMU and GNSS inputs

Next: REXGEN XML reference: device settings (CONFIG).