Colin Carpenter

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

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.

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.

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.

No, it's all in the manual, but I would keep it "confidential" from the operators

I have a funny feeling that there is a limit to the age of E-Terminals that you can upgrade to version 6.1. I know in the past that I've had to swap out older ones for newer ones to let me upgrade to newer firmware versions to enable the fitting of ethernet cards. I'm pretty sure the cut off point is firmware version 2.04 ... but stand to be corrected on that one. You can download the old version 2.04 here. http://www.e-terminals.com/index2.html then Sitemap then Download then search on E710. Just use HMI tools and try and send it and the terminal will normally respond without having to set it into sysload mode. This should at least get you a bootable E710, but I doubt if you are going to be able to fit an ethernet card. I had a similar problem with and E900 that thought it was an E910, but managed to get it back eventually as detailed on this thread. http://forums.mrplc.com/index.php?showtopic=9472&hl=e900

I recently purchased a secondhand copy of MX Component V3.06, mainly because it was cheap and I had no real idea what it was for, so it seemed like a good idea to install it and have a play with it. Having read through the manuals, it seems clear that the software enables the user to write visual basic, C++ software etc that allows easy communication to a PLC without having to know about the comms protocols to the PLC. I've installed it on my PC and the supplied setup programmes are happily talking to an FX2N that I use as a test bed PLC. It occurred to me having read the manuals, that it's apparently easy to set up HTML web pages that will provide a realtime view of data in the PLC. This could be very useful for me when I'm monitoring the PLC during commissioning, as I could create Web pages on my laptop that effectively gave me a crude HMI screen, which would be more informative than monitoring through the programming software. As usual, though, the manuals give clues, but never quite the whole anser to how to do this. I'm pretty sure it's related to Active X controls .... but would appreciate any advice on exactly how to do it from someone who might have used this software. Thanks, Colin

Thanks .... I guess that's the question .... how long does it take to set up up a web page to access data registers (using the ActiveX controls)? I can knock out web pages quite easily and I have the ability to incorporate ActiveX controls using the HTML page designer, it's just that I haven't a clue what each of these ActiveX controls do, or how they work. I've opened up some of the sample HTML pages that come with the software, and I can view them up, it's just that they don't appear to connect to the PLC or do anything when I click them. Bear in mind that this is only for my own use when commissioning or bench testing software, so I can afford to invest a bit of time to find out the capabilities of the software .... but the manuals seem sadly lacking, unfortunately.

