Modbus MINT (Modular INCOM Network Translator or mMINT)

[Dave Loucks]

The mMINT is used to connect devices that use the INCOM protocol to a Modbus RTU network via a 485 twisted pair network.


A more complex diagram could look like this:


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).


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
• Custom Pass-Through

Preset Modbus Register Map
Refer to Tables 8 and 9 in the Modbus MINT instruction manual. 

Some important notes:

• The mMINT does NOT poll the INCOM devices without a request being received from the Modbus master.  The mMINT does not have the data waiting in Modbus registers from the INCOM devices.
• When a command supported by the mMINT is received from the Modbus master, the mMINT will send a Fast Status to see if the device is under it.
• If so it logs it in and continues to process the command (i.e., do more INCOM transfers to obtain the data).
• If the device is logged in (and would be logged back off with about 5 consecutive no responses from the INCOM device), it simply processes the command (INCOM transfers) without the FS.
• It is important to note that the mMINT response to the Modbus master is delayed waiting for the INCOM responds.  The mMINT needs to obtain all the data from the INCOM network and organize it into the Modbus register format response.
• Even when the mMINT receives a command for a Modbus device address not under the mMINT, it will send the FS out on INCOM (will get a timeout and not log it in).
• Also, the initial time the mMINT needs to get an object, it will try all the various ways to get the data from INCOM and log that way for that device.
  Future accesses for that object will then always use that INCOM command.
  

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.



Besides the instruction manual that you can download from the Eaton web site, I also wrote a few other app notes that might help.

• Modbus MINT Application (attached below)
• IQ/Digitrip Communications
• Transfer Switch Communications

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

No response?

• Make sure downstream devices are powered up!  Trip units, for example, won't respond unless sufficient current is flowing through them (or the optional auxiliary power supply is installed) because the microprocessor is not powered
• If using a subnet master on the INCOM network (like a Breaker Interface Module or BIM), make sure you have uploaded the subnetwork routing table to the mMINT.  See article on Subnetwork Routing below.
• Check 485 polarity (some devices use A & B, but the meaning of A & B (is A + or -?) changes between vendors. 
• Check 485 termination switch (only close if at end of line).  If the mMINT is not at the end of the 485 line, make sure SW3 is OFF.
  
  If the mMINT is a the end of a 485 line, make sure SW3 is ON.
  

Invalid Responses

• Check 485 termination switch (only close if at end of line).
• INCOM devices disconnecting?  The mMINT will remember that an INCOM device was there so if a Modbus request arrives for that (previously available) INCOM device, the mMINT will respond with an error oinly for the first 5 attempts.  After 5 attempts the mMINT will stop responding with a Modbus error message and instead go silent until the INCOM device at that address once again is restored to operation.

[Dave Loucks]

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:

	Modbus Address	INCOM 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)):




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 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 to simplify filling in the Modbus to routing register cross-reference table.  Optionally, you can use the Excel programming tool to configure these registers.  The use of this tool is described in this tutorial video.

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 further down this page.)

• The mMINT is a pass-through device.  To read or write any Modbus registers on the mMINT device itself, remember you must give the mMINT its own Modbus network address.  To do so, move DIP SW2-1 to the OPEN position:
  
  The mMINT's Modbus address is then set to 247 (248 also works). 
  NOTE: the position of DIP switch 2 may be rotated 180 degrees (upside down) from what is shown on this picture (in other words, OPEN would be away from the mMINT housing).  Be sure to look closely at the switch for the printed words OPEN (or CLOSED) and set switch OPEN to activate the Modbus addresses 247 and 248.
  NOTE: The mMINT originally could only be addressed using Modbus node 248.  In V1.06 firmware a change was made that when SW2-1 was opened BOTH addresses 248 AND 247 would be activated.  This change was made because some Modbus masters could not access a slave device above 247.  A complete list (CodeRevisions.txt) of all mMINT firmware revisions is attached immediately below this subarticle.
  
