Use Case

Modbus is a common protocol used in solar and substation data sources. Matching register numbers to bazefield driver source, and IO Data Types to source modbus tag lists can be tricky. 0 based register numbering, combo based register type and register value, endianness, etc. This quick start walks through entry to troubleshooting data values with a free command line software modpoll.


Read up on the modbus protocol on the following sources. 


Access to the server polling the modbus slave.


Step 1: Open Command Prompt - Find Modpoll.exe

Modpoll is typically copied to all buffers for quick access. Typically located as shown in screenshot below, in the bazetemp folder.

Open command prompt and change directory to the location of modpoll.exe.

Step 2: Identify parameter options

Shown below is running the '-h' on the executable, which shows you all the options. Highlighted are the default connection parameters independent of the type of registers you are looking at. The ip address of the slave (we are the master in this scenario) is placed at the end of the parameter string.

Step 3: Test connectivity

For this walk through, we know we are trying to connect to a slave on, slave address 1 on port 502. We have a tag that is supposed to be a solar tracker set point, which should be in degrees somewhere between 0 - 180 but most likely somewhere between 10 - 35. This information will lead us to using a 'modpoll' command, as port 502 and slave address 1 are default values for those parameters. If the slave address is different, you'll have to add that parameter before the ip. 

Shown below, the first attempt at connecting to this tracker is rejected. This 'Can't reach server/slave! ... ' error is referencing a rejection on the port attempted to establish a TCP connection. Note, this can be because of a firewall problem, wrong slave source connection details or a general network/data source power or cabling issue. However, many smaller or older modbus slaves can only respond to a single modbus master (the data client). We want to ensure that no other masters are polling this slave (this was the case, as we had a master polling this tracker already collecting data in an erroneous data type providing erroneous data).

After stopping the other master (client), we are able to successfully establish a TCP connection to the slave and poll the default parameters, shown here as the first 16 bit holding regist

Step 4: Test registers & data types to find configuration

Once connectivity is established, you want to move towards testing the data types. In this case, we were told that the set point for tracker 1 should be on 401010 and the position should be 401012. Also they should be "float" data types. The 4 in the front of these registers identifies that it is a 'holding register'.

For this we'll have to start using the parameters '-r' for the register we want to start with, and the '-c' which references the number of registers we want to return. Shown below a 1010 start and a 4 register count, '-r 1010 -c 4'

Looks like we're getting some values on these registers, so lets test out some data types. Since we're told it should be a float, so lets try that out. Adding '-t 4:float' to the parameters list. This changes the output to float polls, combining two 16 bit registers to a 32 bit float register.

It looks like this data type isn't giving us the appropriate value. Here it seems like we may be 1 register off or we maybe be dealing with an endian switch. Let's test shifting the registers by one.

Now this is promising, we have relevant values that seem to be what we're expecting. 

Product Environment and Version

Generic - non-environment version specific