Best way for 4 PLC communication?

[mr_electrician 9]

Hello Mitsubishi forum. I am new to Mitsubishi but not to this web site or plc's. I am now employed at an automotive facility that employs Q Series PLC's. We have a cell that has 4 seperate control cabinets each using a Q01UCPU. We program using the USB method. In order to reduce physical interlocking and wiring I would like each PLC to be tied together somehow. One of the PLC's does have a CC link card (QJ61BT11N) that goes out to some remote I/O. I was considering using this method to tie all the PLC's together but a future project is to have data sent to the network for production details. I would obviously do this with Eternet. Because of the future project I am thinking that Ethernet cards for each PLC are the way to go with Ethernet Hubs in each cabinet as well. Each cabinet by the way also talks via hard wire interlocking to Fanuc R30iB Robotic Spot Welders. What suggestions does anyone have??

[Colin Carpenter 10]

There are numerous ways of doing it, but I'm a great fan of MelsecNet in it's various formats. In the simplest form, you fit cards to each of the PLCs, one is designated as Master and the parameters of the network are set up in that PLC. Essentially, you assign a range of W words and B Bits for each of the 4 PLCs in the parameters of the Master only. That's it then ... no other programming to do. Each of the PLCs can write to it's own range of W words and B bits and can read the W words and B bits of all the other three. Very useful as a way of adding "remote IO" to a rack. Just create a new rack, get the cheapest CPU, fit one of these cards and add it to the network. In the new PLC write a small programme that just maps the remote IO to and from the B bits and address the remote IO with their B bit addresses in the master PLC. Works perfectly, never falls over, doesn't mind if one is powered off etc etc. You can even set up the network to do the remote IO bits for you, but I just like to give the CPU something to do to stop it getting bored :)

[kaare_t 155]

I agree with Colin, MelsecNet rocks! However, the only sad thing with MelsecNet is that you don't really have an "Open solution" when it comes to communicating with other peripheral equipment. By using the Ethernet modules you can, in essence, connect to any device and write your own defined protocol in the cards. Therefore, sadly, I almost never use MelsecNet anymore. After MelsecNet I just love the Ethernet modules of the same reason as stated above: User defined/programmed protocols. You can collect data from 3. party devices, you can also control 3. party devices by programming your own protocol using the "NoProtocol" mode in the card. No special "extra" card is needed. Further on, if you at some point would like to start collecting data to a more centralized system like Scada, OPC, SQL or other control/monitoring systems Ethernet is the way to go since you can access all your devices via the network. Sadly, Mitsubishi haven't been very good when it comes to connectivity between their own Ethernet modules which means you'll have to do a little programming. There are lots of examples of this on their website, but I really feel that it should have been as easy as MelsecNet to connect two Mitsu PLCs together via Ethernet. This is not a big issue it's just my personal opinion. Based on your initial post I would recommend using Ethernet modules in all your systems. Remember that HMI solutions most often also have drivers for Mitsu Ethernet which means you can connect them remote or local via Ethernet instead of serial cabling.