• Using Modscan or other Modbus master program, send Modbus function code 16₁₀ (10₁₆) [Write Multiple Registers] to address 247 or 248 (either one works) along with the data in registers 42101 to ... (where the last register is dependent on how many look up entries you wish to use.  An Excel spreadsheet is attached that shows the cross-reference between Modbus addresses and the lookup register pair stored within the mMINT.
  
• Move SW2-1 back to the CLOSED position once you are done.  (You can technically keep the switch in the OPEN position, but doing so keeps the ability to make remote changes to its flash configuration which might be a security issue.  Also, having two or more mMINTs with SW2-1 open would place two more more devices with address 247 and 248 on the same network.  Collisions will result.  On the other hand, note that moving SW2-1 back to closed not only locks out the ability to make remote changes, but it also prevents viewing mMINT diagnostic registers on that mMINT.  For this reason, it may make sense to place each mMINT on its own Modbus network.)

Here's a larger example to show how the addresses can be allocated:



ModScan 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

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.



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 (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:



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 Expand


//
// 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:



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



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).

[Dave Loucks]

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

[Dave Loucks]

Here's how to read and decode these registers:

• You must read both registers (404609 and 404610 [floating point] or 406145 and 406146 [integer]) in one Modbus message.
  
  You can't just read one register at a time.  You'll get an error!  You can read more than 2 registers at a time, as long as the block of registers you read ends by reading a complete register (if it is a 2-register pair, you must read both... a 4-register value, you must read all 4, etc.). 
  
  To retrieve the register pair as floating point, depending on your system you may only specify the starting register and the type (float).  After all, a single precision IEEE floating point value uses 32-bits so that means you need 2 registers.
  
  Your system may automatically know that and read two Modbus registers (example Tridium JACE 8000 running Niagara 4) when you specify you are reading a floating point register. 
  
  For reading these status values from the integer registers (406145-406416) some systems, may automatically retrieve both registers if you specify that you wish to read a "long" integer (example Tridium JACE 8000 running Niagara 4).
  
  For other systems you may need to specify that you wish to read two 16-bit registers and you will manipulate them as separate values.
  
  In particular, in the mMINT Modbus memory map notice that the next higher registers past these status registers contain currents and they are also 2-register pairs (since both integer and floating point values are 32-bit values, stored in 2 16-bit registers).  If you decide to include those registers in the same read message, you must set your length to read only complete pairs of registers for a complete register.  If you were to end your read to only read the first half of a register, you'll get an error.
  
• Those two registers hold one large number that must be subdivided into 3 parts!
  
  Appendix A, #12 on page 15 in the IL tables 10, 11 and 12 show how to interpret the data for those three parts

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)

• Divide the number returned by 2¹⁶ (65536)
  The quotient is the code for Table 12 (Cause-of-Status Code)
• Now subtract from this number (quotient * 65536) to give the combined Table 10 and 11
• Divide the combined Table 10/11 value by 256
  The quotient is Table 10.
  Now subtract this new quotient from the Table 10/11 value to give the Table 11 value

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

66055/65536 = 1.004013...   -> Table 12 = 1 (Normal Operating Mode)


66055 - (1*65536) = 519

519/256 = 2.0273... -> Table 10 = 2 (Closed)


519 - (2*256) = 7 -> Table 11 = 7 (Powered up)

[Dave Loucks]

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 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

• Now displays firmware year correctly for all mMINT firmware releases to date.
• Detects certain mMINT user configuration errors.  "Fix It Now" buttons appear when these problems are detected.  The user can chose to press this button to reconfigure mMINT configuration to correct values.

VBA-comms10

