VLINX MESR911 ModBus TCP to Modbus Serial Converter to Badger M-5000

[usapatriotforlife]

I'm using Advanced HMI's ModbusTCP driver (v341) to connect to a VLINK MESR911 Module which in turn is connected RS-232 to a Badger M-5000 flow meter.  (The purpose of the MESR911 is to convert Modbus TCP to Modbus Serial.)

Software supplied by Badger running on my laptop is able to read the M-5000 when connected directly to the M-5000 with the serial cable.

However, depending on what address I attempt to read, I get "Illegal Modbus Function" or "Invalid Modbus Address" errors when using the AdvancedHMI ModbusTCP driver connected to the MESR911.

I want to read the following Modbus address: 30541.  When I do, I get Invalid Modbus Address displayed in the advancedhmi control.  As I mentioned, attempted reads of other addresses will return Illegal Modbus Function or Invalid Modbus Address. 

I have found through experimentation that I can read modbus address "40001" successfully.  Well, at least AdvancedHMI controls display a "2" when I read that address instead of an error. 

I've done lots and lots of trouble shooting.  The config for the MESR911 is very simple and I've been through it all making changes just to see what would happen.  Any deviation from what I think should be the proper config yields COMM ERRORS or similar AdvancedHMI type responses.  I've changed the Modbus UnitID in the M-5000 and have witnessed AdvancedHMI complain about that.  Changing the unitid value in the ModbusTCP driver to match the meter setting corrects the problem.  So I feel that I'm getting through to the Meter using AdvancedHMI.

The address 40001 that I believe that I'm able to read is a UINT 16.  The value that I want to read is a FLOAT32 at address 30541.  However, other UINT 16 address fail to read as well.  I don't know if being able to read 40001 is significant and if I'm having an offset issue, though I can't read any 30001 or 10001 or 00001 addresses.

I noticed that the AdvancedHMI modbusTCP driver is described as Alpha software at this time.  I'm wondering if the driver is causing the problem or if it's something that I'm missing or doing wrong.

Any help and advice would be appreciated. 

[Archie]

Currently the Modbus driver doesn't support floating point. Modbus works by function code, so AdvancedHMI could be using a function code that is not supported by your device. Below is the code that parses the addresses and converts it to function code. It's based on the first digit of the address and only 0,1,3, and 4 are supported.

The easiest troubleshooting route may be to use wireshark to look at the packets and see what function codes are working.

Code: [Select]

                    Select Case CInt(AddressFirstDigit)
                        Case 0 : m_ReadFunctionCode = 1
                            WriteSingleFunctionCode = 5
                            WriteMultiFunctionCode = 15
                            m_BitsPerElement = 1
                        Case 1 : m_ReadFunctionCode = 2
                            WriteMultiFunctionCode = 0 '* Invalid
                            m_BitsPerElement = 1
                        Case 3 : m_ReadFunctionCode = 4
                            WriteMultiFunctionCode = 0
                            m_Element = CInt(Address.Substring(1)) - 1
                            m_BitsPerElement = 16
                        Case 4 : m_ReadFunctionCode = 3
                            WriteSingleFunctionCode = 6
                            WriteMultiFunctionCode = 16
                            m_Element = CInt(Address.Substring(1)) - 1
                            m_BitsPerElement = 16


[usapatriotforlife]

Thank you so much for your answer.  As far as I can tell, the ONLY thing that works is "40001", but I work with wireshark all the time and will definitely do as you advise to see what happens. 

Would you help clarify with would be contained in Address.Substring(1)?  Say for example values "30541" and "40001" placed in to PLCADDRESSVALUE?

[Archie]

In the Modbus protocol, the offset is 0 based, but in the addressing it is 1 based. For example, 40001 will convert to a function code 3 and offset 0

"40001".substring(1)="0001"
 Convert to integer then subtract 1 and you get the element of 0

[usapatriotforlife]

Thank you!  That's what I suspected by looking at the code, but I wanted to be sure.