Beijers to DH+

[Colin Carpenter 10]

I am proposing a control system using a Mitsubishi FX3U working with a Beijers 1000 series screen. I have absolutely no problem with connecting the FX3U to the screen, but my customer wants to be able to access data from the PLC using his Allen Bradley based DH+ SCADA system. I propose to use the HMI to Data Transfer data registers from the Mitsubishi to the Allen Bradley system, but believe that the HMI does not appear to support DH+ directly from the HMI ( although it does do DF1, DH485 and Ethernet) Does anyone know a way of making this happen? My knowledge of the numerous AB networks is limited to say the least.

[JesperMP 2]

Hi Colin. What SCADA software is it exactly ? Most SCADA's these days support OPC which is an open standard for connecting to various PLCs. I think (= not sure really) that Rockwell RSView is even bundled with a version of KepWare OPC servers that will connect to a wide range of PLCs, and possibly even to Mitsi. If nothing else, you can probably purchase a separate OPC server to connect to the Mitsi PLC. In other words, you will NOT connect your Beijer HMI to DH+ or the customers SCADA. In stead your customers SCADA connects directly to the Mitsi PLC via whatever network connection type the mitsi supports.

[Colin Carpenter 10]

Hi Jesper, Yes, that's a valid point (not exactly sure what the SCADA software is at the moment, though suspect it's In Touch). The only problem I have is that the customer is very resistant to having Mitsubishi anyway, and as the application uses a lot of "fancy" Mitsubishi functions and has been developed specifically on Mitsubishi software, I'm very reluctant to have to port the whole lot across to an Allen Bradley. So I was kind of hoping that there is a "seamless" solution which involves him having to do no work other than plug his DH+ system into my kit and just watch the data flow, if you see what I mean.

[JesperMP 2]

Hi again Colin. It shall be your customers problem how to connect to your PLC. Forget about DH+. There is absolutely no way or reason for connecting your Mitsi PLC to DH+. The solution for your customer is to use a native driver for Mitsubishi if it is possible, and if there is no native driver for Mitsubishi then go via OPC. OPC is the most seamless solution there is.

[Crossbow 295]

Doesn't AB offer a bridge to convert a DF1 device to DH+? Use that on the screen set for DF1 and you should be in shape. I agree with the previous comments it's not your problem if they choose to go after this information in the E-terminal. There are other ways to get the data without using the E1000 as a bridge, but that is one of the easiest.

[Colin Carpenter 10]

Thanks for the info .... did download a PDF from Beijers that shows how to connect the RS232 port on the HMI to a 1747-KE module which will enable the screen to talk to an SLC500. The KE module is much cheaper than other comms converters in the AB range ($2,000 or more) so that may be the option to go for. I would love to agree that "it's the customer's problem", but here in the UK it seems that a lot of companies are insisting on a particular site standard for anything PLC related, and they can be tough to dissuade. I've lost a few jobs when sites have insisted on Siemens (which I can't do), have sweated months doing a Control Logix project when an old A series would have eaten the application very quickly. Some of them just get to the point where if you can't provide their chosen PLC, then you just have to walk away from the job. I can see both points of view ..... but sometimes, you just need the work.

[JesperMP 2]

Colin. The 1747-KE module is intended to be installed in an SLC rack and will allow a SCADA for example to bridge from DF1 to DH485. In other words, it has nothing to do with talking DH+ from your Beijer panel to the customers SCADA. DH+ and DH485 are two totally different things. There is a 1770-KF2 module that bridges from DF1 to DH+. Many HMI has this as the method to connect to an AB PLC via DF1/DH+. Maybe your Beijer panel supports this method. But read on. IF your Beijer panel supports DF1/DH+ via a 1770-KF2, then it will probably only work as a device that polls data from an AB PLC. As the customers SCADA also works as a device that polls data from a PLC, how can you pass the data from the Beijer panel to your customers SCADA ? There is a way to send "messages" via DH+, but I am 99% sure that your Beijer panel wont be able to do this. Plus, the 1770-KF2 box is obsolete (dont know if it can be purchased any longer), plus it is very expensive. Here are your options: 1. Convince the customer that he shall connect to your Mitsi PLC via OPC. This is the simplest, easiest and least expensive solution. Noone has to change anything, you get to keep your PLC and HMI, and the customer gets to connect to your PLC with his current SCADA. 2. You take on the task of installing a PC with two OPC servers, one for Mitsi, the other for AB, and pass the data from one OPC server to the other. Maybe you can switch your Beijer HMI panel into a PC, so you only have the same number of devices in the entire system. If you decide to go this way, I can give more tips. 3. Convert your PLC to an AB. It probably has to be an SLC5/04 because of the DH+ connection to your customers SCADA.

[Colin Carpenter 10]

