PLC to PLC comms with built in ethernet ports

[mjrx 1]

What instruction would I use to read a few D registers from a another ethernet connected PLC? I have two Q03UEDH's with the built in ethernet ports. I was going to use J.ZNRD but I don't know if that will work, I don't see where you setup the station number for the CPU. Thanks.

[Mitsu 2]

Using the built in ethernet ports, the command you could use is SOCSND/SOCRCV. For the data, you can use the MC Protocol. If you send an MC Protocol compatible frame, an answer will be "automatically" (without having to write code for it) generated and send back to you from the other side. There is a separate, short manual available describing everything you need about the socket communication for the QnU.

[mjrx 1]

Thanks for that reply. I'm a bit confused about the "not having to write any code" part and the need to use SOCSND and SOCRCV instructions. Wouldn't using the instructions constitute writing code? Anyway I have downloaded a manual pertaining to the Built-In Ethernet Ports, is this the manual you were referring to?

[Mitsu 2]

I should have been more clear about that. If you have two plc's, lets call them A en B, using an MC compatible frame, plc A can ask to B: "give me the content of dataregister D100 to D120". Assemble this frame (or question) and send it from plc A using SOCSND to plc B (so you have to write code at one side, in plc A). Plc B will receive this frame (question), recognise it as an MC protocol frame and answer automatically to A with the content of the data D100 to D120. So in plc B, you don't have to write any code because the ethernet card is able to recognise the Mitsubishi protocol question by itself and will generate an answer automatically. In plc A, you will have to use SOCRCV to receive this answer. MC Protocol is a quite powerful means of communication. If you have gx iec developer, there are function blocks available for this type of communication. I think they are from Beijer and can be downloaded from the Beijer.se website. Comes in handy if you want to study how this communcation is setup. There might be easier solutions for your type of problem though. You could just send a couple of bytes from one card to the other without using the MC Protocol too.

[mjrx 1]

Thanks for that answer, that helped. I really only need to read (or send) about 8 bytes (4 ints) of data. Each PLC needs some status info from the other, thats it.

[Mitsu 2]

In that case, you can do the same thing with SOCSND and SOCRCV but keep in mind that the other plc will not automatically send back the data. So you need to write code to send and receive data in both plc's. It boils down to the same mechanism. The only difference is that the data you will transfer will just be a couple of words instead of an MC Protocol compatible frame.

[Colin Carpenter 10]

In my humble opinion, ethernet "peer to peer" comms is something that Mitsubishi needs to address to make it so much simpler for the end user. I may well be wrong in this, but I seem to remember being told by Tech Support that it wasn't possible to do "PLC to PLC" comms using the built in ethernet ports on the Q03 CPUs. That may be wrong and it may have now been fixed, but I came to the conclusion that it wasn't worth the effort to find out, and we installed some Melsecnet cards that are an absolute doddle and need no code written at all ..... soooo simple. When I spent a day or so looking into Mitsubishi ethernet comms using E71 cards, once again, it's poorly documented and expects me to be an expert in ethernet comms as well as in the plant I'm trying to control. The only IEC function blocks I could find were by Beijers ( the best), but even those seemed to require resets of the PLCs which is not simple on a running plant. Allen Bradley really has got this so much better .... insert the read command, specify the IP address of the other PLC, the starting register and the number of registers you want read, the comms interval and where you want those registers to go in the local PLC and it just works. If you want to write to the other PLC, just use a different command. It's that easy and Mitsubishi should really be following their example on this one. Mr Grumpy.

[mjrx 1]

Not possible to do PLC to PLC? My inquiries to Mits tech support were a bit vague as well, that is why I asked the question on this forum. Has anyone actually done the comms with the SOCSND & SOCRCV instructions that could verify this? I don't have two Q03 CPU's lying around to test this, I just have to know to order the right parts for the project. It seems absolutely idiotic to have a new line of what Mits calls "3rd generation" CPU's with built in ethernet ports that cannot talk to each other. Having to buy 2 seperate cards on top of these built-in port CPU's to achieve this simple task will really frost me. Maybe A-B isn't that expensive after all.

[Colin Carpenter 10]

I seem to remember that was the case, because instead of buying a Q03, I actually spent more money buying a Q02 with an E71 ethernet card thinking that ethernet comms would be the way to go on this particular job, and I actually have a couple of PDFs from tech support showing how to set read and write up using the E71s. Eventually we went for Melsecnet as well, because it seemed that most of the ethernet comms set up was a bit vague, and the PLC I had to talk to could be shut down once in a blue moon and only at around 3 am for about 10 minutes. Like you, I wasn't going to buy another couple of Q02s with E71 cards to play about with to make sure that I could get the comms working, so decided that the best way was the bombproof, foolproof Melsecnet cards that only require a reset on the master (station 0) card, and it worked like a charm. On another site, I've used the Beijers Mac Terminal to transfer the data between a Q03 and an old Q2AS, and that works fine. You can either write some code in the PLCs and set up the BDTP options in the screen (Beijers Data Transfer Protocol) or you can use the Beijers data exchange function. Initially I couldn't get that to work, but in hindsight, I think the Q03 requires a "power off" reset to force it to read ethernet parameters and we hadn't realised that. By the time we did, the BDTP comms was working fine so I just left it. Better the devil you know. Only thing about the BDTP option though is that it's not that fast .... update times measured in seconds rather than milli seconds, which I think is down to the handshaking and the fact that the HMI is also displaying screens and talking to the Q2AS at the same time. "MItsu" is pretty good at this, so I may well be barking up the wrong tree, it's just that with a 20,000 line programme to commission, I just want the comms to work "out of the box". "Maybe" is not an option. Edited 26 Apr 2011 by Colin Carpenter

[Mitsu 2]

Socket communication (as it is now called with on board QnU ethernet) was not possible in the first versions of the QnU cpu's but this has been addressed a long time ago. We have this up and running and it is not so difficult to set up once you know how to. It has been revised in the QnU ethernet and is easier to set up than was the case with the standalone ethernet cards. I do tend to agree that the documentation on it (especially the set of manuals on the standalone ethernet cards) is very confusing though. And i do agree that it should be even more easy to setup as ethernet communication is pretty much the standard communication nowadays. Also, in my experience, the ethernet communication as it is now, is most suited for a situation where you have a very limited amount of communication partners (two plc's exchanging data). In that case, the ethernet card comes at no extra cost most of the time because you have it there either onboard with the QnU or with a separate ethernetcard for scada anyway. For communication between multiple (more than two) plc's, i still prefer a dedicated network solution (like MelsecNet). Edited 26 Apr 2011 by Mitsu

[mjrx 1]

Thanks everyone for the support on this, I'll post again with my results once I get into it.

[Crossbow 295]

Mitsubishi in the US offers an Ethernet class, and I know from the outline on their website that they cover the built-in Ethernet communications and the socket commands.