Bridge Router (TDM) FAQ

Bridge Router (TDM) FAQ

I’m new, and my station has a Bridge Router. Can you give me an overview of how the system works?

In a Wheatstone TDM system, anything with an IP address needs to have a unique address on a common subnet. The default TDM subnet is 192.168.1.0, but you don’t have to stay with that subnet. If you do change to use another subnet, you’ll need to change the IP addressing of all your Wheatstone equipment since everything must now use an address within the new subnet. Here’s an overview of the main TDM components:   

• Tier 1— This can either be a Bridge rack with one or two CPU cards, or it may be one or two WheatNet hubs, so Tier 1 will always have either 1 or 2 IP addresses with the Tier 1 addresses set by that device’s
_NET.TXT file (for Bridge and WheatNet CPU config files, the filename is XP_NET.TXT). This file is saved on the device. In very early systems a DOS configuration program was used instead of a text file. If Tier 1 has two CPUs or two hubs, then there will be a primary and a backup address. Both must be changed to the new subnet. The network settings files are accessed via FTP to the device in question and are editable using Windows Notepad. Instructions for changing these addresses are included in the Bridge and WheatNet manuals. 

• Other Tiers—Other Tiers will have CPU addresses only if they have CPU cards in them. Any of these cards can have their IP addresses changed by the FTP process using the information found in the Bridge and
WheatNet manuals. 

• Control Surfaces—Control surfaces will have one or two CPUs each. They will also have device_NET.TXT files. The E-6 Surface CPU file will be named E6_NET.TXT. The procedure for editing these to change the IP
address is like that used on the Bridge / WheatNet CPUs, and is covered in the Bridge and WheatNet manuals, and in the specific surface manual. 

• XPoint—The XPoint program needs to know the IP addresses of the Bridge/WheatNet CPU primary addresses, and the Surface primary addresses as well. The Bridge manual explains how to change the addresses that XPoint is looking to find CPUs and Surfaces at. Additionally, the PC running XPoint must also have an address on the common TDM system subnet.  

• XY Controllers—The utility program WSNetServer is used to change XY controller IP addresses  

We had a power hit and I do not remember the X-Point password
The default administrator password in X-Point is Admin
What steps does one take to properly reset a TDM frame?

1. Take XPoint offline and save the configurations with the CPU cards removed and update network files on both WheatNet units.

2. Delete the file that stores the devices from the standby WheatNet, then power it off.

3. Delete the file that stores the devices from the Master WheatNet, then reboot.

4. After rebooting the software will start up with no cards in the configuration. Once we are online with XPoint, we will open the saved configuration with the CPU cards removed and send it. This will likely reset all the cards in the system.

5. The standby WheatNet will also start up with no cards in the configuration, so the two will have no way to detect each other. For this reason, we’ll need to power off the other WheatNet unit, then power it on, open and send the configuration to it as well. After that, we will be able to resume normal operations with both units powered on.

Can you clarify the Master vs. Standby Wheatnet. Is the Primary the top, and the Secondary, the bottom unit?

It all depends on which one is set as the master when we start since either top or bottom unit could be the master.At that point in the instructions, there is one unit powered on and one unit powered off, so “power off the other” refers to the one that is powered on. Assuming the the top unit (Wheatnet A) is master when we start the process, then “the other” is the top unit (Wheatnet A). If the bottom unit (Wheatnet B) is master when we start the process, then “the other” is the bottom unit (Wheatnet B).

Assuming the top unit (Wheatnet A) is master when we start the process…

1. With XPoint offline, save the configuration with the CPU cards removed and update network files on both WheatNet units.

2. Delete the file that stores the devices from Wheatnet B, then power it off.

3. Delete the file that stores the devices from the Wheatnet A, then reboot.

4. After reboot, the software will start up with no cards in the configuration. Once we are online with XPoint, we will open the saved configuration with the CPU cards removed, and send it to Wheanet A. This will likely reset all of the cards in the system.

5. Wheatnet B will also start up with no cards in the configuration, so the two will have no way to detect each other. For this reason, we will need to power off Wheatnet A, then power on Wheatnet B, open and send the configuration to it as well. After that, we will be able to resume normal operations with both units powered on.

Assuming the bottom unit (Wheatnet B) is master when we start the process…

