Mitsubishi Driver Beta Test Open Now! Test through April

Beta Testing Context

Thank you for helping test the native Ignition Mitsubishi drivers. This is a tight window (April) as we are aiming for production release in 8.1.28 (May 30th). Please provide feedback here as soon as you have it. Non-bug feature requests will be most actionable in the first few weeks of April.

April 3rd. Beta Release. Set up your Mitsubishi hardware now!
April - ~May 1st Beta Test Window.
May 12th Code freeze for final QA/release (8.1.28). Changes must be complete.
May 30th Production Ignition release of 8.1.28 with Mitsubishi driver included.

Beta Testing Instructions

  1. Download and install the latest 8.1.27 Nightly (dated Apr 3rd or later).

  2. Download and install the latest Mitsubishi Driver module
    Mitsubishi-Driver.modl (678.7 KB)

  3. Report bugs and request features.

Mitsubishi TCP Driver

The Mitsubishi TCP driver provides a user interface in the Gateway where you can create, import, and export addresses when connected to devices that support the MELSEC protocol. After setup, configured tags will be browsable in the OPC Browser of the Designer with read/write access. Supported Hardware Series include:

  • iQ-R
  • iQ-F (FX5U)
  • Q
  • L

Connect to Mitsubishi devices

Before you can connect your Mitsubishi device to this driver, make sure your GX Works software settings meet the driver requirements. Detailed setting requirements are included in the GX Works Configuration section.

  1. Navigate to Config > OPC UA > Device Connections on the Gateway Webpage.
  2. On the Devices page, click on Create new Device.
  3. Select Mitsubishi TCP, and click Next.
  4. Fill in the Name field. Entering a description is optional.
  5. Select the MELSEC series you will be connecting to using the dropdown. Options include iQR, Q, and L.
  6. Enter the device hostname in the Hostname field.
  7. Enter the device port in the Port field.
    Note: Be aware that because Q/L and iQ-R Series allow only one SLMP client connection per unique TCP port, a connection attempt on an already established port will be refused by the PLC.

8. Enter the local address of the network adapter to connect from. This is necessary if you have multiple network cards and you need to specify the particular network card that has PLC access.
9. Leave the default values in the remaining fields.
10. Click Create New Device.

The Devices page now displays the Mitsubishi TCP device is successfully connected.

Device Settings

General Description
Name Device name
Description Device description
Enabled If true, attempt connection to the device, default is true
Main Description
Series The series of the Mitsubishi device. Default is iQR
Hostname The IP Address of the device
Port The port the device is listening on
Local Address Address of network adapter to connect from
Timeout The request timeout, specified in milliseconds with a valid range from 0 to 16383750. Default is 5000
Request Optimization Description
Max Gap Size The maximum address “gap” to span when optimizing requests to contiguous address locations. Increasing the max gap size will reduce the number requests but increase the amount of data requested. Default is 0.
Write Priority Ratio The number of write requests to execute for every read request when an abundance of both types are queued up for execution. Default is 5.


You can add addresses by entering the Tag Path and Address information individually or importing a CSV file containing a list of addresses to upload at once. The addresses page is setup to read three areas of address information to create tags:

  • Tag Path: This is what will appear as the tag name.
  • Address: This is the device, offset, and additional specifications to find desired values.
  • Description: This is an optional field to help in identifying displayed values.

To access the addresses page on the Gateway:

  1. Go to the Config > OPC UA > Device Connections.

  2. Click the More dropdown and choose addresses on your Mitsubishi device.

Adding Individual Address Rows

Even if you are planning to import multiple addresses using a CSV file, it’s recommended to first enter a single tag address to test if your connection is working as expected.

To enter addresses:

  1. Click Add Row to populate rows for address information.
  2. Enter Tag Path field and Address field information. Enter Description information as desired.
    Note: All components are case-insensitive.
  3. Continue adding rows and address information until you’ve added all the addresses you want to be available as tags.
  4. Click Save Configuration when you are finished.

Importing and Exporting

To Import a CSV file:

  1. Select Load Configuration File on the device address page.
  2. Select Choose File.
  3. Locate the CSV file you want to upload and select it to open.
    Note: Make sure a comma separates column information, and if your Description column includes commas, use quotes to prevent misinterpretations when uploading.
  4. Select the Append to current configuration box if you already have addresses listed and you want to add on to them. Leave unchecked if you want to replace existing rows.
  5. Click Load.
    Note: If an existing address shares a tag name with an address imported by the CSV file, it will be replaced with the imported address.

  1. Click Save Configuration.

