Mitsubishi QJ71E71-100 - MC Protocol (Binary) Always Returning the Same Response(Python)

[PLC_baby]

Hello everyone, I hope you're doing well.

1. System Overview

I am working with a Mitsubishi QJ71E71-100 Ethernet module and trying to establish communication using MC Protocol (Binary Mode) over UDP. My goal is to retrieve real-time data from a Q13UDEHCPU PLC and display it on a dashboard.

2. Current Network Setup

• PLC Model: QJ71E71-100
• CPU: Q13UDEHCPU
• Communication Mode: MC Protocol (Binary/ASCII Mode) over UDP
• PLC IP: 192.168.22.51
• PLC Port: 7000
• PC IP: 192.168.22.100
• PC Port (Listening for response): 9600

3. Current PLC Ethernet Settings

• Protocol: UDP
• Fixed Buffer Communication: Procedure Exist
• Pairing Open: Enable
• Existence Confirmation: Confirm
• Communication Data Code: Binary
• Initial Timing: Always wait for OPEN
• TCP Existence Confirmation Setting: Use the KeepAlive

4. Issue Description

I have tried communicating with the PLC using both MC Protocol Binary Mode and ASCII Mode, but the response is always the same, regardless of the register I request.

I attempted reading from D12001, D12002, and other D-registers, but the response remains unchanged.
Additionally, I have received different response values (44303534 and 43303534), but the content of the data does not change.

5. Packet Details

Below is the request packet I am sending:

request_packet = struct.pack(
    "<4B H H H 3B B H",  
    0x50, 0x00,  # Subheader (2B)
    0x00, 0xFF,  # Network Number & PLC Number (2B)
    0x0C, 0x00,  # Request Length (2B)
    0x01, 0x04,  # Command Code (Read Word Device - 0x0401)
    0x00, 0x00,  # Subcommand (2B)
    0x01, 0x20, 0xA8,  # Start Address (D12001 - 3B)
    0x01  # Number of Words to Read (1B)
)

When I send this request, Wireshark captures the correct packet format, but the PLC's response is always the same, regardless of the requested register.

 

6. Response from PLC (Always the same)

• Raw Response (HEX): 44303534 or 43303534
• ASCII Interpretation: "D054" or "C054"

I have also tried sending the request in ASCII mode, but the response remains the same.
Regardless of whether I use Binary or ASCII communication, the PLC does not return the expected register value.

 

7. Steps Taken & Debugging So Far

1. Verified that MC Protocol (Binary) is enabled on the PLC.
2. Tried switching between ASCII and Binary Mode, but the response does not change.
3. Ensured that the Ethernet settings match the MC Protocol requirements (Binary Mode, Procedure Exist, Pairing Open: Enable, etc.).
4. Tested different D-registers (D12001, D12002, etc.) but always receive the same response.
5. Checked Wireshark logs to confirm the correct packet is being sent.

 

8. Questions & Request for Help

1. Why is the PLC always returning the same response (44303534 or 43303534)?
2. Is there an additional setting required to enable proper MC Protocol Binary/ASCII communication?
3. Is it possible that the PLC is still using a Fixed Buffer communication mode instead of MC Protocol?
4. What additional debugging steps should I take?

Any insights or suggestions would be greatly appreciated!

I am not very familiar with English, so I used ChatGPT to write this post. Thank you for your understanding. 😊

[sczot]

Hi,
I have no experience trying to connect Qplc to PC with Python, but your response looks like an error.

bellow is part of "Q Corresponding Ethernet Interface Module User's Manual (Basic)"

C054H
The number of read/write points is outside the allowable
range.
• Correct the number of read/write points and send the data to the
Ethernet module again.

[SergeyBorchshev]

Hello,

I think your mistake coming from how you format your message. 

request_packet = struct.pack(

"<4B H H H 3B B H",

0x50, 0x00, # Subheader (2B)

0x00, 0xFF, # Network Number & PLC Number (2B)

0x0C, 0x00, # Request Length (2B)

0x01, 0x04, # Command Code (Read Word Device - 0x0401)

0x00, 0x00, # Subcommand (2B)

0x01, 0x20, 0xA8, # Start Address (D12001 - 3B) - these should be 3B for head device number only so your 12001 should look like this 0x2E, 0xE1, 0x00

0xA8, #Device code (D in binary message is A8 - 1B)

0x01, 0x00 # Number of Points to Read (2B) )

 

Try to format this way and see what is coming back.

[SergeyBorchshev]

IN ASCII Device code first, than device number, then amount of points.

But in binary - Device number, device code, number of points...

[kitter]

In the case of binary communication, the packet should look like the following, but isn’t it missing some parts?

I particularly feel there might be an error in the Request Length.

For reference, here is a packet example to read 6 points from D0 on a Q03UDE:

0x50, 0x00,                     // Sub Header
0x00, 0xFF, 0xFF, 0x03, 0x00,   // Route
0x0C, 0x00,                     // Request Length
0x00, 0x00,                     // Monitoring Timer
0x01, 0x04, 0x00, 0x00,         // Command
0x00, 0x00, 0x00,               // Device Address
0xA8,                           // Device Prefix
0x06, 0x00                      // Device Length

Also, it seems there is an MC Protocol library available on GitHub — why not take a look for reference?

https://github.com/YudaiKitamura/McpX

[SergeyBorchshev]

4 hours ago, kitter said:

In the case of binary communication, the packet should look like the following, but isn’t it missing some parts?

I particularly feel there might be an error in the Request Length.

For reference, here is a packet example to read 6 points from D0 on a Q03UDE:

0x50, 0x00,                     // Sub Header
0x00, 0xFF, 0xFF, 0x03, 0x00,   // Route
0x0C, 0x00,                     // Request Length
0x00, 0x00,                     // Monitoring Timer
0x01, 0x04, 0x00, 0x00,         // Command
0x00, 0x00, 0x00,               // Device Address
0xA8,                           // Device Prefix
0x06, 0x00                      // Device Length

Also, it seems there is an MC Protocol library available on GitHub — why not take a look for reference?

https://github.com/YudaiKitamura/McpX

That is some gold right there. Thanks for sharing!

[PLC_baby]

Thanks everyone for the helpful comments!

The issue was with how I was formatting the binary request message — I wasn't struct packing it properly, which is why I wasn’t getting the correct response from the PLC.

SergeyBorchshev’s example helped me understand the correct structure of the packet in binary format, and once I followed that, everything worked perfectly.

Also, big thanks to Aoto10 for the clear breakdown of the 3E frame format and the endian differences. That explanation really helped me understand what was going on behind the scenes.

I’ve marked the solution and will go ahead and close the post. Appreciate all the support!