1. With XPoint offline, save the configuration with the CPU cards removed and update network files on both WheatNet units.

2. Delete the file that stores the devices from Wheatnet A, then power it off.

3. Delete the file that stores the devices from the Wheatnet B, then reboot.

4. After reboot, the software will start up with no cards in the configuration. Once we are online with XPoint, we will open the saved configuration with the CPU cards removed, and send it to Wheanet B. This will likely reset all of the cards in the system.

5. Wheatnet A will also start up with no cards in the configuration, so the two will have no way to detect each other. For this reason, we will need to power off Wheatnet B, then power on Wheatnet A, open and send the configuration to it as well. After that, we will be able to resume normal operations with both units powered on.

We have a HC-2001 that has failed with LED2 lit on the card. We’re currently on our backup HC-2001 and everything is fine but wanted to know how to troubleshoot the failed card.

The Tier 1 cage normally has two HC-2001 Host CPU cards in it: slot 22 will have the Primary Host CPU and slot 20 will have the Secondary Host CPU. Under normal operations the Primary card in slot 22 is in charge, which means LED3 is lit to indicate it’s the Main CPU. The other CPU card will have LED2 lit to indicate it is now the backup CPU.

When something happens to cause a CPU failover, the Primary and Secondary CPUs may swap their Main/Backup roles. Thus, a lit LED2 on either card is not necessarily an indication the card is failing. From your description it sounds like your concern is in seeing LED2 lit on the Primary card in slot 22, which simply indicates there has been a failover and now the Secondary CPU card is serving as the Main and the Primary CPU is the Backup. Considering only the LED status, that is all we can determine without further information.

Have there been other issues that lead you to suspect problems with the Primary card? If so, what kind of issues? How often do they occur? In this condition you can force a failover to switch back to having the Primary serve as Main by pressing the failover switch on the CPU that’s currently serving as Main. The failover switch on an HC-2001 card is the switch just below the card’s handle. 

You could force this resetting by powering down the Tier 1 rack, waiting 30 seconds or so, and then power it back up. It should power up with the slot 22 card set as Main (LED3 lit) and the slot 20 card set as Backup (LED2 lit).

Note: The Main card uses an FTP process to communicate configuration changes–including the current crosspoints, to the Backup. If this process is not working properly, the two CPUs will have different configurations and a failover can cause changes to the active crosspoints and their associated audio and logic. For this reason it’s always advisable to perform a system backup prior to doing any system rebooting or forced failover by using XPoint’s File > Save… to save the current configuration.

Are there any gotchas to watch out for in general when changing the IP addresses for an entire system? Stuff like signal IDs being tied to the IP addresses of their host? In other words, will the source and destination info all remain intact, will routes stored in salvos still work, etc?
 
How do I transfer XPoint to a new PC?

If both are 64-bit PCs, you copy the contents of the Wheatstone directory in the Program Files (x86) folder from the old PC to that same folder on the new PC. If the old PC is a 32-bit but the new one is 64-bit,
then the Wheatstone folder you need to copy will be under the Program Files folder.   

Once you copy the files to the new PC, the XPoint settings file, XP.INI, will need to be edited to set the path to the default config file, which is usually defined in the second line from the top. It must specify
the correct path which is: C:Program FilesWheatstoneXPointcfgdefault — on a 32-bit PC  

C:Program Files (x86)WheatstoneXPointcfgdefault — on a 64-bit PC.    

If the config file is saved in the default location, the path will either be Program Files or Program Files (x86) and will only need to be edited when going to a 64-bit PC from a 32-bit PC. 

The XP.INI file also has a similar path issue with the HowTo.txt file (it’s in the Program Files or Program Files (x86) path). When that’s not defined properly, every time XPoint is started it complains there’s a file it can’t find.

Can X-Point run in Windows 10? If so, how do I transfer my files to the new PC?

The short answer is yes. The X-point app can be run on WinXP, Win7, or Win 10 PCs. As to transferring your config files, you’ll first need to determine whether the previous PC is a 32-bit or 64-bit OS since that
determines where the files are stored. I assume your new PC is 64-bit. If your current X-point PC is 32-bit–and it was installed using the default settings, then the folder you’ll need to copy is in this path: C:Program FilesWheatstoneXPoint. If your current X-point PC is 64-bit–and it was installed using the default settings, then the folder you’ll need to copy is in this path: C:Program Files (x86)WheatstoneXPoint. 