Click the Export Configuration icon to download the existing address rows as a CSV file.

Determining Addresses

The Mitsubishi driver requires Area and Offset address components, but also allows many optional specifications. It’s important to know where the optional components must be placed in your address to properly connect. The example syntax below shows how optional data type (including modifiers) and array specifiers are listed before the Offset specification and the optional array element index and bit index must be listed after the Offset specification.

Note: This page uses the term Area to describe the address component that identifies the PLC device to eliminate confusion with other sections of this page, such as the Device Settings which applies to the Ignition Mitsubishi driver.

Example syntax, where optional components are included in curly brackets

Areas (Devices)

The following table shows the device keyword recognized by the driver as well as the native type of each device. Extended Data Registers and Extended Link Registers are currently not supported.

Device Name Keyword Type
Special relay SM Bit
Special register SD Word
Input X Bit
Output Y
Internal relay M
Latch relay L
Annunciator F
Edge relay V
Link relay B
Step relay S
Data register D Word
Link register W
Timer Contact TS Bit
Coil TC
Current value TN Word
Long timer* Contact LTS Bit
Coil LTC
Current value LTN Double word
Retentive timer Contact STS Bit
Coil STC
Current value STN Word
Long retentive timer* Contact LSTS Bit
Current value LSTN Double word
Counter Contact CS Bit
Coil CC
Current value CN Word
Long counter* Contact LCS Bit
Coil LCC
Current value LCN Double word
Link special relay SB Bit
Link special register SW Word
Direct access input DX Bit
Direct access output DY
Index register Index register Z Word
Long index register* LZ Double word
File register Block switching method R Word
Serial number access method* ZR
Refresh data register* RD Word

*Not available for Q/L series


The Mitsubishi driver supports reading/writing data types larger than the area’s native type by combining bytes from adjacent offsets into a single value. For example, each Data Register (D) point is natively a word (16-bit), but reading D0 requests bytes for D0 and D1 and combining the bytes into a signed 32-bit value.

The Mitsubishi driver does not support reading/writing data types smaller than the area’s native type. For example, each Long Index Register (LZ) point is a double word (32-bit) which means LZ0 and LZ0 cannot be specified.

Some areas in particular cannot be combined and specific data types corresponding to its native type must be specified:

  • Any area having a native type of Bit
  • Any area having to do with Current value, such as:
    • TN
    • LTN
    • STN
    • LSTN
    • CN
    • LCN

String Request Considerations

When specifying a string data type, the length of the string must also be specified on the address. For example, D0 requests a string of up to 10 characters at offset 0 in the data register device.

  • If the length of the string is less than the address string length, it will be padded with null characters. For example, writing “hello” to D is equivalent to writing “hello\0\0\0\0\0” where “\0” are null characters.
  • If the length of the string is more than the address string length, it will be truncated to the address string length. For example, writing “hello world!” to D is equivalent to writing “hello worl”.

For the Q/L series, the string length will be automatically rounded up to the nearest even value. This is because two characters are stored inside a word. For example, D0 will be treated as D0.

Optional Data Types

The following data types are recognized by the driver:

Bool Int16 Int32
Int64 UInt16 UInt16
UInt64 Float Double

If the data type is omitted, a default data type will be used depending on the area’s native type:

Area Native Type Default Data Type
Bit bool
Word int16
Double word int32

Optional Data Type Modifiers

Attribute Order
@BE Big Endian Byte Order
@LE Little Endian Byte Order (default when not specified)
@HL High-Low Word Order (default when not specified)
@LH Low-High Word Order

Optional Arrays

Arrays are a concept created within the driver representing a contiguous range of addresses starting from an offset. Arrays do not exist in the PLC.

For example, instead of reading D0 through D8, you can create an array of the same values. The number of elements in an array are determined by multiplying the array dimensions. So reading D<int16[3, 3]>0 is a length of 3x3 with the start offset is 0 and the last offset is 8.

Similarly, reading an element within an array is equivalent to reading a single address. For example, you can see in the table above that reading D<int16[3, 3]>0[1][2] is equivalent to reading D5.

