Nvision NV9000 and HELM


Note: Helm V4 adds a UsePhysicalPorts property for the NV9000 that bypasses the database IDs, rendering this section obsolete. This also solves problems reported by some customers where backing up and restoring an NV9000 configuration could result in changed database IDs.

Unlike most routers, the NV9000 control system does not have the model of an underlying 3-D ‘matrix’ of crosspoints (sources, destinations and levels). Instead, it’s really ‘just a bunch of crosspoints’ with each source, destination and level is represented by a 32-bit ID. These IDs are assigned arbitrarily by the NV9000 database, and – while they may look ‘normal’ for a freshly configured system, assumptions about relationships based on these ID’s cannot be safely made.

For example: If a router has two virtual levels, you cannot assume that their level ID’s are 1 and 2. They might equally well be 15 and 99
Related souces may not have related IDs. Sources VTR1, VTR2, VTR3, VTR4 might have IDs 10,11, 542 and 13

However, HELM requires level numbers to be small (zero to seven), and also requires source and destination ‘numbers’ to be within the defined size of the router (If helm is controlling a 32×32 router, it expects sources and destinations to be in the range 0..31 (or 1..32)

Router Map file

Because the range of IDs is large, we must have a way of imposing a virtual ‘matrix’ on the IDs to make the router easy to use with HELM.
This is done using a Router Map File which specifies which levels, inputs and ouputs are to be made available to HELM Panels. Router Map files are text files, with a “.routermap” extension.

Here’s an example Router Map file.

[Levels]
HD=1
AES 1/2=3
AES 3/4=4

[Inputs]
HDVTR  1=1
HDVTR  2=2
HDVTR  3=3
HDVTR  4=4
HDVTR  5=5
HDVTR  6=6
HDVTR  7=7
HDVTR  8=8
BARS   =64
BLACK  =6000

[Outputs]
HDVTR  1=1
HDVTR  2=2
HDVTR  3=3
HDVTR  4=4

There are three sections (Levels, Inputs and Outputs), and within each section, a list of Name/Value pairs. Each pair has the form <MNEMONIC>=<ID>, where MNEMONIC is the name used by HELM, and ID is the Device or Level ID within the NV9000 database. Each line in a section specifies mapping for one item.
For example, the LEVELS section contains three lines, which relate to HELM levels 0, 1 and 2. (HELM numbers signals and levels from zero).

  • HELM “level 0” is the HD level, which has the Virtual Level ID of 1 in the NV9000 database.
  • HELM “level 1” is the AES 1/2 level, which has the Virtual Level ID of 3 in the NV9000 database.
  • HELM “level 2” is the AES 3/4 level, which has the Virtual Level ID of 4 in the NV9000 database.

Similar mapping is used for Inputs and Outputs – in all cases, it is the ID value that is most important, and MUST directly match the DeviceIDs currently in use in the NV9000 database.

HELM’s use of the routermap file

If you place an NV9000 component on a panel, and assign it the NAME “MyNV9K”, HELM will look for a routermap file called “MyNV9K.routermap” when the panel is run.
The file should be located in the directory:”C:\Documents and Settings\All Users\Application Data\Rascular\HELM_DESIGNER”

If HELM can’t find the routermap file, it creates a default one, based on the retrieved mnemonics and device IDs from the router. You can then edit this file (with notepad) to remove unwanted sources, destinations and levels, and to re-order them to match the HELM panel requirements.

You must deploy routermap files along with the HELM panel, and – to run your panel from the Helm “Runtime”, copy them into ”C:\Documents and Settings\All Users\Application Data\Rascular\HELM_RT”

Suggested workflow:

  • Place an NV9000 component on a blank panel, set the Inputs = 256, Outputs=256, and the correct IP address
  • Run the panel
  • A routermap file will be created – edit this to isolate and re-order the required levels, inputs and outputs.
  • Now, place normal router control components on the panel (RouterBusses, OutputSelectors) and verify that correct switching occurs.
Tagged with: , ,
Posted in Devices, HELM, Routers

Leave a Reply