When using M-BUS with Niagara, you are most probably using either a protocol converter (like M-BUS to Modbus) or a gateway (which usually converts from M-BUS 2 wires to M-BUS over TCP).
In this article I am going to focus on the example of using a gateway (such as the iSMA Controlli MG-IP) and the native MBUS TCP driver within Niagara.
Why writing the article?
We have found often clients experiencing problems especially with discovering devices. The driver from Tridium relies on an internal database to store information. The discovery process is completely separate from the ongoing communication, and sometimes you might run the discovery and find nothing on the discovery windows at the end (after agonizing minutes of waiting).
This article is at least trying to reduce such situations and give you some tips to speed up the setup process. A few "work around" to the typical issues you might encounter when using the M-BUS native driver that are not clear when using a Relay configurator for example.
Add the right driver
The driver you want to select when communicating using the iSMA MG-IP (M-bus over IP) is the following
Check the baud rate
When configuring your network (most probably with the Relay software), take note of the baud rate.
Then, make sure you select the same baud rate on the iSMA MG-IP web page configuration
We assume you have already configured the IP address to be reachable by the Jace/web supervisor
Give the network... time
When setting up the driver, make sure you give enough delay for timing out and between messages
Also on the iSMA MG-IP, provide enough delay for timing out (I went for 20 seconds as well)
Discovery process: address gaps and... time again (yes, it is separate!)
When discovering, try discovering using the Primary Address
This will allow you to constrain the range to discover. We recommend to restrict the range to consecutive meters. We had instances where just a gap of 1 or 2 meters in the range was good enough to timeout the search and return... no result!
You might also think the 3 timeouts/delays you configured a few steps above will be considered for the discovery. Wrong!
You need to set up specific times for discovering: as mentioned, this is a completely independent process from the regular communication.
Set up the "Customized timings based scan" search, reduce the "retries" to "0" (if it doesn't respond, it tends not to respond all the time, this reduces the waiting), then try increasing the 3 delays, put a few seconds on each, a starting point. You can always increase further if needed.
NOTE: the window will not show the 3 timeouts/delays. Hover with your mouse cursor to the bottom part of the pop up and stretch it down, you will see the times and shown below.
Here are my settings
Once all is setup, try discovering.
First thing, click the chevrons >> on the top right of the discovery window. Close the pop up and re-open it to refresh.
Any device "found" within the network should be coming back with the "Found Device at Address XX" in this window
You should see some devices being discovered.
If there are gaps between meter addresses, maybe reduce the range and run multiple separate discoveries or, worst case, discover each meter individually.
Assuming you have no gaps, maybe your discover was successful!
It didn't work... let's add debug information to know if a discovery has errors
You need to enable the Application Director FINEST information on your M-BUS driver to be able to identify any "Communication Timeout" that could occur while discovering devices.
This is extremely important, because any Timeout would explain an unsuccessful result on the discovery window.
A timeout could be solved by adding longer timeouts/delays, or reducing gaps in the addresses you are searching for, see ad the bottom of this chapter.
To enable the debug information, open the Station Services - Debug Service and add FINEST debug information for MbusTcpIpNetwork_none (press the "+" icon to add, as highlighted below)
Then, open the Platform - Application director, press "Clear output" to start fresh, and wait for all the information to appear once you discover the network.
Hit the "Discover" button again, so you can monitor the results in the Application Director.
Do not worry if you see "Baud300" on the application director, despite having set the baud rate at 2400. It is ok.
This is my discovery result on application director, when everything goes well and the settings make for a healthy discovery
If you do have issues discovering, in this Application Director you will probably spot one or more "Communication Timeout". This means your connection is probably ok, but you might have to tweak your search to get rid of the timeouts.
There are 2 things you can try:
- Did you have a gap in the primary address range you used for discovering? Use a smaller range with no gaps! It will help massively. Try again the discovery.
- Still no luck and having "Communication Timeouts"? Try now increasing the delays on the discovery function, go up by 10 seconds each time, try discovering again (remember to add the same time also on the timeout within the web interface of your iSMA MG-IP).
Still no luck?
The above usually helps massively when the discovery process doesn't work.
Having gone through that with no success, we would recommend re-checking the network with the Relay configurator (or any other M-bus addressing tool), possibly reducing the amount of meters connected to isolate potential problems with the network. You might have to get down to connect one meter a time if necessary to identify the configuration issue, depending on the site.
For example, a "ring" network configuration does work with the Relay converters, but IT DOES NOT work with the MG-IP as documented. So isolating the network might help realizing there might be an actual ring configuration you haven't spotted.