D[0][0] = D0 D[0][1] = D1 D[0][2] = D2
D[1][0] = D3 D[1][1] = D4 D[1][2] = D5
D[2][0] = D6 D[2][1] = D7 D[2][2] = D8

Large arrays should be used with caution. If an array read/write request is too large to fit into a single request, it will be broken up into multiple non-atomic sequential requests. Splitting requests when writing can result in the first send of the write requests creating new values and the remaining write requests failing. Similarly, if read requests are sent separately the resulting array may contain stale points.

Determining if an array is too large to be sent at the same time on how the array is optimized. Optimization refers to the process of minimizing the number of requests sent to the PLC by batching together device points with the goal to fit as many points as possible into a single request before splitting it off into multiple requests. Request optimization happens automatically when points are read or written to at the same time.

Optional Bit Index

A bit index can be specified on any integer data type to retrieve a boolean value at some bit position. Addresses with a bit index are read-only and any attempts to write to them will result in a Bad_NotSupported error due to the MELSEC protocol not supporting atomic writes to bits within an underlying data type.

A simple example of reading a bit would be D0.0, which reads the bit0 of int16 at offset 0. You can also read bits within array elements that represent scalar values following the same addressing format. To read the bit 0 of element 0 of an array of length 4 at offset 0 would be D<int16[4]>0[0].0

A bit index cannot be specified for the following:

  • Non-integer data types (bool, float, double, and string)
  • Non-scalar addresses (arrays)

GX Works Configuration

GX Works is the programming software designed for Mitsubishi PLCs. Before you can use the Mitsubishi driver, some configurations need to be made in GX Works when connecting to MELSEC-Q/L and iQ-R series devices with the Mitsubishi driver. These instructions are written for GX Works3. GX Works2 has slightly different settings but should in general resemble the following setting requirements.

  1. Under the navigation tab, locate Parameter > CPU > Module Parameter > Basic Settings > Own Node Settings.
  2. Set Enable/Disable Online Change to Enable All (SLMP).
  3. Set Communication Data Code to Binary.
  4. Navigate to External Device Configuration > Detailed Setting to add an SLMP Connection Module to the Ethernet Configuration with Protocol set to TCP.
  5. Make sure to also identify the IP Address and Port No. These settings are what will be used for the Mitsubishi TCP driver Hostname and Port connection fields.
    Note: If multiple connections to the PLC are required, multiple SLMP Connection Modules will need to be defined, each with its own unique Port No.
  6. Write all changes to the PLC (Online > Write to PLC) and initiate a power cycle.

Configuring Device Points

Some areas or offsets within an area may not be accessible by default unless additional memory is allocated.

  1. Navigate to Parameter > CPU > CPU Parameter > Memory Device Setting > Device/Label Memory Area Setting > Detailed Setting.
  2. Change Points to desired size. The point allocation from all areas must not exceed the Total Device size.
  3. Click Apply.
  4. Write to the PLC (Online > Write to PLC) and initiate a power cycle.

Using GX Works3 to Troubleshoot

If you have access to GX Works3, you can use the Device/Buffer Memory Batch Monitor feature to test or troubleshoot your connection. This can be found under Online > Monitor > Device/Buffer Memory Batch Monitor. Type in the device keyword with an offset and hit enter to begin monitoring values.

GX Works also has an Ethernet Diagnostics tool which is useful for determining the status of the connection as well as other information like IP Address, Port No, and Latest Error Code. To access this tool, navigate to Diagnostics > Ethernet Diagnostics.


I don't have anything to test with, but I have to admit concern over some of the above.

First, and most concerning, is the use of "tag path" terminology in a driver. Everywhere else in Ignition, a "tag path" refers to the hierarchy in a tag provider, not in a driver. Drivers have OPC "item paths". This clash of terminology will end in confusion and grief.

Second, you have to "Import a CSV" and/or have to configure specific addresses and ranges, yielding new names, to have browsable items. Just like the Modbus driver. Utterly annoying and difficult to maintain. A default configuration that exposes the maximum size of each memory area, and makes those browsable, is much easier for both integrators and end users to deal with. Making the browse ranges optionally adjustable makes sense.


100% agreement here. OPC UA drivers expose opc items.