The key to transferring an X-point installation from one PC to another is to copy all the files from the original installation and paste them into the appropriate location on the new PC. In the case of transferring
from one PC to another using 32-bit, the procedure is simple: copy the entire Wheatstone folder from the original PC to the new PC, landing it in the same location that it was in on the old PC. 

But, when transferring files from a 32-bit PC to a 64-bit PC, the procedure is a bit more complicated. The WheatstoneXPoint folder should be copied from the old PC location of: C:Program FilesWheatstone but it needs to be pasted into the new PC using this path: C:Program Files (x86)WheatstoneXPoint.    

If you moved from a 32-bit PC to a 64-bit PC, you have some additional things to do: 

1. In the WheatstoneXpoint folder, set the executable file (XP.exe) to Run as administrator. 

 a. Right-click on the icon for XP.exe 

 b. Select Properties from the popup context menu 

 c. Select the Compatibility tab. 

 d. Check mark the box that tells the program to Run as administrator. 

 e. Click OK 

2. Edit the XP.ini file section [Config Dir] path settingsto read as follows: (see Note 1 below) 

 a. ConfigDir=C:Program Files (x86)WheatstoneXPointcfgdefault (see Note 2 below) 

 b. HowToFile=C:Program Files (x86)WheatstoneXPointHowTo.txt   

Note 1: In most cases, Win7 and up allow you to open and edit the XP.ini file from its normal location, but then won’t allow you to save it. So, before you start editing the file, drag it, or create a copy and paste
it, to your desktop. Once you’ve edited and saved the file you can then drag it back to its proper location. If you copied it make sure the original file gets overwritten.   

Note 2: The default configuration X-point uses is typically the one shown. However, the user can specify using a different location but DO NOT change the file location specified in the XP.ini file beyond the insertion
of “ (x86)” – without the quotes – after “Program Files” unless you have a good reason to do that and an understanding of why it must be done.   

In the case of transferring from a 64-bit to a 32-bit PC, why? If you must do this, the procedure is basically the same with a couple of exceptions – you will be moving from Program Files (x86) to Program Files,
and thus will be removing “ (x86)” from the paths. You will most likely want to create a shortcut on your desktop to easily start the program. 

If you follow these instructions carefully you should end up with a working version of XPoint that has proper read and write access to the configuration files.   

There are a few possible gotchas to watch out for: Depending upon how the PC has been setup, file extensions may not be visible. In this case you’d see two files named XP, rather than an XP.exe and an XP.ini. The
larger of these files should be tagged as an Application – that will be XP.exe. The smaller one will be XP.ini and tagged as a Settings file. 

The current (old PC) may be set up to have the configuration files in a different location than default, possibly even on a network drive – i.e., on another PC than the one X-point runs on. This should still be possible to do on the new PC, but may involve a committee decision on whether to do it or not. The new PC must have a unique static IP address on the same subnet as the Wheatstone equipment.  

We added four analog audio cards to an existing Bridge cage (2in, 2out) so we could cross-connect to the new blade system we’re installing. The two systems are inter-connected using analog audio on DB-25 connectors. The issue is we’re having trouble making some XPoint connections in the old software and it’s not restricted to the new I/Os. Any idea why this might occur?

I suspect you’re running into a tier-to-tier bandwidth limitation. The AT links between tiers have a limited bandwidth that allows only a certain number of “channels” originating in Tier X to pass audio to Tier Y (where X and Y are actual tier numbers in your system). If there is no path for the audio between the tiers, then XPoint will not make the crosspoint.   

A quick way to verify this is the case is to pick a crosspoint that you cannot currently make, determine what the source tier is and what the destination tier is for that crosspoint, and look for existing
crosspoints between the two tiers in the same direction. For example, if the crosspoint not being allowed has a source in tier 3 and a destination in tier 4, you would be looking for other crosspoints with their sources in tier 3 and destinations in tier 4, not from tier 4 back to tier 3.    

Disconnect one of the current crosspoints you find and see if you can then make the one that was being refused. If you can, that’s a sure sign you’re encountering a tier-to-tier bandwidth limitation between those two tiers in that direction. One caveat: if the crosspoint you’re trying to make is a stereo connection and the one you disconnect is a mono (or 5.1 vs stereo) that may not free up adequate bandwidth and the new crosspoint may still be disallowed, so in doing this test make sure the channel width (mono, stereo, 5.1) of the crosspoint you remove is at least as wide as the one you want to replace it with.   

