Skip to main content

Understanding Mitsubishi PLCs

David Fogle
  • Updated

Introduction

Mitsubishi Electric is considered to be Asia’s leading manufacturer for programmable controllers in PLC markets. For this reason, providing support for these brands of PLCs brings a significant improvement to the flexibility of the Ignition platform.  

 

Mitsubishi PLCs are formally referred to as MELSEC Programmable Controllers since MELSEC is the name of Mitsubishi’s proprietary communication protocol. MELSEC Communication, or MC, operates by passing frames of data between an external machine (e.g. Ignition server) and a Mitsubishi controller’s modules, primarily the CPU module.

 

MELSEC Control Procedure 

In the simplest terms, we can describe the MC protocol messaging process as follows:

  1. The external machine sends a request to the MC-supported controller. 
  2. The controller unpacks this as a read or write request to send to its CPU module.
  3. The CPU module then processes a result to send back to the controller.
  4. The controller packages a result to send back to the external machine.

 

In order to package the data of these requests and responses to MC standards, both sides of the communication need to adhere to specific message formats called frames. 

 

A frame is a structure type for a message following MC protocol standards. In its most atomic state, a message consists of a long sequence of binary values. The sequences are understood by the controller since it recognizes subsequences as the header, subheader, request data, etc. after translating them into readable hexadecimal values.

 

Different series of MC-supported controllers come with their own unique frame structure for communication. However, since the Ignition driver (as of 8.1.28) only focuses on ethernet-based messaging, the important frame types you’ll need to know are 3E and 4E. These two frame types are part of a messaging format within MC protocol known as SLMP ( details on this term are provided in the next section).

 

A few points to keep in mind regarding the diagram above include:

  • All 4 character values suffixed with the trailing “H” indicate a hexadecimal representation of the 2-byte long, binary values within the frame’s fields (e.g. 5000H = 10100000 00000000).
  • The subheader field can contain different values based on frame and message type:
    • A 3E type will contain a fixed 2-byte value of 5000H to indicate a request message or D000H to indicate a response message.
    • A 4E will contain a 6-byte value consisting of a fixed 5400H (request) / D400H (response) header,  a 2-byte long serial number, and a trailing 0000H to end this field’s section.

 

SLMP 

SLMP stands for Seamless Messaging Protocol, a standard format within MC protocol that’s focused on ethernet-based messaging against a Mitsubishi controller’s ethernet module. This format provides the highest range of access within an ethernet-based network of MC-supported controllers when compared to other formats. 

 

Range of access refers to the ability for an external device (e.g. Ignition) to reach out to other stations beyond the host station of MC-connected networks. If you refer to the 3E/4E message diagram above, the Access Route field would be responsible for providing a host station unique identifiers to a different station it is connected to. However, as of 8.1.28, the Mitsubishi driver only supports direct connections to host stations. This means that Access Route fields will be given fixed values during request and cannot be modified by the user. This also means that requests will be limited to data from host stations only, unless a separate IP address is defined for a separate device connection.

 

See the following list for what Mitsubishi hardware types are supported by the accepted SLMP formats:

  • 4E frame types:
    • iQ-R
    • iQ-F (FX5U)
  • 3E frame types:
    • Q
    • L

 

In the SLMP frame structure, the request and response data field will contain the information needed for reading and writing data. Requests will contain command codes, which vary depending on the type of item being accessed and whether the operation being carried out is a single read, a block read, single write, block write, etc. 

 

A Note on MELSEC-F Series Support

8.1.31 introduced support for the MELSEC-F Series PLCs where SLMP frame structures are not used for communication. Instead of the 3E/4E frames described above, MELSEC-F support involves the 1E frame structure which is very similar. Differences can be found in the Subheader field, where neither an additional Serial Number or Fixed Value will be added. Access Route fields will also omit any identifiers pointing to targets beyond a host station. This is because 1E frames are used for clients communicating with host stations directly only.

 

A Note on Supported Command Types