Yeah, modeling the addressing off the Modbus driver seems like a poor choice.

I'll be honest, I have no idea what the use case is for address mapping. What's the advantage of abstracting away the PLC address with an arbitrary item name? It's just double data entry with no real gain.

Being able to click and navigate through all potentially available memory areas in the OPC item browser makes much more sense. Keep it simple.

That being said, I'm very excited to give this a shot.

1 Like

I tend to agree with this, and our Modbus driver address mapping is especially broken compared to others.

CSV import/export is primarily in response to a demand for "CSV support" from users. The Ignition tag import/export format is complicated. The CSV import used by FINS, Mitsubishi, and a couple other drivers is just 3 columns in a CSV file that you can pretty easily create and manage as a lay-user.

I don't love it, but it's just a response to something we saw a lot of requests for.

The Mitsubishi driver is also going to support import of whatever CSV or TSV file that GX Works can export, which means you'll get the name-to-address translation being used in the program for basically no work, which I think is a bit of a win. I don't know if this is implemented yet, though...

We're going to be changing the "Tag Path" terminology on that page and any others like it. I don't know how that made it's way in. It needs to be something like "Name", "Browse Name", or "Browse Path" (open to suggestions - the tricky part about naming it is you can put just a name or a path, where the last component becomes the Node's browse name).

I don't like the "Item Path" terminology, it's a holdover from when only OPC Classic existed and it's not a term that is used by OPC UA.


Does this mean it's optional, like the Modbus mappings are optional? The text above is unclear.

I'd be perfectly happy to see "Node Id" replace "Item Path" everywhere. My concern is was with the overload on "Tag".

Yes, totally optional. Just create tags that have a NodeId (OPC Item Path) with the syntax described in the docs.

Yeah, “Tag” was a mistake. I’d like to replace “OPC Item Path” up in Ignition but OPC tags are still for both OPC Classic and OPC UA… and OPC Classic doesn’t have NodeIds… Maybe some day we can stop pretending there’s more than 2 kinds of “OPC” and instead of trying to cover both with one kind of tag we can just have OPC Classic and OPC UA tags.


Ok. But still annoying to not be able to browse the well-defined linear address space.

1 Like

I might actually agree with you on this driver, but only because I don’t have enough experience to know how these memory layouts are used. If people stick to the “native” DataType of each memory area and don’t combine them into multi-“word” types, sure, it would be useful. But GX works seems to have support built in for viewing and manipulating these areas with larger/combined types… so I don’t know yet. Hoping for feedback from real users in the beta on that one.

I think what you did in your Modbus driver is a neat trick but don’t have any desire to implement it in ours. You can really only enumerate the default type for each area, and nearly every real world use of Modbus I’ve seen uses multi-register types, at who knows what alignment within the memory. Plus, no offense, if yours was deployed on anywhere near the scale ours was I guarantee you’d field non-stop support emails/calls from people who dragged the whole folder in and now wonder why nothing works.

Did you notice my driver offers the multi-word types in the node with the "plain" register? So, you literally just drill in one layer further to get the other types (or bits of registers).

Not offended. :grin:

I even thought of that. It is one of the reasons I include more descriptive information in my browse tree--that extra information, by itself, will mess with the heads of deter mass drag-and-drop fiends. (Fiends!!)


Yes, fiends indeed.

Back to the whole import / tag list thing, another pain point is that in all of these implementations we end up fielding support calls from users who think they are assembling some kind of tag polling list, not just creating a browse model. This confusion seems especially common with DNP3 users.

I've not had to work with DNP3 devices yet, or their users. I suppose I can wait.

Consider making such browse models actually deliver the underlying (nonmapped) node id when obtained from OPC browse, whether by copying the item path from the tree, or via drag-n-drop. This would make the browse functionality more obvious, and would also make the resulting tags functional without the mapping in place. You'd probably want to still perform the transform for any item paths entered by hand (or in a UDT), naturally. (And for backward compatibility.)

All drivers except Modbus do this. That the Modbus driver maps/aliases the NodeId as well was a huge mistake.

1 Like

First, thank you for completing this. I'm sure our sales rep is jumping for joy knowing my monthly emails regarding this driver will stop after several years of harassment.

