Text only | Text with Images

LEC Forum

Communications => Modbus => Topic started by: Dave Loucks on September 12, 2014, 11:30:51 AM

Title: Modbus MINT (Modular INCOM Network Translator or mMINT)
Post by: Dave Loucks on September 12, 2014, 11:30:51 AM
The mMINT is used to connect devices that use the INCOM protocol to a Modbus RTU network via a 485 twisted pair network.
(http://pps2.com/images/smf/2014-09-12_11-01-27.png)

A more complex diagram could look like this:
(http://pps2.com/images/smf/mmint_wiring.jpg)

When using computers with USB ports connected to 485 converters, take care to identify the "inverting" from the "non-inverting" terminals on each device.  Always connected like terminals (inverting to inverting, non-inverting to non-inverting).  Do not look at letters (A or B, for example) as different vendors ascribe different meanings to those letters).
(http://pps2.com/images/smf/usb_485_mmint_wiring.png)

The Modbus MINT (mMINT) allows a Modbus master device to collect data from INCOM slave devices.  The mMINT supports two methods of collecting data.

Preset Modbus Register Map
Refer to Tables 8 and 9 in the Modbus MINT instruction manual (http://www.eaton.com/ecm/groups/public/@pub/@electrical/documents/content/66a7508.pdf). 

Some important notes:

Custom Pass-Through

If the data you desire from the downstream INCOM device is not stored within the mMINT Modbus register map, you can send what is called a "pass-through" message using the Modbus protocol that the mMINT will interpret as special instructions to fetch data from an INCOM device.  That process requires two (or more) Modbus messages and is graphically shown below.

(http://pps2.com/images/smf/2014-09-12_11-06-15.png)

Besides the instruction manual (http://www.eaton.com/ecm/groups/public/@pub/@electrical/documents/content/66a7508.pdf) that you can download from the Eaton web site, I also wrote a few other app notes that might help.

Troubleshooting:
Following the instructions in the Modbus MINT Application document attached, but some key things to watch:

No response?

Invalid Responses
Title: Re: Modbus MINT (Modular INCOM Network Translator)
Post by: Dave Loucks on September 19, 2014, 02:57:43 PM
The mMINT has a unique workaround for the problem when trying to use the Modbus RTU protocol on a network with separate "layers". 

Normally, Modbus MINT addressing is just one for one - whatever Modbus address you send down the wire will be converted to the same INCOM address.  The expectation, therefore, is that you cannot reuse INCOM addresses on the same Modbus network:
(http://pps2.com/images/smf/simple_mmint_network.jpg)




Modbus AddressINCOM Address
Main 4-1
001
001
Tie 4-1
002
002

Very straight forward!

But now consider an INCOM system that uses subnetwork masters (like the Breaker Interface Module II (BIM II)):

(http://pps2.com/images/smf/two_subnet_mmint.jpg)


You quickly see the problem.  Several of the circuit breakers have the same INCOM addresses!  For example, the Main 4-1 and the Main 3-1 breakers are both addressed 001.  However, since they are on different, isolated subnetworks, they don't interfere with each other.  So then how does a Modbus device (like the DeltaV DCS in this example) access the correct Main breaker?

The solution is to create a routing table within the mMINT.  Refer to INCOM routing address configurations found on page 6 of the mMINT - Modbus Translator Module - Instruction Leaflet IL66A7508H08 (http://www.eaton.com/ecm/groups/public/@pub/@electrical/documents/content/66a7508.pdf) for more information.

The key is to assign each Modbus address to two separate INCOM addresses.  A table of registers is set aside within the mMINT to hold this cross reference.

In the table shown immediately below, notice that Modbus address 001 is assigned two registers within the mMINT, 42101 and 42102.

The first of the two registers, 42101, holds the INCOM address of the subnet master and the second register, 42102, holds the INCOM address of the device itself.

The mMINT now knows how to route a message addressed to Modbus address 001 to the device defined by the two register pair:




Modbus
Address		  Subnet Master
Stored Here		  Device Address
Stored Here
001
 
42101
 
42102

A more complete routing table showing all the possible 246 (1-246) Modbus routing addresses is shown below:

Routing Table






Modbus
Address
INCOM Main
Network Address
INCOM Sub-
NetworkAddress
001
42101
42102
002
42103
42104
:  :
:  :
:  :
246
42591
42592

Note: in a mixed system with both directly addressed and routed INCOM addresses, just place the value 255 (or 65535) in the routing table for the Modbus addresses and the mMINT will just use the Modbus address-to-INCOM address one-to-one mapping. 

Download the attached Excel MINT_routing_template.xls spreadsheet (http://pps2.com/smf/index.php?action=dlattach;topic=29.0;attach=3) to simplify filling in the Modbus to routing register cross-reference table.  Optionally, you can use the Excel programming tool (http://pps2.com/smf/index.php/topic,29.msg39.html#msg39) to configure these registers.  The use of this tool is described in this tutorial video (http://pps2.com/v/1/mmint08.php).

We now have enough information to know what to put in those tables.  To fix the problem described above, we must enter both the circuit breaker address and the address of the subnet master (BIM II):





Modbus
Address
Points
to:
INCOM Main
Network Address
INCOM Sub-
NetworkAddress
001
Main 3-1
42101=003
42102=001
002
Main 4-1
42103=004
42104=001

So even though the INCOM addresses for both breakers are the same (001), since they are on different subnetworks, the mMINT knows where to find them by using the routing table to "route" the message through the upstream BIM II's at either INCOM address 003 or 004.

Tips to Remember
(Note: a specially programmed Excel worksheet that can talk to the mMINT and perform these routing settings is available in this article (https://pps2.com/smf/index.php/topic,29.msg39.html#msg39) further down this page.)


Here's a larger example to show how the addresses can be allocated:
(http://pps2.com/images/smf/subnetwork_connections.jpg)
(http://pps2.com/images/smf/routing_table.jpg)

ModScan (http://www.win-tech.com/html/modscan32.htm) is a common tool used to send and receive Modbus messages.  To send this routing table via ModScan, you will need to create a script (or manually enter a "user message"). 




Running a Script  Entering a Message Manually
(http://pps2.com/images/smf/run_script.png)(http://pps2.com/images/smf/run_user_msg.png)

ModScan does permit changing registers by double-clicking on the screen, but it uses Modbus function code 06, Preset Single Register, by default, which the mMINT does not support.  To use the function code 16, Preset Multiple Registers, either a script must be created or, for single register writes, you can change the default behavior of Modscan to use function code 16 instead.  Since you MUST change the routing table two registers at a time (subnet master and device address must both be changed at the same time -- never individually), you can't use the double-click method even if you change Modscan to use function code 16) since it will only change a single register.

(http://pps2.com/images/smf/use_function16.png)

Remember, this only works for editing a single 16-bit Modbus register value.  When the mMINT requires that blocks of registers be changed at once (like the subnet routing table), then use a script instead.

Modscan defines scripts on page 41 in their manual (http://www.win-tech.com/html/manual.htm) (dated 1998), but there are some tricks that are not immediately evident.  One of the most important when writing data to the mMINT is the proper ordering of the values you wish to write within the script.

For example, to write the following table of registers (mMINT Subnet Routing Table), use the Modscan script immediately after this table:

(http://pps2.com/images/smf/sample_routing_table.png)

Modscan Scripts

Modscan test scripts consist of ASCII text data field separated by commas. They may be constructed using any word processor or spreadsheet application (but make sure that word processor saves the file as a text file with no added characters.  If you aren't sure, on a Windows computer use the NotePad application.  In Excel, save your files as a comma separated variable .csv file).  A test script entry consists of at least 7 data fields as depicted in the example script, (see WriteRoutingTable2.csv attached below).

When writing data, Modscan uses a unique method of requiring that 32 bits (two 16-bit registers) be written as one message.

Recommend using NotePad or other text editor, NOT Excel as Excel may try to add quotations around the '//' character pair (which won't work when imported into Modscan).

Code Select

//
// Modbus Test Script for ModScan Application
//
// Each Script entry consists of the following comma delimited data fields:
// TEST NAME, NODE, FUNCTION, ADDRESS, LENGTH, DATA, CONTROL CODE
//
// Double slashes on the front of a line denote comments
//
// The following Control Codes may be used (i.e. last field on each line)
// \ -- Continue DATA fields on next line"
// C -- Generate Bad CRC message to slave"
// D -- Check response data quantity only", (ignore actual data)
// 1 -- Expect Exception Response 01"
// 2 -- Expect Exception Response 02"
// 4 -- Expect Exception Response 04"
// R -- Expect no Response"
// T (default) -- Verify Response Data"
//
//
//          -----------------------------------------------
//          mMINT diagnostics communications (SW2-1 ""OPEN"")"
//          -----------------------------------------------
//
// mMINT Echo Test:
//   Echo Test (Diagnostic Function 08  SubFunction 0x0000)
//   TEST NAME, NODE, FUNCTION, SUBFUNCTION, LENGTH, DATA, CONTROL CODE
E1. mMINT Echo Test,248,8,0x0000,1,0xAA55,T
//
//   Config Block (Preset Multiple Registers 0x10  Address 2100)
//   TEST NAME, NODE, FUNCTION, ADDRESS, NBR REGS,Data
1A. Config Map 0-1,248,16,2101,64,\
,0x00010001,0x00020001,0x00030001,0x00040001,0x00050001,0x00060001,0x00070001,0x00080001,\
,0x00010002,0x00020002,0x00030002,0x00040002,0x00050002,0x00060002,0x00070002,0x00080002,\
,0x00010003,0x00020003,0x00030003,0x00040003,0x00050003,0x00060003,0x00070003,0x00080003,\
,0x00010004,0x00020004,0x00030004,0x00040004,0x00050004,0x00060004,0x00070004,0x00080004,\
T
// This message will send out the following data:
//N  - Modbus node address
//fn - Modbus function code
//add- Starting register address - 1 (e.g. 42101 dec = 0835 hex subtract 1 = 0834 address)
//num- Number of registers to write
//by - Bytes sent (redundant to num, but Modbus uses as a form of error checking)
// 1 - Hi byte, Lo byte of first register value
// 2 - Hi byte, Lo byte of second register value
// : : : :
//64 - Hi byte, Lo byte of 64th register value
//
//N  fn  add   num  by   1     2     3     4     5     6     7     8     9    10       
//F8,10,08,34,00,40,80,00,01,00,01,00,01,00,02,00,01,00,03,00,01,00,04,00,01,00,05,
// 11    12    13    14    15    16    17    18    19    20    21    22    23 
//00,01,00,06,00,01,00,07,00,01,00,08,00,02,00,01,00,02,00,02,00,02,00,03,00,02,
// 24    25    26    27    28    29    30    31    32    33    34    35    36    37
//00,04,00,02,00,05,00,02,00,06,00,02,00,07,00,02,00,08,00,03,00,01,00,03,00,02,00,03,
// 38    39    40    41    42    43    44    45    46    47    48    49    50
//00,03,00,03,00,04,00,03,00,05,00,03,00,06,00,03,00,07,00,03,00,08,00,04,00,01,
//  51   52    53    54    55    56    57    58    59    60    61    62    63    64
//00,04,00,02,00,04,00,03,00,04,00,04,00,04,00,05,00,04,00,06,00,04,00,07,00,04,00,08,
//CL CH
//76,49
//
//
// END OF SCRIPT
end



To delete a value in the routing table, simply write 0xFFFF in each register.

For example, assume that we wish to remove Modbus address 001 from the routing table (a message received by the mMINT, then, will be translated directly to talk to INCOM address 001 without any routing).  We know that mMINT Modbus registers 42101 and 42012 control the subnet master and device addresses, respectively for Modbus address 001.  Assume they presently contain routing information where 42101 contains 0001 and 42102 contains 0001.  From the Modscan screen it would appear as:

(http://pps2.com/images/smf/routing_active.png)

To change these values to FFFF and FFFF, use the "User Msg" function in Modscan.

(http://pps2.com/images/smf/run_user_msg.png)

Enter the slave address of 247 or 248 (F7 or F8 hexadecimal), then the Modbus function code as 16 (10 hex). 

If you are not familiar with the Modbus structure, the next part is to build the proper Modbus data string using  structure of STARTING REGISTER ADDRESS, LENGTH, DATA.

We are intending to write data starting at register 2101 (Modbus prefaces holding registers with the number '4', but this isn't sent down the network) so this must be converted into a binary address to send down the wire.  To represent the decimal number 2101 as a binary number (for sending down the wire), we see that 2101 decimal is 1000 0011 0101 binary, or 835 hex (use a calculator online).  We are not done though -- Register numbers in Modbus always start with 1.  There is no such thing as Modbus register 0.  But in memory addressing, there is an address 0.  The authors of Modbus stipulated that to determine the actual memory address, take the register address and subtract 1.

In this example, register number 835 hex becomes memory offset 834 hex.  That second number is what we transmit down the wire.  Below, the same user defined command string is formatted -- one showing values in hexadecimal and one in decimal.  Notice that STARTING REGISTER = 08 34, LENGTH is 00 02 (first two numbers are the number of registers being sent) then 04 (the third number is the number of bytes... this is duplicate data since you've already inserted the number of registers and since each register is 16 bits [2 x 8-bit bytes long], then the number of bytes is known already as two times the length ... So why include both?  Perhaps the inventors of Modbus used this redundancy as a form of error checking?).  DATA is FF FF FF FF.  Since each digit represents 4 bits and two 16-bit registers are being sent, we need 8 total hex digits.  Each register is 16 bits or 4 hex digits (FFFF).

(http://pps2.com/images/smf/routing_disable_message.png)(http://pps2.com/images/smf/routing_disable_message_decimal.png)
Title: 2, 3 or 4-wire Modbus
Post by: Dave Loucks on October 09, 2014, 04:41:57 PM
Here's a discussion of the issues around the number of wires to use in a Modbus connection.  Note that at a minimum 3-wires are needed.

See http://pps2.com/smf/index.php/topic,30.0.html (http://pps2.com/smf/index.php/topic,30.0.html)
Title: Primary and Secondary Cause Registers (per Tables 10 and 11) in the IL
Post by: Dave Loucks on February 02, 2015, 12:12:31 PM
Here's how to read and decode these registers:

Here's how to convert that big 32-bit number into three numbers that correspond to the codes you'll see in Tables 10 (Primary Status Code Definitions), 11 (Secondary Status Code Definitions) and 12 (Cause-of-Status Code Definitions)


Example:
Read two register pair 404609-404610 -> returns 32-bit value 66055

66055/65536 = 1.004013...   -> Table 12 = 1 (Normal Operating Mode)
(http://pps2.com/images/smf/mmint/table12.png)

66055 - (1*65536) = 519

519/256 = 2.0273... -> Table 10 = 2 (Closed)
(http://pps2.com/images/smf/mmint/Table10.png)

519 - (2*256) = 7 -> Table 11 = 7 (Powered up)
(http://pps2.com/images/smf/mmint/Table11.png)
Title: Modbus MINT (Modular INCOM Network Translator or mMINT) test program
Post by: Dave Loucks on March 04, 2015, 02:20:16 PM
(https://pps2.com/images/smf/mmint/mMINT_ExcelV10.png)

I've attached an Excel 2010 (Windows) spreadsheet that, if you have Excel 2010 (or later?), it can be used to communicate with a Modbus MINT via a COM port. 

I wrote the code to send and receive Modbus messages from within Excel using Excel's scripting language, VBA, and to decode the data returned to make it easier to interpret.  No more MODSCAN needed!

Here's an 18 min screencast tutorial (https://pps2.com/v/1/mmint08.php) I created that explains how this program works.

I'm adding features over time, so check back to learn about upgrades.  I'm also including earlier (simpler) versions since if all you want is the Modbus VBA code, you won't want to weed through bigger and bigger programs to snip out a Modbus Read or Modbus Write algorithm!

Revision list (major changes)
VBA-comms9

VBA-comms10

VBA-comms11
This is a fairly extensive update to the code.  As such, all this extra code is making this program more unwieldy to follow, so this is the first version that I've switched off viewing of the underlying code.  Shouldn't be a problem if all you wanted were the Modbus read/write commands.  You can see those in the earlier versions!

Screencast tutorials on new features:

Here's the list of upgrades to this version:
Known bugs in V0.11

VBA-comms12

VBA-comms13

VBA-comms14

VBA-comms15

NOTE: for more information on decoding the PRODUCT ID register, refer to the article immediately below (https://pps2.com/smf/index.php/topic,29.msg45.html#msg45).

VBA-comms16

VBA-comms17

VBA-comms18

VBA-comms19

VBA-comms20

VBA-comms21

VBA-comms22


Where are the previous version of this program?
This forum software places limits on the number and maximum size of files that can be attached to an article.  Previous versions of the program can be downloaded from https://pps2.com/files/mm/ (https://pps2.com/files/mm/)
Title: Decoding PRODUCT ID Register (INCOM/IMPACC Fast Status 3 0 0)
Post by: Dave Loucks on August 03, 2015, 05:50:59 PM
VERY IMPORTANT
A request to read the Modbus MINT PRODUCT ID must always start at the PRODUCT ID 406255 register (underlying address 625410 or 186E16).  You can still read a block of registers (i.e. read other registers in the same message along with the PRODUCT ID register), but you must always start reading at the 406255 register.

Correct Example:
Modbus Address: 1
Starting Register: 406255 (register number) or 625410 (address)
Number of Registers to Read: 4 (collects both PRODUCT ID and Frequency (Hz))

The mMINT will return four 16-bit registers, the first two being the PRODUCT ID of the INCOM device associated with Modbus address 001 (which could be either a device with INCOM address 001 or could be something else if the mMINT routing tables are used to remap Modbus-to-INCOM addresses) and the second two the frequency as a 32-bit integer scaled by 10 (divide 32-bit number by 10 to get actual frequency).

Incorrect Example:
Modbus Address: 1
Starting Register: 406253 (register number) or 625210 (address)
Number of Registers to Read: 6 (collects Power Factor, PRODUCT ID and Frequency)

The mMINT will return six 16-bit registers, with the first two being the power factor, the next two being the PRODUCT ID and the last two being the frequency.  Because you didn't request PRODUCT ID as the first register in the table, the value returned will be INCORRECT.

Decoding Fast Status
The data returned in PRODUCT ID is the data returned using the INCOM "Fast Status" message.   You can read about the INCOM Fast Status message in the IMPACC protocol guide: http://www.eaton.com/ecm/groups/public/@pub/@electrical/documents/content/1030709222496.pdf#page=33
(http://pps2.com/images/smf/mmint/fs.png)
You'll notice that there are three 8-bit bytes returned, which contain a total of 24-bits.  Because Modbus registers are 16 bits long, you need two registers or 32 bits.  There won't be anything in the upper half of the second register (BYTE3 as described in INCOM protocol manual and how I display it in my Excel program). 

Notice that inside those 24 bits you see letters S, P, V and D with numbers after them.
(http://pps2.com/images/smf/mmint/msb-lsb.jpg)

"S" are status bits.  These describe the state of the device (open, closed, trip, alarm, etc.).   You see that bit S7 and S6 define whether the device is open, closed, tripped or alarm (for example, in a trip unit like the Digtrip 1150, alarm corresponds to a long delay pickup... you are going to trip if the current stays at this level).  S7 and S6 are the most significant bits of Byte 2 of the reply returned.  Note: the meaning of these bits can change depending on the type of device providing the Fast Status ... e.g. a trip unit versus a meter versus a transfer switch controller.

For example, if you look at the INCOM guide for the DT1150: http://www.eaton.com/ecm/groups/public/@pub/@electrical/documents/content/il17384c.pdf#page=136
(http://pps2.com/images/smf/mmint/1150.jpg)

So you see that S0-S5 provides additional information.  But you also see that the meaning of S4 differs depending on whether you have COMM VERSION 0 (bits V3-V0 are all zero) or if you have COMM VERSION 1 (bits V3-V1 are zero and V0 is one).

Here's another example...  an ATC-600. 

Checking out the ATC-600 (also known as the IQ Transfer II) you see from: http://www.eaton.com/ecm/groups/public/@pub/@electrical/documents/content/il17384f.pdf#page=61 that the Fast Status (and therefore what is returned in the PRODUCT ID register in the Modbus MINT is as follows:
(http://pps2.com/images/smf/mmint/atc.jpg)

Using the mMINT Excel program (http://pps2.com/smf/index.php/topic,29.msg39.html#msg39), and reading the PRODUCT ID register, you might get something that looks like this:
(http://pps2.com/images/smf/mmint/prodid-live.jpg)

We see that the values returned are:
BYTE0 / B0 = 196  (C416)
BYTE 1/ B1 = 84  (5416)
BYTE 2 / B2 = 195 (c316)

Converting these hexadecimal values into binary (to see the individual bits) we have the following:
(http://pps2.com/images/smf/mmint/convert2bin.jpg)

Now you can segregate the bits into their groups.  Starting with the Division Code, we see the following:
BYTE0:
(http://pps2.com/images/smf/mmint/D5.jpg)
   Converting this Division code from binary to decimal we have 4 ... the correct value  (http://pps2.com/images/smf/mmint/divcode4.jpg)

Now looking at the Communication Version we take the top 2 bits of BYTE0 and the bottom (least significant) 2 bits from BYTE1:
(http://pps2.com/images/smf/mmint/V3.jpg)
   Converting this Communications Version from binary to decimal we have 3.  From the list above: (http://pps2.com/images/smf/mmint/incorporate.jpg)


Now looking at the remaining bits in BYTE1
BYTE1:
(http://pps2.com/images/smf/mmint/p5.jpg)
   Converting this PRODUCT ID from binary to decimal we have 16+4+1 = 21 ... the correct value  (http://pps2.com/images/smf/mmint/p21.jpg)

Now finishing with BYTE2:
(http://pps2.com/images/smf/mmint/s7.jpg)
Both bits S6 and S7 are on, so we are in alarm:  (http://pps2.com/images/smf/mmint/11alarm.jpg)

(http://pps2.com/images/smf/mmint/s5.jpg)   Only bits S0 and S1 are on, so both sources are available.
(http://pps2.com/images/smf/mmint/s1s0.jpg)

Sure enough, when we look at the faceplate of the ATC, that is what we see... both sources are available and we are in alarm!
(http://pps2.com/images/smf/mmint/atcfront.jpg)
Title: Re: Modbus MINT (Modular INCOM Network Translator or mMINT)
Post by: Dave Loucks on September 16, 2016, 03:41:07 PM
Having trouble talking to an mMINT and you've tried all the other steps in this section?

The trouble might be with "self-powered" 232-485 converters connected to industrial automation, protective relays or other devices with EIA-232 ports.

You can read more here (https://pps2.com/smf/index.php?topic=217.msg244#msg244).
Title: Modbus MINT (Modular INCOM Network Translator or mMINT) Power Connections
Post by: Dave Loucks on September 20, 2016, 10:57:35 AM
When trying to wire power to the mMINT, it may not be completely obvious which wire connects where.  Here is the diagram from the Eaton instruction booklet for the mMINT:
(https://pps2.com/images/smf/mmint/mMINT_power_wiring.png)

Perhaps this diagram will make it clearer:
(https://pps2.com/images/smf/mmint/mMINT_power_wiring_2.jpg)
You can ground the ac neutral or the dc common to the same terminal 1 on the J1 terminal block.

You can download a larger version immediately below.
Title: Re: Modbus MINT - 02 Illegal Address exception
Post by: Dave Loucks on September 01, 2017, 11:39:41 AM
Have you attempted to read what should be a valid register and you get the Modbus Exception Code 02 (Illegal Address) or 03 (Illegal Data Value)?

Two fixes:

Click on the image below to view a video explaining this problem with the mMINT and how to fix it (just set 42001 to 0 and make sure you start reading registers at a proper "boundary").

(https://pps2.com/v/m4/mMINT_illegal_addr_video.jpg) (https://pps2.com/v/s/1/mmia.php)
Title: USB to RS-485 adapter for Computer
Post by: Dave Loucks on February 15, 2018, 08:14:59 AM
Since the mMINT communicates on Modbus using RS-485 and since most computers and laptops don't have an RS-485 port you might ask "how do I talk to the mMINT?"

Here's an article (https://pps2.com/smf/index.php/topic,234.0.html) that discusses one very inexpensive method.

(https://pps2.com/images/smf/mmint/JBTech_USB_485_to_mMINT.jpg) (https://pps2.com/smf/index.php/topic,234.0.html)
Title: Decoding 32- and 64-bit fixed point values
Post by: Dave Loucks on November 12, 2018, 10:25:21 AM
While the published Modbus standard (http://www.modbus.org/specs.php) explains the bit/byte order of 16-bit registers, it doesn't include any instructions for how to deal with 32 or 64-bit registers.  That is left up to the vendors using the Modbus protocol.  Here is how the mMINT handles them.

Example:
Read 32-bit Product ID Modbus Register pair (406255/406256)













Request
(hex)
Modbus Node02
Function Code03
Starting Address (High)18
Starting Address (Low)6e
# of Registers (High)00
# of Registers (Low)02
CRC (Low)A3
CRC (High)45
   












Response
(hex)
Modbus Node02
Function Code03
Byte Count04
Register Value (High)(406255)0C
Register Value (Low)(406255)63
Register Value (High)(406256)00
Register Value (Low)(406256)80
CRC (Low)3B
CRC (High)DD
To convert these two 16-bit registers into one 32-bit register:

Value = (3171) + (128*655361)
Value = (3171) + (8388608)
Value = 8391779 (800C6316)

For 64-bit values, the process is similar.

Example:
Read 64-bit Real-Energy-Forward Modbus Register 4-register group (406305-406308)













Request
(hex)
Modbus Node02
Function Code03
Starting Address (High)18
Starting Address (Low)A0
# of Registers (High)00
# of Registers (Low)04
CRC (Low)42
CRC (High)B8
   
















Response
(hex)
Modbus Node02
Function Code03
Byte Count08
Register Value (High)(406305)00
Register Value (Low)(406305)00
Register Value (High)(406306)00
Register Value (Low)(406306)00
Register Value (High)(406307)00
Register Value (Low)(406307)00
Register Value (High)(406308)03
Register Value (Low)(406308)00
CRC (Low)9A
CRC (High)63
To convert these four 16-bit registers into one 64-bit register you can convert the two register pairs to decimal and multiply them by 256 raised to these powers:










Register Value (High)(406305)00 * 2561
Register Value (Low)(406305)00 * 2560
Register Value (High)(406306)00 * 2563
Register Value (Low)(406306)00 * 2562
Register Value (High)(406307)00 * 2565
Register Value (Low)(406307)00 * 2564
Register Value (High)(406308)03 * 2567
Register Value (Low)(406308)00 * 2566
Value = 0 +... + 0 + 316 * 7.206 x 1016
Value = 2.1617 x 1017
Text only | Text with Images