Features, discussions, tips, tricks, questions, problems and feedback

Mitsubishi Electric Ethernet Communications

How to Troubleshoot Mitsubishi Ethernet Communications.pdf (367.3 KB)


Driver communications on ethernet requires a TCP/IP Socket connection which means we must be able to access a certain IP Address on a specified TCP port. This is no different when communicating to the Mitsubishi PLC range. The IP Address and TCP port needs to be configured for each CPU or ethernet module accordingly in the PLC software like GX Works2 or GX Works3. Communications to the PLC is through a SLMP connection and the drivers makes use of the 3E Frames protocol. Depending on the CPU type you can have up to 16 connections configured where at least 1 should be for a MELSOFT connection such that you have access to program and debug your program through GX Works2 or GX Works3 and the rest could be used for SLMP connections. Our driver document does show how to configure these connections.

So, what happens when the connections are created and PLC is setup and there are communications problems? Let’s look at possible scenarios.

What if you have a driver problem. For example, you look at the driver status and see it is red as in below image from the Adroit/MAPS Config Editor.


Driver Statuses:

image Driver is not loaded or used, as in the agent server is not running or the agent server is running and the device is created but not yet instantiated or scanned too inside your project.

image Device communications are healthy and running and there are no problems.

image Device is scan bad which could point to many reasons like the device is not started and therefore no communications, or the device is started but cannot create a connection or the device is started but just 1 scan point is bad due to an invalid address being used, hence the red does not point to a communication problem with the PLC always, and could point to invalid or bad scanning addresses or even just bad networking causing failures on some scan tasks.

Troubleshooting a image Driver problem.

Ensure connections is correctly configured in the PLC.

Using the driver document ensure the SLMP (MC Protocol) connections is correctly configured and downloaded to the PLC. A plc reboot might be required for the change to take effect.

Can you ping the PLC’s IP Address?

Using the driver dialog, you can use the ping test to ensure the driver can actually ping the PLC on the IP Address specified.

Can you access the SLMP Port (MC Protocol) configured?

For the driver to function correctly it need to be able to access the IP and the port specified, so being able to ping it does not tell you that a connection is possible, the driver also need to be able to open the port. Some reasons why this is could not be possible is that the port could already be open by some other application. in the case of Mitsubishi, it allows a port to be opened only once and port sharing is not possible, so if you require more ports to be opened for example in the case of a cluster system then you need to create multiple SLMP (MC Protocol) ports. You can make use of GX Works2 or GX Works3 functionality to check if a port is opened and what application has opened it.

Is there any firewall prohibiting the TCP/IP connection?

Ensure all firewalls are configured to allow the specified port to be connected too or disable the firewall just to confirm and then enable it again with the specified rule applied to allow traffic through.

Troubleshoot connection problems

When you get to this point, we need to make use of the driver tools like the Driver Monitor launcher to tell us what the driver is trying to do. Follow the steps below to open the driver monitor launcher.

  • Open the Adroit/MAPS Config Editor and select the “Agent Server Configuration” section, then select the “Driver Configuration” section as shown below.
  • Expand the Mitsubishi Etherent Driver and select your device that you have problems with, then select the “Datascope” button to your bottom right.
  • The datascope will open as below and show you lots of information like connection attem-ts and scan tasks it is performing as well as the actual protocol messages being transferred between the driver and the PLC.

If the datascope gives a message that it cannot connect then its time to play with the driver settings. When it comes to driver settings, all of them have a timeout setting in milliseconds. When it comes to creating a socket connection the driver will try and create a connection within a dedicated timeout and in most cases this timeout setting in the driver is used to establish a connection and if a connection cannot be established within that time it fails. In the case of Mitsubishi and more specifically the on-board ethernet CPU’s there is no timeout settings on the PLC side as in the case of the ethernet module. See image below.

This does sometimes cause a connection to take up to 15 seconds. For this reason, we especially created a separate timeout for the Mitsubishi drivers that we use as a connection timeout. In the 1st generation driver, the connection timeout is hard coded to use the timeout setting with a multiplier of 10, which means a timeout setting in the driver of 1500ms will allow for a 15 seconds connection timeout.

For the 2nd generation driver, we have separate setting one for the timeout and 1 for the connection timeout.

Troubleshooting Communication problems

We have now established it is not a connection problem but more a communication problem which could be anything from bad address or scan job to bad networks or CPU not able to process the driver requests in specified timeout. Let’s look at these individually.

Bad scan address

In the scenario of scanning an address to the PLC that is not available in the PLC that specific address or scan task that address belongs too is marked bad and as such your device is also bad. You can always use the scanning monitor to show you which tags is bad.