It may be possible to increase the available bandwidth between a given pair of tiers, but would require someone from the factory to be able to remote in and make the adjustments, or, in lieu of that, you would need to send us your current configuration and specify the tier pairs that require increased bandwidth so we can, if possible, update the configuration to meet your new bandwidth needs.  

 
How do I configure and define a GP-4S Microphone Control Panel? I see a piece of software to do it in the manual that I am not sure that I have.

These are wired to LIO ports and require no special software. The GPC-IP user manual has some information, including schematics, on that panel, beginning on page 1-7. Here’s a link to download that manual. 

Generally, you’ll need to wire the panel to LIO ports then use the XPoint software to configure the LIO functions. The functions are configured on the LIO tabs of the microphone audio signal definitions. Information about wiring the LIO ports begins on page 2-66 of the Gibraltar Network manual and information about configuring the LIO ports begins on page 4-23.

I have a TDM Bridge system. I’m replacing some CD players, which just needed a closure on the GPIO, with NuMark CDN77USB which need to be pulled up to +5 to trigger the CD with low logic. I’m digging through the manual, but it looks like I’ll need an external +5 supply to make this work. Is that the case?

 If that CD player does not supply +5 volts then you will need an external +5V supply since the logic outputs on TDM cards are “dry-contact” which means each logic port only provides a closure between its two pins (labelled as plus and minus). For example, when output logic port 1 is activated on an LIO-2001 card, you get a dry-contact closure between pin 12 (Out +) and pin 25 (Out -) on the lower DB-25 connector.    

If you’re using logic port 1 for Start and port 2 for Stop you would need to wire the CD player remote and a +5 volt supply in this manner:   

1. Connect the 5 VDC supply’s plus wire, through a pull-up resistor R1 to LIO card pin 12 and thru pull-up resistor R2 to LIO card pin 11.   

2. Connect LIO card pin 12 to CD player START connection (TIP) and LIO card pin 11 to CD player STOP connection (SLEEVE).   

3. Connect the 5 VDC supply’s minus wire to LIO card pins 25 and 24 and to the CD player AUDIO COMMON.   

The R1 and R2 pull-up resistors should be around 1K (unless NuMark tells you differently) since the Wheatstone logic ports can sink up to
120mA.  

 
In XPoint both CPUs are listed as “FAILED”. I pulled the power for the Wheatstone system above the frame and reset the bridge router successfully. Once the system came back up the audio was heard normally. I’ve let the system run for a while to see if the CPUs failed again, but as of this writing both CPUs have a status of OK. What’s up with both CPUs failing?
Whenever a CPU failover occurs, both CPUs will indicate “failed over” in the log, but one will indicate that it’s online while the other will indicate it’s offline. Rebooting is the only way to clear those error messages. You shouldn’t be concerned about the rare instances of a CPU failover since the system is designed to do that under certain conditions. However, I would not expect loss of audio from the failover action,
but it’s not unheard of. Keep XPoint running for a while and periodically check for error messages in the logs which could indicate a CPU or system issue. If you do see errors, let us know and we can help you analyze the log entries.
 
Question about manifold and simultaneously running WSTimeSet and utilities on one PC? The manifold windows service WSPORTMANIFOLD is referred to in the document “Wheatstone XY Controller Protocol & WSXYCLib.DLL Programmers Manual” dated Nov 27, 2005. The manifold source code is in the SDK but sounds like it might be part of the simulator and not a separate installed service.

At one point, early in the development of the TDM series of products, Wheatstone was considering making a manifold program to allow port sharing, but one was never developed. For that reason, it becomes necessary, when running TDM utilities simultaneously, to use multiple PCs. I’m not aware of any manifold products available from others, so I can’t speak to the use of any such programs.   

There are essentially two ports of interest used by XPoint and utilities, and you cannot run two programs that are using a common port on the same PC at the same time.   

Port 2898 (TCP, I believe) is used by WSTimeSet and WSNetServer, so those two programs cannot run simultaneously on a single PC. Please note that you also cannot run two simultaneous instances of any of these utilities on the same PC.   