The Mitsubishi driver (as of 8.1.28) focuses on commands that apply to Device item types only.  Other item types mentioned in MELSEC documentation such as Label, Memory, Extended Unit, etc. will not be supported. You can also refer to these accessible Device Items as Areas. In the user manual, potentially accessible Areas of the Ignition-supported MC controllers are listed for making requests.

 

The Ignition Mitsubishi driver

Since SLMP is only possible through ethernet, the Ignition Mitsubishi driver will only support TCP connections between Ignition’s OPC UA and an MC controller’s Ethernet module. Once a TCP connection is established, SLMP requests will then be possible. 

 

The common methods for passing appropriate commands into SLMP requests with Ignition:

  1. Create Ignition tag subscriptions with unique, manually-specified syntax in the OPC Item Path field. 
  2. Define scripts system.opc.readValue() or system.opc.writeValue() using the same manually-specified syntax as method 1.
  3. Create tag subscriptions against browsable, defined addresses rows on the device connection.

 

Details for both the syntax and address row configuration are provided in the user manual. Unlike some other device drivers you are familiar with (e.g. Allen Bradley), OPC items for these devices are not automatically provided for a browsable, “drag and drop” solution to your Tag Browser due to the nature of the protocol. Initial TCP connections to these types of devices do not provide any information about what can be subscribed to, which is why you are required to request data from a specific address using prior knowledge of accessible areas. Such knowledge of accessible device areas will only be possible by referring to the controller’s programming software.

 

GXWorks3

GXWorks3 is a programming software meant for the monitoring and configuration of MC controllers. Any active MC controllers in the field should have an existing GXWorks program configured in order to provide information about points that can be subscribed to in Ignition. 

 

Note: There are users who may still be using the predecessor software GXWorks2. Snapshots and configuration paths mentioned below come from GXWorks3 and may be slightly different in comparison. 

 

Connecting with Ignition

If this is your first time establishing a TCP connection between the Mitsubishi driver and MC-supported controller, then the following configuration changes must be made in GXWorks. The following settings below ensure the Mitsubishi driver’s supported frames will be accepted by the device.

Under the navigation tab,  locate Parameter > CPU > Module Parameter > Basic Settings > Own Node Settings

  • The Enable/Disable Online Change setting must be set to Enable All (SLMP).
  • The Communication Data Code setting must be set to Binary.

Under the navigation tab,  locate Parameter > CPU > Module Parameter > Basic Settings > Own Node Settings > External Device Configuration > Detailed Setting

  • An SLMP Connection Module must be added to the Ethernet Configuration with Protocol set to TCP. The IP Address and Port No., which will be used for the Hostname and Port settings in the Ignition Mitsubishi Driver, must also be specified. If multiple connections to the PLC are required, multiple SLMP Connection Modules will need to be defined.

Note: Any changes made above will require writing to the PLC (Online > Write to PLC) and a power cycle before taking effect.

 

Configuring Device Points

Areas or offsets within a device may require additional memory allocations before being accessed. In order to configure memory allocations for device areas:

  1. Navigate to Parameter > CPU > CPU Parameter > Memory Device Setting > Device/Label Memory Area Setting > Detailed Setting.

 

  1. Change Points to desired size. The point allocation from all areas must not exceed the Total Device size.
  2. Click on Apply.
  3. Write to the PLC (Online > Write to PLC).

Note: If an area and their offsets have a value of 0, then that means there are no accessible device areas of that type. For example, the snapshot below shows the scenario of three device areas: Step Relays (S), Retentive Timer (ST), and Long Retentive Timer (LST) with 0 point allocations.

Ignition tag subscriptions to these device areas without the proper point allocations will result in a failed request.

 

Monitoring Device Points

Device points can be read or written to in real time via the Device/Buffer Memory Batch Monitor which can be useful for troubleshooting. This can be found under Online > Monitor > Device/Buffer Memory Batch Monitor.

Type in the device keyword and an offset and hit enter to begin monitoring values. For example, type D0 to see live values for the Data Register device starting at offset 0. Any device keywords ending in “S”, “C”, or “N” are part of a timer or counter. To monitor them, type the device keyword and omit the last character and then add the offset to monitor the encapsulating area they are part of. For example, type LT0 to see values for LTS, LTC, or LTN.