I'm curious about a few items listed and will be interested in how the driver mapping will work in an actual production environment. We have some very interesting memory mappings regarding arrays and UDTs. We also use a lot of "bit of word" situations as option flags in recipes (R memory arrays) that we will need to figure out a way to deal with cleanly.

A few points of interest:

The Q/L series requires a specific project type to support array tags, but all GXW3 supported PLCs (iQ-R / iQ-F) inherently support arrays as tags. While they are simply just linear groups of memory, they are certainly valid PLC tags. I can provide examples of this used on production systems, including the Kepware dynamic tag config in IGN.

The protocol definition doesn't have anything specific to arrays and doesn't care how you assemble the basic memory blocks. As they are linear groups of memory and the protocol supports linear group memory read and writes, it technically supports arrays, at least at a basic protocol level. It is up to the application or the protocol driver to assemble and provide those memory groups as array tags per the application requirements.

GXW2 Int Array:

GXW2 even supports structured type arrays (RECIPE is a structured, user defined type, containing bits, ints, floats, and strings):

Are you sure this is correct? We commonly configure several "open settings" to use the same port so that the PLC supports multiple incoming connections on the same port. This allows us to use various software systems to connect to the PLCs for different purposes. Especially before IGN, we would have report printing, MES, and line status display software (TVs, etc...) all reading data from the PLCs on the same ports at the same time.

Here is the port config of a working system doing just that (Q13UDVCPU, structured):

This system is old (10+yrs) but it is currently connected to Kepware/IGN, Cognex cameras, an old Telit MES system, and a JAVA report printing software that just won't die. All of those on port 10000.


Thanks for your feedback!

Yeah, I think this just needs to be rewritten to just explain that arrays are contiguous blocks of memory. I think what was trying to be conveyed at the time was mixing up tag-based PLCs like Logix and even arrays as a concept in OPC UA, where they are more atomic.

Regardless, the driver can address both scalar and array tags. Unfortunately array support in Ignition's tag system itself remains... wanting.

Sheesh, thank you. We couldn't believe this limitation and were even told explicitly by Mitsubishi support that you needed one connection configured per client, but they failed to explain that you can use the same port over multiple connections...


Okay, this may be a little too nitty gritty protocol, but in case some of ya'll know...

We're using Frame4E with iQ-R and iQ-F devices, as opposed to Frame3E, and the only difference is the addition of a "serial number" field, aka a sequence number. In my mind this should allow for concurrent requests, however from what we've seen, even though 4E has this extra sequence number, none of our devices can handle receiving a 2nd request while a 1st is still outstanding.

Does this track with your experience?

I've had the same issue with no resolution. Everything else seems to work correctly in our custom built drivers so I don't think we have a formatting issue and we were able to set the SEQ# to anything we wanted and it responded back, but we could not send more than one MSG without waiting a specific amount of time for assumed failure (wire disconnect testing). Your experience matches ours.

We still use 4E so we can verify SEND/RECV pairing and add it to the logs. I can't think of an instance it didn't work like it was supposed to, so in reality all I'm doing is taking up HD log space.

Also, my driver testing was on iQ and L series, not sure it matters, but worth noting. We've used it on iQ-R but it worked so we didn't change anything which means it didn't try parallel MSGs. Almost all were PLC built in ports, didn't see any change using ETH cards but only tried once or twice. My understanding is that it should act the same (L/Q/R), which to me meant it was still "broken" on the R based on how I thought it should work. Assuming my thoughts match the person who wrote the spec.


I'll also say that as far as performance, we've never had an issue with our requirements verses data rates with any MEAU PLC, so the parallel MSG issue was never an engineering issue that absolutely needed a solution. It was more of an annoyance back when I cared about our drivers being fully functional and optimized. Everything we do is purpose/project/solution driven. Your situation is probably a bit different.


@pturmel @bmusson @christianrauh thank you very much for your participation! Your continued feedback is greatly appreciated. Please reach out directly if you are not getting resolution here. I'd love to hear about all aspects of your experience (process, success, bugs/features/issues, recommendations, etc). I can help with the following:

  1. Loop in appropriate stakeholders within IA (developers, QA, documentation, etc)
  2. Drive internal tickets as needed. Represent your concerns.
  3. Ensure that documentation updates make sense
  4. Process improvement for how we run future Beta programs based on your feedback
1 Like