Route Table
Introduction
The Route Table for the NADS miniSim provides the functionality for forwarding cell data over UDP “datagrams” to a specified location. The datagrams are sent at 60 Hz. The route table is specified by the routetable.txt file. This file must exist in the “MiniSimDir\bin” directory; if the file does not exist the miniSim will operate normally, although no data will be forwarded.
The following is an example of a route table:
The route table is broken up into 4 sections, the “var” (L01 to L07), “device” (L09 to L15), “input” (L17 to L21) and the “route” (L23 to L27). Each section must begin with the section name (e.g. see L10 for “device” section), with no other text on the line, and must end with “end” (e.g. see L15 for “device” section) on a line by itself. All lines that begin with “rem” are considered comments and are discarded when the route table is parsed. The “var” section declares variables. Variables are references to cells in the *.daq file (which stores outputs from a MiniSim drive, e.g.???), the “device” sections contains devices which are variables for output. The “route” section specifies the destination to send the data to..
Var
<name> <type> <size>
The var section declares a set of variables. Each line in the var section declares one variable. The first thing on the line is the variable name, this must be exactly the same as it appears in the .daq file or the .cec file, the next item (space or tab delimited) is the type:
'i': 32 bit integer
's': 16 bit short
'f': 32 bit floating point
'd': 64 bit floating point
'c': 8 bit character
The last element on the line is the size, this is the number of elements in the cell, in the above example SCC_Audio_Trigger is a single integer.
“FrameNum” is a special variable that does not have to be listed in the cec file, it will provide the current frame number. This is the same frame number that will appear in the daq file.
Device
<id> <type> <size> <e or n> “expression”
The device section is for declaring output variables. The first element on the device line, is the id. The id is used in the route section to reference the device. The next element is the type. This uses the same designation as the var section. The next element is the size, is the element count (currently only 1 is supported). Next specifies is the output is an expression (e) or just takes the value of a variable (n). Currently only expressions are supported so “e” must appear in this section. The last section is the expression. The expression must be in quotes. Each expression must have at least one operator. The so in the above expression the “SCC_Visual_Warning + 0 “, 0 is added to SCC_Visual_Warning as to not change its value. The value of the expression is always evaluated as a double, and then type casted to the type, so very large integers may get rounded off (double has 52 significant bits), in addition to any rounding that is done to convert the double to the output type. So in the above example:
11 c 1 e "SCC_Visual_Warning + 0"
We are taking the 16 bit SCC_Visual_Warning and outputting it as a 8 bit char
Route
<ip> <port> <packed?> <device1, device2,device3, …>
The route section specifies where to send data. The first element is the ip address, the second element is the port. The third element (0 or 1) specifies if the data is to be sent in a packed data format or using a NADS specific data protocol (not specified here). Next is a list of devices the devices are specified as above and will appear in the order as they are specified. The data will be sent as little endian. For the above example the address 191.168.0.101:1500, would be sent a datagram with a single 8 bit character data load at the rate of 60 Hz. When multiple devices are selected and packed is also specified no padding will appear between variables in the data load.