Click on the button labeled Open Display format to view settings for changing the format of the data.

 

Diagnosing Connectivity

GXWorks has an Ethernet Diagnostics tool which is useful for determining the status of the connection as well as other information including incoming IP address/port, last error code, etc. To access this tool, navigate to Diagnostics > Ethernet Diagnostics.



Requesting from Device Areas

Now that you have confirmation of known accessible areas within the MC controller, you can start subscribing to specific points of the connected device.  The user manual contains complete details on how to format MC command codes to fit the Mitsubishi driver’s accepted syntax.

 

The driver’s address syntax consists of the following components:

  • area
  • data type (optional)
  • array specifier on data type (requires data type to be specified; optional)
  • data type attributes via @ syntax after data type or array specifier (requires data type to be specified; optional)
  • offset
  • array element index (optional)
  • bit index (optional)

The user manual lists details on all possible options for each component listed above, as well as caveats on the behavior of some component options.

 

Request Optimization

Request optimization refers to the process of minimizing the number of requests sent to the PLC by batching together device points. Most types of requests sent to the PLC can read/write a contiguous range of data instead of reading/writing a single point at a time. Thus, the goal of optimization is 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. In most cases, points will be optimized together when:

Reads:

  • Points are subscribed or polling under the same tag group. 
  • Points are read together via system.opc.readValues().

Writes:

  • Points are written together via system.tag.writeAsync().
  • Points are written together via system.opc.writeValues().

Note: For subscriptions, request optimization only occurs once at the start of the subscription and is only performed again if a new point is added or removed. This is because the Mitsubishi driver caches optimized requests since there is no point in constantly re-optimizing the same set of points.

For the Mitsubishi driver, the general procedure for request optimization is as follows: 

  1. Group requested points by area.
  2. For each group of points, divide points into sublists spanning a continuous range based on the specified Max Gap Size and the Max Device Point Size.
  3. Create an optimized request for each sublist.

 

Max Gap Size

The Max Gap Size refers to the maximum address “gap” to span when optimizing requests to contiguous address locations. This is a configurable property that can be found from the main device connection page. The default gap size is 0.

 

 

Typically, increasing the max gap size will reduce the number of requests but increase the amount of data requested. Max Gap Size is not used for write request optimization.

 

Consider a subscription with the following addresses: 

 

  • D0
  • D1
  • D10
  • D50

 

Suppose the Max Gap Size is set to 0, then the addresses would be optimized into requests with the following range:

  • D0-D1
  • D10 (this is its own request because the gap between D10 and D1 is greater than 1)
  • D50 (this is its own request because the gap between D50 and D10 is greater than 1)

 

Now suppose the Max Gap Size is set to 100, then the addresses would be optimized into a single request with the following range:

  • D0-D50 (this is a single request because all address offsets are within 101 of each other)



In the above scenario, when Max Gap Size is set to 0, three requests are sent and three responses, relatively small in size, are received. When the Max Gap Size is set to 100, only a single request is sent and a single response, relatively larger in size, is received.

 

Max Device Point Sizes

The maximum number of device points that can fit into a single request depends on the type of request being sent which is dependent on the area’s native type and data type. If the number of points-to-be-optimized exceeds the maximum number of device points for a request, device points will be broken up into multiple requests. The Mitsubishi driver uses five types of requests:

  • Batch Read in Word Units
  • Random Read in Word Units
  • Batch Write in Word Units
  • Random Write in Word Units
  • Random Write in Bit Units

Batch Read in Word Units Request

This request is used for reading all areas.

Examples:

  • D0…D959 would be optimized into a single request. D0…D960 would be optimized into two requests.
  • D<int32>0…D<int32>479 would be optimized into a single request.
  • D<int32>0…D<int32>480 would be optimized into two requests. 
    • While a Data Register (D) is a word device which has a maximum of 960 points for this request, specifying an int32 combines two words together into a single value, so, the maximum number of contiguous D<int32> points is 480 points.
  • M0…M15359 would be optimized into a single request. M0…M15360 would be optimized into two requests.
  • Below is a diagram for request and response data for a “batch read in word units” command from the Mitsubishi MELSEC Communication Protocol specification:

In the above diagram, a contiguous range of TN points is read. In the request data, the “Head Device Number” refers to the starting offset and the “Number of Device Points” is the number of points to be read from the starting offset. With a Head Device Number of 100 and a Number of Device Points of 3, the values for TN100, TN101, and TN102 are returned in the response data as shown. Examples of items that would have been optimized into this request:

  • TN100, TN101, TN102
  • TN100 and TN102 with a Max Gap Size >= 1

 

Random Read in Word Units Request

This request is used for writing to LCN and LZ for iQ-F series devices.

 

Batch Write in Word Units Request

This request is used for writing to all areas except for the following:

 

Random Write in Word Units Request

This request is used for writing to LTN and LSTN.

Note: Subcommand 0002 is used for the MELSEC iQ-R series and subcommand 0000 is used for the MELSEC Q/L series.

This request allows a mix of both words and double words, but since request optimization groups by area, a request will contain only word points or double word points. To make calculations simpler, the Mitsubishi driver uses the maximum number of double word points as the upper bound. The adjusted maximum point size regardless of whether the area is a word or double word native type is as follows:

  • iQ-R: 68
  • Q/L: 137

 

Random Write in Bit Units Request

This request is used for writing to any area with a native type of Bit (see Areas (Devices) section for more details).

Note: Subcommand 0003 is used for the MELSEC iQ-R series and subcommand 0001 is used for the MELSEC Q/L series.

 

Troubleshooting Guidelines / Additional Notes

Important Considerations

  • As of 8.1.28
    • The driver supports 3E and 4E frame types only.
    • The driver supports direct connections to host stations only.
    • The driver supports commands that apply to Device item types only.
  • If you are connecting the PLC for the first time, refer to the section Connecting with Ignition or the User Manual to ensure the Mitsubishi driver’s supported frames will be accepted by the device.
  • As of 8.1.31
    • The driver supports the 1E frame type.
      • This frame type is meant for MELSEC-F series where it is structured to communicate with host stations only.
      • This frame type is similar to 3E/4E structures except it omits unique identifiers from it's Subheader and Access Route fields.

Mitsubishi Loggers

The following are gateway loggers that need to be set to DEBUG or TRACE when troubleshooting.

Connectivity

  • com.inductiveautomation.ignition.drivers.mitsubishi.MitsubishiTcpDevice
  • com.inductiveautomation.ignition.drivers.mitsubishi.melsec
    • com.inductiveautomation.ignition.drivers.mitsubishi.melsec.ChannelFsm
    • com.inductiveautomation.ignition.drivers.mitsubishi.melsec.Melsec4EClient

Addressing

  • com.inductiveautomation.ignition.drivers.mitsubishi.address.MitsubishiAddress
  • com.inductiveautomation.ignition.drivers.mitsubishi.opcua.DeviceAddressSpace

Requests

  • drivers.mitsubishi.Requests
    • drivers.mitsubishi.Requests.BatchReadWordRequest
    • drivers.mitsubishi.Requests.BatchWriteBitRequest
    • drivers.mitsubishi.Requests.BatchWriteWordRequest
    • drivers.mitsubishi.Requests.ErrorReadRequest
    • drivers.mitsubishi.Requests.ErrorWriteRequest
    • drivers.mitsubishi.Requests.LargeArrayReadRequest
    • drivers.mitsubishi.Requests.LargeArrayWriteRequest
    • drivers.mitsubishi.Requests.RandomWriteBitRequest
    • drivers.mitsubishi.Requests.RandomWriteWordRequest
  • com.inductiveautomation.ignition.drivers.mitsubishi.requests
    • com.inductiveautomation.ignition.drivers.mitsubishi.requests.ReadOptimizer
    • com.inductiveautomation.ignition.drivers.mitsubishi.requests.WriteOptimizer

References

 
Was this article helpful?
0 out of 0 found this helpful
Return to top

Comments

0 comments

Article is closed for comments.

This article has 0 comments.

Powered by Zendesk