The other port of concern is the system Broadcast Port. It is configurable, but everything in a system using broadcast communications must use the same broadcast port. By default, this is set to 55555. The following programs use the broadcast port, and so none in this group can run simultaneously on a single PC: XPoint, but only in Guest Mode (a mode which was eventually dropped as the product line developed), WSNetServer, Event Scheduler, and pc_xyc. Again you cannot run two simultaneous instances of any of these utilities on the same PC.   

The only other network restriction I’m aware of in the TDM product line, other than an automation simulator which would only be used by automation vendors during the development process, is that you cannot run two or more instances of XPoint in normal mode in the system, even on separate PCs.   

Early in the development of the TDM products we considered making a manifold program to allow port sharing, but one was never developed. Thus, when running TDM utilities simultaneously, you must use multiple PCs. I’m not aware of any manifold products available from others, so I can’t speak to the use of any such programs.   

There are essentially two ports used by XPoint and utilities and you cannot run two programs that are using a common port on the same PC at the same time. Port 2898 (TCP, I believe) is used by WSTimeSet and WSNetServer, so those two programs cannot run simultaneously on a single PC. Also note that you cannot run two simultaneous instances of any of these utilities on the same PC.   

The second port is the system Broadcast Port. It’s configurable, but everything in a system using broadcast communications uses the same broadcast port. By default, this is set to port 55555. The following
programs use the broadcast port and so only one in this group can be run at a time on a single PC: XPoint, but only in Guest Mode (a mode which was eventually dropped as the product line developed), WSNetServer, Event Scheduler, and PC_XYC.   

The only other network restriction I’m aware of in the TDM product line, other than an automation simulator which would only be used by automation vendors during the development process, is that you cannot run two or more instances of XPoint in normal mode in the system, even on separate PCs.  

 
Our TDM Bridge system failed over to the secondary CPU but when it did we lost audio on the main outputs even though we could see levels on the VU meters on our E-6 board.

When anything changes in the system, including crosspoint connections, the primary CPU should be updating the backup CPU with the changes over the Ethernet network so that when the backup CPU takes over, it should be up-to-date with all the current connections. However, if there’s a problem which prevents those updates from taking place, that can lead to crosspoints not being made. Here is how you can see if that’s what’s happening:   

1. Connect to XPoint, while the primary CPU is running, and save its configuration. (File -> Save, OK) 

2. Fail over to the backup CPU. This can be forced by pressing the button below the card handle on the primary CPU. 

3. If there’s no audio on the outputs, connect to XPoint and open the configuration you previously saved and send it. (File -> Open, OK… File -> Send Cfg To Switch). If the audio is restored then need to figure out why the secondary CPU isn’t being updated. Check the network settings files on both CPUs to verify they are identical—with the exception of their names. To check the settings, you can use any FTP client like Filezilla, to login into the CPU.. Log in with the Username: knockknock and the password: whosthere   

If sending the saved configuration to the backup CPU doesn’t return the audio, then there’s another problem that will need to be investigated.   

Download and view the file XP_NET.TXT and verify that the files on the two CPUs are identical, again with the exception of the CPU names. If there’s not a problem with the network files, then there may be a problem with the network itself. We’ve seen network switches misbehave when the IP addresses are changed. This can cause problems because when there’s a CPU failover, the two CPUs swap IP addresses, so if one CPU is not communicating properly you could end up with both having the same IP address.  

 



    • Related Articles

    • Interfacing ENCO DAD to the Bridge Router

      This document explains how to interface ENCO DAD automation to a Wheatstone Bridge Router. Download here

    • Wheatstone Bridge Router Manual

      Download/View Manual here

    • USB Devices FAQ

      My Win 10 PC is only getting the left channel over USB. What's the issue? You must use Windows 10, release 1803 or later for the USB audio to work properly. At this point in the Windows 10 lifecycle, all PCs should be on a build that supports stereo ...

    • Wheatstone Sideboard FAQ

      How can I route talkback/IFB to the Sideboard headphone jack? There is no built-in functionality for interrupting the SideBoard headphone feed with a talkback or IFB signal, but one way to do this is by using a script. The SideBoard, once added to ...

    • Wheatstone TV-1000 Console Manual

      TV-1000 Manuals, Drawings, and Router Control Download here