• Added support for sending Loopback Diagnostic codes to addresses other than 248.  This is important since (as shown in Table 6 in the mMINT Instructional Leaflet), sub-function codes 21 and 22 (slave INCOM BCH error count and slave INCOM overrun count, respectively) only have meaning for INCOM devices.
• Changed Diagnostic counters so they could be reset to zero after pressing the "Send Reset" button on the mMINT tab.
• The "Start Here" check for the mMINT now also reads the firmware version and displays both it and the firmware year following the pressing of the "Check" button.
• Changed how the firmware version and revision was displayed.  Now forced the revision to be a 2-digit number by inserting a leading zero into the revision for any revision less than 10.  Example: version 1, revision 3 would now be displayed as V1.03 instead of V1.3 (as it would have been shown in prior versions of this program.)  This was done to match the look of the version sticker placed on the mMINT case by manufacturing.
• (mMINT tab) Changed descriptive text above the "Write Routing" button explaining that to write changes you must press both "Write Config" (to update configuration registers 42001-42003) AND "Write Routing" (routing registers 42101 - 42592).  While it may have been clear you needed to press both buttons to update both sets of settings, the text was modified to clarify further.
• Program now checks mMINT firmware and displays appropriate error messages about unavailability of routing and/or configuration table programmability.  Releases prior to V1.05 did not support either, nor did it include the mirrored registers below 9999.  Earlier releases placed data in registers above 9999 which some Modbus masters could not access.  Releases prior to V1.06 did not support mMINT address 247.  Releases prior to V1.10 did not support ATC-300 transfer switch controller.  All these idiosyncrasies are now flagged to the user, hopefully clarifying why their (older) mMINT doesn't seem to have the functionality described in the (latest) instructions found on the web.

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:

• Cloud backup and restore
• Control commands

Here's the list of upgrades to this version:

• Includes an example of a simple "Backup and Restore" functionality to allow a user to send their data to a cloud based storage for safekeeping.
• Activation feature included to serialize each copy of the program.
• Added code to troubleshoot if not able to configure COM port.  In the past, program would simply not communicate without providing any indication of the reason for the failure.
• Checkbox included ("Extended error logging") to enable/disable the logging of COM port configuration errors.  If this checkbox is checked (is by default), then failures to configure COM port are written to log file with additional descriptive text explain the reason for the failure.
• Added additional diagnostics to detect if modem or line driver is in loopback or echo mode.  A warning given for the user to check their settings to insure the system is set to 2-wire mode.  Converters/modems/line drivers properly set in 2-wire mode mute their receivers when they are transmitting so they don't hear a copy of their own transmission.
• Added additional diagnostics to detect if the COM port selected is in use.  (One potential situation is if this program crashes during communications.  If so, the program won't have signaled the Windows operating system that it is finished using the COM port and to Windows, it will still be in use.  A subsequent attempt to reconnect using the same port will be rejected by Windows as that port will be considered to still be in use.  The fix is to close and reopen Excel.)
• Fixed bug that could cause the COM routine to hang in the particular case where the program was interrupted (or crashed) during communications.  The system would be left in a state where a subsequent attempt to communicate would result in the receiver waiting indefinitely for a response to a message.  True Modbus assumes the end of a message has been received if no character is received after waiting 3.5 character times and hearing no new data.  While program functionality worked properly prior to a crash, it wasn't immediately obvious (due to my attempt to more gracefully recover after a crash) to the user that the program had crashed.  I now alert the user by giving more details in the log file, advising that the program should be shut down and restarted to resolve this problem.
• Device Data tab now include a check box that activates displaying the data retrieved from the devices connected to the mMINT as hexadecimal in addition to decimal.
• Added new color code (orange) to the background of each value read from the mMINT, now in addition to green (valid response) and red (invalid/failed Modbus message response).  Orange means that a valid response was heard but it exactly matched the message sent.  This is normally an indication of an improperly configured 485 line driver/converter or modem (likely set for 4-wire rather than 2-wire mode but connected on a 2-wire network).  However, this can occur normally in the one case of the Modbus Loopback function.  The mMINT uses the Modbus Loopback function to interrogate certain internal mMINT registers (these are status registers internal to the mMINT and outside the normal Modbus register memory map).  Since it is perfectly possible for a response to match the request (occurs when the response says there is a zero in the register), it could also indicate an echo.  If at least some of the data is returned as green, then it is likely not an echo and the orange coded fields can safely be assumed to be "green"
• Besides adding the color code for the loopback messages, also seeded the loopback request with a non-zero value in one of the overhead bytes.  Now, if the mMINT responds correctly, the reply will more than likely overwrite that reply with a different value and the request and the reply won't match.  That tells the program that there isn't a modem loopback returning a reply, but it is a real Modbus device.  The field will be color coded green instead of orange.  If, in the unlikely but possible event that the reply includes that seeded value, the program will have no way to know if that particular message was an echo of the request or if it was an actual reply with real data (that just happened to match the seed value put in the request).  In this case, the response will be color coded orange.  However, as mentioned above, if the modem is in loopback mode, ALL responses will be echoes of the requests, not just one.  Therefore if ANY of the other responses are green, then we know that the modem is not in loopback (or a 2-wire system is set to 4-wire mode, for example).
• Discovered that the mMINT could get into a mode where it would respond to messages addressed to 248 (or 247) and would pass-through requests for addresses 1-246, but would not translate the response from those INCOM messages into Modbus.  With no reply from the mMINT, the polling program would assume the INCOM devices 1-246 went off line.   However, when examining the appropriate INCOM device's Tx and Rx LEDs, it was clear that an INCOM reply was being sent - the mMINT just chose to not translate this into a Modbus message and forward to the polling device!  The solution was to send a sequence of mMINT reset messages listed in Table 6 of the Instruction Leaflet (IL).  Now, when pressing the "Check" button, the program not only reads firmware revision information, it also sends loopback subfunction codes 10 (clear slave counters), 20 (clear UART counters), 29 (remove INCOM devices), and 30 (reset INCOM routing addresses).
• Prior to downloading "Selected Cloud Values" to mMINT, a validity check is performed (basically are the values integers in the proper range?) prior to downloading.
• Added new tab "Control" that issues INCOM Slave Action messages through mMINT to INCOM devices

Known bugs in V0.11

• Backup-Restore tab: If one user logs in and retrieves a file listing for their account, then opens the window to select a file to upload (doesn't matter whether they do or don't upload) and then a second user logs in and retrieves a listing of the stored files for that second account, when the second user attempts to view the available files they will see the file listing for the first user.  Fix: Close Excel spreadsheet to completely log out the first user.  Fixed in V0.12.
• Fixed a major bug where data copied from the cloud was written to the mMINT registers offset down by two.  In other words, if the value was supposed to have been written into mMINT register 42103 and 42104, it instead was written to 42101 and 42102. Fixed in V0.12
• Fixed bug where the firmware revision was stored properly in its correct location in the cloud database, but also incorrectly overwriting the firmware month and day.  Fixed in 0.12.

VBA-comms12

• Modified code to use new database (database SQL injection protection algorithms changed)
• Added new error messages when attempting to store data to cloud if DLM system is offline.
• Added new error message if attempting to download a blank listing from the cloud database.
• Added status message.  After copying file from cloud the program displays a message that it is ready to write selected values to mMINT.  In other words, the program is waiting for you to press the 4th button marked Write Selected Cloud Values to mMINT.
• Switched off PHP error display (improve security)
• When registering as a new user, enlarged the Comments box (made it support multiple lines ... use <Shift>-<Enter> to create new line) on the new user registration form.  Also included a character counter so user knows how many of the remaining 1000 characters for this comment field are available.
• Added missing label Device over columns F & G, row 11.  Also changed labels over row 12 to say decimal and hex.
• Fixed bug in Backup-Restore tab where if one user logged in with one set of credentials, downloaded a listing (but didn't choose a file) -- if then a second user logged in with a different set of credentials and downloaded a different list of files -- the system would present the files from the first user, not the second.
• Added status messages to display if a user tries to register a username/email that has already been registered (but is awaiting authorization by an admin).
• Fixed a major bug where data copied from the cloud was written to the mMINT registers offset down by two.  In other words, if the value was supposed to have been written into mMINT register 42103 and 42104, instead incorrectly it was written to 42101 and 42102.
• Fixed bug where the firmware revision was stored properly in its correct location in the cloud database, but also incorrectly overwriting the firmware month and day.

VBA-comms13

• Discovered that in the 1.10 version of the mMINT firmware if attempting to read PRODUCT ID (register 406255 or address 6254) as part of a larger block of data (such as attempting to read registers 406145-406262), invalid data would be returned.  The solution was to issue a read register command starting with the PRODUCT ID register 406255 (address 6254) by itself.  When reading only that register (or when that is the first register of a block of registers, the data returned would be correct.

VBA-comms14

• Fixed the problem where the PRODUCT ID register still wasn't updating correctly (too little regression testing on V0.13... that's what happens when you rush a fix!).

VBA-comms15

• Decodes the PRODUCT ID 32-bit register pair (406255-406256) and populates S(tatus), D(ivision), P(roduct ID), and V(communication firmware version).  From the "Start Here" tab, after you have clicked on the "Find Devices" button, just click on the cell associated with any found device.  The decoded values from the PRODUCT ID register pair will be displayed at the top of the spreadsheet. 
  
  In the screenshot below P=21 (which according to https://www.eaton.com/ecm/groups/public/@pub/@electrical/documents/content/il17384f.pdf#page=61 means this is an automatic transfer switch controller), bits 6 & 7 of the Status register (S67) = 3 (or 1 1 binary which according to that same link means the ATC is in alarm), bits 0 through 5 of the Status register (S05)=3 (or 1 1 binary, which means that both sources feeding into the transfer switch are available), V=3 which means Comm firmware version 3 is installed and finally D=4 which is an internal designation for an Eaton business division. 
  
  

NOTE: for more information on decoding the PRODUCT ID register, refer to the article immediately below.

VBA-comms16

• Includes a new feature that allows "pinging" individual Modbus register addresses to see if they are valid.
  
  This feature is useful when using the mMINT "zero-fill" setting.  With zero-fill, registers that you request from the mMINT for a particular device will return zeros (rather than errors) if you attempt to read a register that is not available for that device (example: attempting to read line voltage on a Digitrip 520).
  
  The trouble is, you have no way of knowing which registers are returning real zero values and which are returning zeros to tell you that register isn't supported.
  
  Now, with this feature, you can switch off zero fill (see tutorial video) and ping each register in question.  The program is pretty manual right now, but if you get an error when you ping a Modbus register, well you know that device doesn't support a read from it!
  
  Check out this tutorial video on using this new feature.
  
  

VBA-comms17

• Includes a new feature that allows monitoring traffic over a serial network by using something called "Eavesdrop mode".  While version 16 added the ability to send and receive messages and watch the bytes sent and received from this program, version 17 adds a new feature to listen to a serial network and copy the traffic (similar to how WireShark does this on an Ethernet network).
  
  
  The data is just copied raw.  No interpretation of the data is made. 
  
  To use: Make sure you have selected the right serial port (COM1, 2, etc.) and bit rate (only 1200, 9600 and 19200 are supported in this version) from the Start Here tab in the spreadsheet.
  
  
  
  
  Then just select how many bytes you want to collect (10-10000) and press the "Eavesdrop" button.
  
  
  Data will be retrieved until at least that many bytes have been captured.  The number of bytes collected so far will be displayed as "Block: xxx" (where xxx are the number of bytes captured so far).  You can press stop to halt collection.  No data is shown in the windows until the last byte has been collected (or after the stop button is pressed).
  
  
  The received data will then be displayed both in decimal and hexadecimal formats.  You can copy data from either window and paste to a document or email. 
  
  Note: No interpretation of the data collected is made.  However, V18 is planned to recognize and automatically parse Modbus messages (e.g. Is a particular byte shown on the screen from the master or a slave?  If latter, which?  Is the message a read or write and to what register, bit or I/O is the message addressing and what value was transmitted to/from that register, bit or I/O?  Was the message completed successfully?, If not, what was the error and possible fix?, etc.)
  
  

VBA-comms18

• Bug fix: For COM ports > 2 might give error code 9 and report the port was not available even if port was available
• Bug fix: Error when pressing "Send Reset" button in mMINT tab.

VBA-comms19

• Bug fix: For bit rates other than 19.2 kbps, the VBA_Comms could prematurely timeout and report a bad response.  Now fixed.

VBA-comms20

• Rewrote it to remove ActiveX controls (buttons, combo boxes, etc.) and replace with Form controls.  Some users were reporting problems with running Active X

VBA-comms21

• Minor bug fix.  Can now reset mMINT Table 6 registers assigned to each INCOM slave device.

VBA-comms22

• Added support for use on 64-bit Excel.

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/

[Dave Loucks]

VERY IMPORTANT
A request to read the Modbus MINT PRODUCT ID must always start at the PRODUCT ID 406255 register (underlying address 6254₁₀ or 186E₁₆).  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 6254₁₀ (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 6252₁₀ (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

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.


"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


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:


Using the mMINT Excel program, and reading the PRODUCT ID register, you might get something that looks like this:


We see that the values returned are:
BYTE0 / B0 = 196  (C4₁₆)
BYTE 1/ B1 = 84  (54₁₆)
BYTE 2 / B2 = 195 (c3₁₆)

Converting these hexadecimal values into binary (to see the individual bits) we have the following:


Now you can segregate the bits into their groups.  Starting with the Division Code, we see the following:
BYTE0:

   Converting this Division code from binary to decimal we have 4 ... the correct value 

Now looking at the Communication Version we take the top 2 bits of BYTE0 and the bottom (least significant) 2 bits from BYTE1:

   Converting this Communications Version from binary to decimal we have 3.  From the list above:


Now looking at the remaining bits in BYTE1
BYTE1:

   Converting this PRODUCT ID from binary to decimal we have 16+4+1 = 21 ... the correct value 

Now finishing with BYTE2:

Both bits S6 and S7 are on, so we are in alarm: 

   Only bits S0 and S1 are on, so both sources are available.


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!

[Dave Loucks]

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.

[Dave Loucks]

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:


Perhaps this diagram will make it clearer:

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.

[Dave Loucks]

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:

• Write a 0 to 42001
  Writing a zero to this register relaxes the error checking on the mMINT such that if you read a block of registers and one or more of those registers within that block are not supported by the connected device at that address, the mMINT will "zero fill" the response and not send a 02 exception
  
• Extend the length of block read to include prior registers
  For example, attempting to read frequency (406197) alone on a DT1150, even if the 42001 register is set to zero can result in an 02 exception.  The fix is to read the prior register 406195 [3-phase apparent power factor] and frequency 406197 as a complete range.  For the PM3, that trick doesn't work and you need to back up to start reading at register 406187.  Note that for this trick to work in either case, 42001 must also be set to 0.  Also, the starting register for this block depends on the device!  While starting at 406195 works for the DT1150, to read frequency on the PM3 you must start by reading 406187 and reading the 12 subsequent register pairs all the way to 406198 to pick up the last register of the 32-bit register pair for frequency (406197/406198).

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").

[Dave Loucks]

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 that discusses one very inexpensive method.

[Dave Loucks]

While the published Modbus standard 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)

   
• Remove the "40" and subtract 1 from lowest register number to find "wire" starting address:
  406255 -> 6254
• Convert to hex:
  6254₁₀ -> 186E₁₆
• Place in proper location of Modbus message
  
  
  
  

  Starting Address Low Byte	6E
  Starting Address High Byte	18

Request (hex) Modbus Node 02 Function Code 03 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 Node 02 Function Code 03 Byte Count 04 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

   
• 406255 = 3171₁₀ (0C63₁₆)
  
• 406256 = 128₁₀ (80₁₆)
  

To convert these two 16-bit registers into one 32-bit register:

Value = (3171) + (128*65536¹)
Value = (3171) + (8388608)
Value = 8391779 (800C63₁₆)

For 64-bit values, the process is similar.

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

   
• Starting with the first register in the list, remove the "40" from the beginning of the register number then subtract 1 from what remains:
  406305 -> 6304
• Convert to hex:
  6304₁₀ -> 18A0₁₆
• Place in proper location of Modbus message
  
  
  
  

  Starting Address Low Byte	A0
  Starting Address High Byte	18

Request (hex) Modbus Node 02 Function Code 03 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 Node 02 Function Code 03 Byte Count 08 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

• 406305 = 0
• 406306 = 0
• 406307 = 0
• 406308 = 3

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 + 3₁₆ * 7.206 x 10¹⁶
Value = 2.1617 x 10¹⁷