Hi Jesper Thanks for all the input ... it's really useful. I have some more information that I found out from the customer. The site runs mainly on SLC500/4 CPUs with one Control Logix CPU controlling one particularly large application. They use Citech SCADA package which somehow uses ethernet / gateway / DH+ to network all the CPUs together (as the 500/4 has a DH+ port built into the CPU). The site engineer is a little vague on the exact way it works, but does know that they had one heck of a job getting it all to talk in the first place. I have no idea how the Citech server distributes information to various monitoring PCs .... presumably through an ethernet network and workstation licensing system. Having looked at all the options, I had come to the conclusion that the simplest / cheapest way of getting the data from the Mits to the Bradley system would be by using the Data Exchange function built into the Beijers HMI. This function enables different PLCs to be connected to the same HMI and enables the "event driven" exchange of data between two different PLCs. Therefore, if I have a block of D registers in the Mits, I can write a simple timer routine that will turn on a bit that will cause the HMI to convert the named block of data registers from Mits "D" registers to Bradley "N" integers and transfer the values. This is easy to do, but relies on an HMI driver being available for connection to the Bradley network. All information (as you rightly say) shows that there is no real way of getting Mits dat into a Bradley DH+ network, however, there is a local SLC 500/4 close to the proposed location of the Mits. The HMI can talk DF1 through a simple serial cable and the 500/4 has a mini din DF1 port, but Beijers specifically suggest that the better option is to interface through a 1747-KE module. So, my current "plan of least resistance" would be to fit a 1747-KE card in a spare slot of the SLC500/4, connect this via DF1 to the HMI and write values (on timed intervals) into spare N integers in that SLC500/4. Once that CPU has the information in those integers, then the SCADA can just access the information from that SLC CPU. Only thing I need to do now is find out if there's a spare slot on the SLC 500/4 .... and we all know the answer to that one Regarding porting it to the SLC500, I really don't want to do that as I get a "one shot" commissioning opportunity of this system and I know the Mits pretty much "inside out" now. Also, the application uses a lot of realtime real number equation solving and the way IEC Developer allows complex maths equation solving to be programmed is so good.

[JesperMP 2]

Hi again Colin. You are talking to the wrong guy at the customer. People with no precise expertise about a system are prone to say "it cannot be done" or "we want it like the last time" rather than making an expert judgement about which solution is the best. What they have done is almost certainly to connect to the various SLC5/04 CPUs by using a ControlLogix chassis with an ENBT ethernet module and a DHRIO module as a gateway between ethernet and DH+. That the guy you talked to is not aware of this layout tells me that he has ZERO knowledge about communication between the SCADA and PLCs. The SCADA very likely uses Rockwell RSLinx as OPC server to connect to the AB PLCs. This would be the same method for connecting to the Mitsi PLC, so it is probably not a problem at all to connect to the Mitsi PLC. Only the guy you talked to thinks so ! In one way or the other, the customers existing system has to be modified. Locate the right SCADA guy, and explain him that the alternatives are: Either: SCADA + Mitsi OPC server ---> Mitsi PLC. (1 step) Or: SCADA + RSLinx OPC server ---> Gateway ---> SLC5/04 ---> 1747-KE ---> Beijer HMI ---> Mitsi PLC (5 steps, with 5 different protocols on the way !) He will choose the first alternative, because he will have to live with the solution after you have left the site. If there is ANY problem with the 2nd solution, then how do you locate the error ? It will take an expert in all components in tha path from the SCADA to the Mitsi PLC to figure out. And even then it will not be easy. Edited 31 Jan 2008 by JesperMP

[Colin Carpenter 10]

Thanks Jesper, So, to connect using "SCADA + Mitsi OPC server ---> Mitsi PLC. (1 step)", what hardware / software would be needed to achieve this? Only time I ever set up an OPC server was using a dedicated Siemens Profibus PCI card in a PC to create a Profibus network to 2 S7 PLCS (manufactured by Softing). Presumably, I'd need some sort of interface for comms from the SCADA PC to the FX3U? Will start hunting round the Net Addition - looks like it's "MX OPC server for all PLCs", and presumably an RS485 interface to the 485BD port on the FX3U Edited 31 Jan 2008 by Colin Carpenter

[JesperMP 2]

I know Siemens and AB quite well, but not Mitsubishi. If I were you I would seriously think about getting a PLC with Ethernet. Serial protocols are more and more being replaced with ethernet (apart from fieldbus standards like Profibus and DeviceNet), and I can imagine you have a much easier "sell" if the customer do not have to add new hardware. Apart from that, there is Mitsubishis own OPC server: http://www.meau.com/eprise/main/sites/publ..._Server/default And kepware sells one OPC server that should support all Mitsubishi protocols: http://www.kepware.com/Products/Mitsubishi-Suite.htm Ask if the customer uses Kepware already. There is a possibilty that they do, as Kepware have OPC servers for AB. edit: One potential problem is that Citect comes bundled with many drivers for various PLCs. There is therefore a risk that the SCADA programmer dont know OPC so well, if he has used one of these bundled direct drivers. But I know for sure that Citect works with OPC. Edited 31 Jan 2008 by JesperMP

[Crossbow 295]

You can use the SC09 cable connected to the RS422 port on the FX, but I assume thats where your E-terminal is. You can add an RS232 adapter on the left bus to go with the 485BD, and use an RS232 cable, or you can just add FX3U-ENET to the right side bus and connect with the OPC server to the Ethernet module.

[Duffanator 1]

We have Citec at our plant and if it's the same thing that we use you should be able to pull the information out of the PLC via Ethernet or 232/422 and write that information into the Allen Bradley PLC's. Kind of like using the Citec as a third party in between the two different PLC's. This, of course, would require someone to program the Citec software (I'm not in charge of that where I work so I'm not sure how that works) but that is as easy an option as anything else.

[Colin Carpenter 10]

Thanks to everyone for their replies and advice. As with all things comms related, it seems that there are many ways to do something. I spoke to Citect yesterday and they advise using an E-Net module on the FX3U and talking direct to it with one of their drivers. They also seem to have a system whereby MX Components can be used on "psudo OPC" basis, though he wasn't too clear on how to use that. Presumably that opens up all sorts of comms options, and as I bought a pukka copy of MX components the other day, it might be worth a look. I think Jesper's right ... increasing the number of protocols and converters just increases the risk of running into problems, so it looks like their Citect system is just going to have learn to talk to a Mitsubishi.

[funfrok 0]

Citect + Mx Component works well. You configure a connection to the PLC in Mx Component Communication Setup Utility and put the connection number to Citects configuration. You can change communication path and options later without changing Citect project. So it behaves like an OPC server to Citect.