Online Help
Online Help
Problems? Rescue pages start here.
Frequently Asked Questions
Tutorial Links
and demo webs
Configuration Tool
Cross Reference
Links to Other Tools





Babel Buster 9-1-1

My Babel Buster isn't talking, Now what?

There are three parties involved in this problem: The LonWorks device, the Modbus device, and the Babel Buster in between. Any one of them is a potential culprit.

To verify the LonWorks connection, start by checking whether you can "Wink" the Babel Buster from the LonWorks network. If you're not reaching the Babel Buster from the LonWorks side, fix this problem first. The most fundamental diagnostic tool in this case is the LonWorks network interface itself and the utilities for it, which you find in your PC's control panel.

If you are not certain whether the Modbus device is talking, consider working on that problem next. This can be a little trickier since you do need some Modbus diagnostic tools. Some of the tools we use are listed on the Tools/links page.

You can use Babel Buster as a diagnostic tool to poll Modbus registers. Enable only a single register (single sensor or actuator object) so that you know the LED indications apply to the particular register you are looking at. (The LEDs apply collectively to all register mappings in the Babel Buster, so flashing LEDs will not tell you much until you single out which one they apply to.) Through a process of trial and error, you can see if/when Modbus is responding and at what register number.

Line polarity is a common problem made greater by devices that do not agree on which pin is labeled A or B, whether A is positive or negative, etc. Manufacturers have not helped the matter with driver chips that consistently identify A and B backwards relative to EIA-485 specification. Since no damage is done by connecting A and B backwards, if you are uncertain of line polarity, simply swap them and try again. More about polarity may be found in the RS-485 Line Bias Tech Note.

Line bias may be an issue on RS-485 networks. It may be necessary to hold the line in a known state between transmissions to prevent false starts. Refer to the RS-485 Line Bias Tech Note for details if you suspect this problem.

Finally, the LEDs on the front of Babel Buster tell you a few things. Also, if you look at the object status for individual registers/network variables, you will see more about what the LEDs are telling you. For more information about status and what the LEDs are telling you, review the online help that comes with the configuration tool software. Click here to see the LED indication page. Click here to see the full help page set. (These open new windows.) 

Check your LonWorks Network Interface

The first step in using the configuration tool is connecting to the network interface. If you do not see any interfaces listed, you need to visit your PC's control panel. If you see an interface listed, but you get any of the indications illustrated above, you also need to visit your PC's control panel. If at any time you see a response message consisting of all CC's, you do not have, or have lost, a network connection.

Click here to visit the network interface help page.

1-2-3 Guide to Configuring the Babel Buster for Modbus to LonWorks
Use this area of the configuration tool to check status of an object once configured. This provides useful diagnostics. Select RQ_UPDATE_STATUS and click Object Request.

What do these check boxes tell you after clicking the Object Request button?

Along with these indications, the LEDs on the front of the Babel Buster provide additional clues. Click here for a summary of LED indications.

OBJECT STATUS

The check boxes in a column to the left of the object number will become active upon clicking Object Request or Node Request, and will show the resulting status information. These check boxes are selected bits from the Object Status network variable output of the device.

Obj Disabled: The disable bit says this functional object is disabled. Issue RQ_ENABLE to enable it. It will remain disabled if there is a problem with the configuration (see Register Invalid box).

No Connection: For RTU, means maximum receive time expired, no poll from master (applies only when operating as a slave). For TCP, means socket connection could not be made.

No Response: Timeout, no response from slave (applies only when operating as a master). You might try setting the timeout value higher on the RTU version. On the TCP version, this means the TCP stack timed out. This timeout is fixed but rather long. You will usually get a TCP socket connection fault before a timeout on TCP.

Comm Fault: Can indicate that an invalid request was issued to Babel Buster. This should not happen with the configuration tool, but could happen using other tools that do not do bounds checking on configuration properties. For TCP, it can also mean the two processors inside the Babel Buster are not communicating. This is normal during power-up initialization, but it should not remain in this state.

Register Invalid: The Modbus register number is out of bounds. The configuration tool will try to catch this before it is allowed to happen, but it is still possible to create an invalid combination of selections. For example, selecting Unsigned but providing a register number that falls into the Coil data block will result in "invalid".

Exception: A most common error when testing unfamiliar Modbus devices, this means the Modbus device got your request, but didn't like it. A common problem is that the register number you are trying to access does not exist in the Modbus device. It may be a legal register number and therefore allowed by the configuration tool, but the Modbus device does not recognize such a register. A well behaved Modbus device will give you an exception error rather than return null data if the register does not exist, but some devices will just return null data (which can be very misleading when trouble shooting).

In Override: This bit says the functional object is in the override state. You can put it in override by issuing the RQ_OVERRIDE request, and return to normal by issuing RQ_NORMAL (or remove override with RQ_RMV_OVERRIDE).