I must admit to sticking with tried and trusted functions whenever I can ... at 1 am, my brain can only deal with simple things, and it's no fun being stuck on a PLC with production screaming at you when you don't know what the problem is. I know that any function with "_M" after it was derived from Mitsubishi code, probably DOS MEDOC, so I tend to trust it implicitly. Any of the "non Mitsubishi IEC functions" are interlopers, which may or may not work (TON = Allen Bradley?). In general, I tend to always use the TIMER_M function, normally picking a timer address that counts in 100 mS, therefore the setpoint is 10 times the number of seconds. As long as I know the timer will count to less than 3,277 seconds (about 54 minutes), then one timer will be fine. If the timer will be less than 108 minutes, then I'll probably cascade two timers and use the same setpoint for each timer, eg, a setpoint of 30,000 = 3,000 secs = 50 minutes, times 2 = 100 minutes. In general I find that's plenty for most of my timer applications. If I need a retentive timer (one that doesn't reset when the enable code goes false) then I'll use a normal counter (CC1) and drive it with the 1 second pulse bit in the PLC. This gives me a retentive timer that can count to 32,767 seconds (546 minutes). If you use the 1 minute PLC pulse to drive it, you can end up with a 546 hr timer, though obviously the resolution is not that good. For "hours run functions", where the PLC is timing the hours run of plant items, I tend to use the DINC_P funtion in conjunction with the PLC one minute pulse. This then gives 32 bit data registers incremeting every time the one minute pulse comes on, meaning that they can go to many thousands of hrs without problem. I know I might be a bit conservative about using functions, but if it ain't broke, don't fix it. I never forget KISS (Keep it simple, stupid) .... it's good for the blood pressure. PS The set point on a TIMER_M would normally be a data register (D) or just put in a whole decimal number. In DOS MEDOC, you had to precede the decimal number with a K but you don't need to in IEC Developer. No doubt you can use other things as well ...... but I never have.

I assume by an ON DELAY Timer, you mean one which times then turns on a bit when it's timed out? If so, the graphic attached may help. Cheers.

In E-Designer, if your data register is a signed 16 bit register (an INTEGER not a DOUBLE INTEGER), then the range of numbers the terminal will expect to display is -32767 to +32767. You will see that -32767 takes up 6 spaces if you include the negative sign. Normally leave positions set at the default 6, unless you have space restrictions on the screen. You can also choose to show leading zeroes if you like. So, if you have -300 in the data register, and you want to display -3.00, with positions 6 and dp 2, this would show -03.00 with preceding zeroes showing, or -3.00 without. Your scaling would be 0 to 300 in the controller and 0 to 3 on the HMI.

>>but D700 from timer1 starts going erratic showing 2d34h3m or similar<< I've never seen a data register showing values like that. At first I thought it was Hex, but there are no h or m values in Hex, so presumably it means something 2 days 34 hours 3 minutes, which again seems meaningless. I've never used the TON instruction, which the help files say is a timer with an IN delay, but it also says that: If IN =1 the timer runs If IN = 0 the timer stops If current value = preset value then the timer output is on. That sounds identical to a normal timer, apart from the fact that the timer will reset in a normal timer when the input conditions are untrue. Tend to use the standard Mitsubishi TIMER_M functions all the time. TC* is the timer coil, TS* is the timer digital output and TN* is the elapsed value of the timer, which I normally move to a data register (D*) if I want to display it on the MAC screen ,as the older E-Designer doesn't really understand the TN* side of things.

Unless you use real (floating point) numbers, you won't be able to store a decimal value in a normal data (D) register in the PLC. This value must be an integer, ie a whole number. So the trick is to store the values as 20 and 30 in the PLC (not 2.0 and 3.0), then use the scaling function of the E150 to divide this value by 10 and display 1 decimal point. I use the MAC screens ability all the time to scale integers to engineering units .... so much easier than having to convert to floating point, do the maths and then convert back to integers. For example, on QnA series PLCs with 8 channel analogue inputs reading 4-20 mA signals from 0-100 C temperature probes, I set the analogue input to read 0-20 mA, meaning that 0 bits = 0 mA, 800 bits = 4 mA and 4000 bits = 20 mA. Thus, on the MAC screen, set the scaling values: Controller Values 800 - 4000, Screen Values 0 - 100. The MAC software then works out the m and the C value for the straight line (y=mx+c) joining the points (800,0) and (4000,100) by solving the double simultaneous equations. Works like a charm ... and I just can't believe that there are other screens out there that don't do this function. Incidentally, the reason for setting the analogue input channel 0-20 instead of 4-20 is that the PLC can read all the way down to 0 mA, so I can set error states at, say, 3.5 mA, which allows the transducer to float a little below 4 mA and still be "good". I digress ....

I think that's the way you do it. Create a POU. Then create a Task - call it what you like. Set up the task with your POU showing in it. Right click on the task and enter (say) M100 in as the event. This will now only run the POU when M100 is on. Have only used this once, when I had a POU that was calculating a lot of real numbers and was slowing down the scan time too much, so I put the code in a POU and only called it when the operator pressed the "recalculate" button. Worked fine. Haven't a clue what the interval and priority numbers mean though.

Thanks for that ... I'm pretty sure that's the way it is as well.

Is anyone an expert on networking E700 HMIs? I have an FX2n that is happily talking to a E700 through the RS422/485 port. The HMI is local to the PLC, and the customer wants the operators to be able to view the information on another E700 in the remote control room, but to have to walk to the plant to actually initiate things. I propose to fit an ethernet adapter to both E700s and set up a BDPT Server / Client network using a crossover cable between the two, with the existing E700 being the server and the Control Room E700 being the client. I know how to configure each E700 with regards to setting up the TCP/IP addresses and configuring them as server and client, and I know how to define the addresses in the client (1>D200 etc.) The only thing I'm not sure about is whether or not the client E700 can access all the data registers in the FX2N that the server E700 can access without writing any new code into the PLC. For example, if the server is accessing D200 in the PLC, can the client access 1>D200 as well? The reason I ask is that the Beijers manual goes into great depth about things called "Data Registers" and "Control Blocks" in the BDTP client page, but I'm fairly sure that that only comes into effect if you have multiple server /client scenarios, when I know that you have to write some PLC code to handle the comms of the various clients and servers that are waiting their turn to talk. In this very simple case (one server, one client), I don't think it's that complex ....... hopefully.

Can't you do that in GX Developer? Reason I ask is that it's available in IEC Developer ..... just export to an ASCII file and tell E-Designer to look at the ASCII file ....job done. Never having really used GX Developer (went straight from MEDOC to IEC), I'm surprised at some of the niggles it seems to have. Have to say that IEC Developer is really good IMHO .... surprised they don't release it in the USA as the latest version is really stable and very easy to use now that Global Variables don't have to be declared in POU headers as well as in the Global Variable list.

I very much doubt if the firmware versions are an issue. Many of the E900s I programme have later firmware versions than the E-Designer firmware version and I've never yet noticed a problem. When transferring programmes, I normally turn off the firmware version check. The comms error flashing in the top corner is the problem you should be hunting down, as it normally relates to a comms problem between the HMI and the PLC, or possibly to an ethernet comms error if an ethernet expansion card is fitted in the HMI and it can't find the network that the HMI software is telling it to expect. The driver that E-Designer uses to enable the HMI to talk to the PLC can also cause this problem. I remember downloading software into an E900 to talk to a Q2AS CPU and the driver on my new laptop was the one that had come with the E-Designer disc, while the one on my old laptop had been updated from the Internet. Result was that the older driver got installed and I ended up with exactly the problem you describe. Conclusion - check that the HMI to PLC Driver is the latest version available from Beijers. The old www.e-terminal.com website is still active (well, it was the last time I looked) and drivers can still be found there, though it's now a bit clunky to find your way round. Or, in E-Designer try FILE / UPDATE DRIVERS FROM THE INTERNET to see how up to date your drivers are. Best of luck .....

Has anyone any experience of connecting two MAC screens (an E300 and an E900) to an FX2N PLC? I know I can do it with ethernet cards in the Macs, but just wondered if there was an add-on card for the FX2N that allows "direct" connection of the 2nd HMI. Thanks.

Perhaps I should have added that one HMI will be very close to the PLC (on the panel door) while the other will be about 60 metres away in an electrically noisy environment. Ideally, I'd like the local one to be RS422 into the PLC so that I can connect my laptop through the serial port in transparent mode, with the distant one connecting by some other means. I chatted to the Mitsubishi rep yesterday and he said that I could add the distant HMI to a 485 or 422 BD board, which would be fine, but I went on the old E-Terminals website and could only find the details for connecting a MAC to a 232 BD board, which makes me wonder if it can be done to a 485 BD board. The distant screen would be too far for 232 comms, so it would have to be the local one which used 232, with the distant one using the PLC programming port. That would be fine normally, but I've now got no local serial port to plug my laptop into. Has anyone actually conncted the RS422/485 port on a MAC to a 422 or 485 BD board just to see if it does work? Thanks

You learn something every day. I've been having a lot of problems recently doing online changes when talking in "transparent mode" through a MAC E900 to a Q2AS CPU. Small changes (address change or change the operation of a contact) seemed fine, but anything involving deletion or insertion of code in the compiled code (IEC Developer) would result in an odd error message and an inconsistent project, involving stopping the PLC and downloading the entire project to get back to a consistent state. That's not much fun when you're working on a running process plant, it involves lots of waiting around and setting manual over rides on solenoids etc., just to get to a point where I can stop the PLC. I just assumed it was a Mitsubishi bug and kind of learned to live with it. Normally, I can't see the MAC screen when I'm doing this, but the other day, I happened to have one on the bench and noticed that whenever the online edit failed, the MAC screen showed a Comms error for a while, which intrigued me. So today I sent off an E-Mail to those nice people at Beijers, and they replied that if you edit the properties of the PLC driver (in peripherals section of E-Designer), you can increase the time out value from the default 2 secs up to 10 secs. This I did, and lo and behold, I can now do online edits without problem. It seems that the PLC stops communicating with the MAC while it's doing the online edits, and this is what causes the comms error and the glitch. E-Designer will let you set up to 10 secs as timeout, but you can do it in the MAC screen and set at least 20 secs (or maybe more) using the buttons on the screen to set the value. I've been using MAC software for 10 years or so, and never knew you could do that. Many thanks to Beijers

Well, now all you have to do is stick one probe of a volt meter onto the "switch wire" of the encoder. Connect the other probe to the 0VDC terminal of the PLC and see if you have 24VDC+ on the switch wire. Slowly spin the encoder and see if you have 24 VDC+ appearing and disappearing at the switch wire. If you can then the encoder is PNP, so connect S/S to 0V and it should work. If you can't see any 24VDC+ at the encoder switch wire, then it may well be NPN, so connect the S/S terminal to 24VDC+ and try again. If neither of those options work, then you need to really read up on the wiring of the encoder to see what's going on. Try to use logic to fault find the wiring as well as to write the programmes. Break things down into manageable, testable chunks, and quite often, you can solve the problem just by thinking about it.

First things first .... forget the encoder for now, connect a flying lead to 24VDC+, connect the S/S terminal to 0V (PNP). Then programme the following: 0) LD M8000 1) OUT C235 K20 2) LD C235 3) OUT Y000 4) LD X003 5) RST C235 6) END If you dab the flying lead onto the X0 terminal, you should now be able to see counter C235 count up. When it gets to 20, output Y0 should come on and be reset when you touch the X3 terminal. The logic is .... when you get a problem that may be caused by a host of things, simplify it and test what you know. If this programme works with you taking the place of the encoder, then the problem may lie with the encoder.

From a previous post regarding the S/S terminal (it stands for "sink" or "source") >>Link it to 0V for PNP (sinking) or 24V+ for NPN (sourcing). Leaving it not connected is not an option, as the strangest things can happen.<< In the early PLCs there was no RUN switch, only a RUN terminal. These days, if there is a RUN switch then there is no RUN terminal (at least not on the FX2Ns) I believe that you can designate a run terminal in the programming software if you really need one, though I've never used it.

Is the RUN Light on?