In the Adroit/MAPS Config Editor you can go to the “Agent Server Configuration” and then select the “Driver Configuration”. Select the device for the driver that has the problem and in the bottom right-hand corner is a button called “Scanning Monitor”. Launching this utility allows you to see all the devices and its associated tags scanned to it with all the status accordingly. See below.
In this specific case I have communication to the PLC but I have scanned an address that does not reside inside the PLC as in R2000 and the status is shown by the “Scan bad” column and my D0 address is not scan bad but my R20000 scan address is scan bad and is hence the cause of my device being not healthy.

Bad scan task

To resolve a bad scan task, it is important to understand how the driver builds these tasks. When it comes to optimizing the scanning to the PLC the driver uses a setting called PDU (Protocol Data unit) length which tells the driver the maximum size of data to be requested from the PLC in a single transaction.

If you have a PDU setting of 255 it relates to the driver to request a maximum of 255 bytes of data from the PLC in a single transaction. The driver can also only request the same device types and in sequential order data within a single transaction. As an example, if I scan D0 the driver will create a scan task to fetch 2 bytes of data from the PLC. If I now scan R0 the driver will create another scan task seeing that R and D device types is different and cannot live within the same scan task. If I know scan D120 the driver will see that the D120 can live within the same scan task as D0 and will because it is of the same device type and still within our PDU limit of 255 bytes as all the data bytes from D0 to D120 will be returned and that amounts to a total byte size of 240. If I know scan D130, the driver will create a new scan task specifically for D130 as it cannot live within the same scan task as D0 and D120 or R0 for that matter.

A scan task can fail for 2 reasons, firstly s bad scan address as explained in the previous section which forms part of a scan task that has good addresses in them, for example if I scan R19900 which is a good register in my PLC and I then scan R20000 which is a bad register in my PLC they will live in the same scan task but because I requested R20000 as part of my transaction it will fail the complete scan task.

Secondly you could be asking for too many bytes in a single request as in the PDU setting is too high for the CPU used. Depending on the CPU in use the maximum PDU length could differ and for example if you specify a maximum PDU higher than the CPU can accept then you might be requesting a scan task with too many data bytes and the PLC will respond with an error.

Network or PLC related problems

In many cases communication could fail due to the response from the PLC taking longer than the set timeout setting of the driver. Increasing the timeout setting will then improve communications but at a cost of not retrieving the data at the scan rate required. So, what causes these delays?

If you have a bad network or extremely busy network, it could cause these delays. By just performing a big 64K packet ping in the command prompt to the PLC will quickly tell you how the network is performing. To fix network issues will require IT department to get involved and investigate.

If the network is fine, then the delay could be on the PLC side. In many cases PLC projects grows to such a state that there is little or no time to process the actual requests from the driver. Below are some PLC related actions you can follow to resolve these issues.

Optimising the PLC for communications

In the PLC the program scan is made up of serial functions.

After an Initialising routine the scan becomes a process of:

  1. Refreshing the IO

  2. Executing the PLC program

  3. End Processing

This process is shown below.

The PLC scan time is the time it takes to process all the above functions.

With small PLC programs the majority of the PLC’s processor time is taken

up refreshing the I/O and the end processing. However, as the program

becomes larger more time is spent running the program and less time is given

to I/O refreshing and end processing.

When the driver requests data from the PLC, the PLC queues the

messages and replies to them during the END processing. This is the same

process if the messages are coming in via the programming port

RS232/RS485 card or Ethernet card to name just a few.

The more cards and the more MC protocol connection nodes communicating to the PLC

the more the messages are queued.

END processing consists of:

This is a post-processing to return the sequence program execution to step 0

after completing the whole sequence program operation processing once.

• MELSECNET/H or CC-Link refreshes processing

• Automatic refresh of intelligent function module

• Self-diagnostics

• Communication with external device such as GX Developer HMI/SCADA

• Processing of intelligent function module dedicated instruction (Completion

processing only)

With short scan times (below 25ms) this does not cause any issues. However

as the scan time approaches 100ms and as the number of nodes increases the more visible the communications delays become.

To get around this problem there is a dedicated instruction called ‘COM’.

When this instruction is executed, the PLC does a mid-scan ‘END process’

The more ‘COM’ instructions used the more ‘end process’ which in turn

increases the PLC scan time.

The best results have been found when a ‘COM’ instruction has been added

about every 25ms of scan.


When it comes to ethernet communications it is still the best preferred method to make use of an external ethernet module instead of the onboard CPU’s Ethernet module for driver communications for a few reasons of which one is that it has the ability to modify the timeouts on the external card that will allow you to specify values that will close the port for communications quicker in the case of network loss, whereas in the case of the onboard ethernet module you will have to wait 10 minutes and this timing is not adjustable.