Colin Carpenter

Dos Medoc and the later 32 bit version works fine with transparent programming to the older PLCs, but I can only confirm that it works with the Beijer HMIs ... have never heard of or seen an MTA-G1 unfortunately. I seem to remember that when using an A1S with an old MAC40 you had to change the comms parameters to talk to the CPU, but every Beijer terminal after that, it just works as long as the HMI is configured for it in the set up software. The cable used was 9 pin serial to 9 pin serial, configured 2-2, 3-3 and 5-5 ... it was that simple.

That's exactly it. Beijer's tech support sent me an email with the installation file for MS Java Virtual Machine and it works perfectly now. Big thanks to Beijer, once again .......... when all else fails, these are the guys that know the answers, it's just a shame that politics make it very difficult to contact them (and it's not Beijer's fault, I hasten to add!!) Thanks

Wonder if anyone can help with the following "viewing" problem that I get when using the web server function on an E900 with ethernet card fitted Below are the notes I wrote at the time and the screen shot as viewed on my PC. Really odd problem this and I'm not really getting any support at the moment. E900 is 2003 vintage. Boot version 4.03, currently running firmware version V6.00 Site is a remote effluent plant, only visited occasionally. When project was commissioned in 2003, E900 WWW server was set up in conjunction with a "special" Mitsubishi modem (connected to the E900 serial port) which enabled the customer to dial in and view / operate the HMI. Has worked fine (but slow) for past 5 years. Customer has now upgraded to broadband and requested upgrade of the E900 to allow WWW server access accordingly. September 2008 Fitted IFC ETTP ethernet to slot 1 of the E900 and connected by patch cable to customer supplied router. Configured E900 accordingly and WWW server function of the E900 now works fine using VPN access across broadband connection, apart from one thing. As shown on graphic, only PART of the terminal graphic actually shows in the JAVA applet view. This happens with all browsers (Firefox, IE various versions and in XP and Vista). All the terminal navigation buttons work fine and all the screens in the E900 work fine. The buttons which are not visible on the screen also work fine, in other words, if you guess where the buttons would be and click, then the screen navigates correctly. Everything works apart from the fact that it seems as if only part of the E900 jpg is displaying on the screen, all controls etc are fine. The screen works with user passwords, so the problem is that the number keypad needs to be visible for full use. More info. When using HMI Tools FTP Connect, the E900 shows 2 files in the HTML directory, these are E900APPL.JAR and the index.htm file.

A few years ago, I installed an E900 in a remote application, complete with a Mitsubishi modem so that the modem could be dialled into and the terminal could be viewed (and even operated) using the inbuilt web server on the the HMI from a remote computer using Internet Explorer. It all worked (and still works) fine, albeit a bit slow. The customer is now asking if they can install a broadband connection so that the terminal can be viewed and operated over a broadband connection. I've installed plenty of ethernet cards in E900s and E700s, but have always used them to talk locally to each other over a Beijers network, and have no experience of setting one up over a remote broadband connection. Has anyone done this, and if so, can you tell me what I should be looking out for, and also, is there a large speed increase or do you still have to wait for things to happen? Thanks

Hi Nathan, Apologies for lateness ... been on holiday. The idea is that the E900 should allow the inbuilt web server to operate over the internet using the added ethernet card. I've done it before on a Beijers local network using an ethernet switch and several mac terminals with ethernet cards fitted. Each of the mac terminals had a TCP/IP address something like 192.168.1.x etc, and I found that if I connected the ethernet port on my laptop to the switch and typed in the TCP/IP address of the mac terminal that had the web server enabled into a browser, then I could view it over the LAN no problem. Any idea how you would address the terminal in a remote browser if connecting via the internet, presumably using a broadband router?

The E700 always used to sell for about £1,250 list price in the UK until it was discontinued.

If testing, sometimes I'll just change the X addresses to similar M addresses (though the X addresses will be HEX, and the M addresses will be Decimal). By doing that, you can write simulation code into the PLC that will alter the state of the M coils as you require. When tested, change them back to X values, delete the simulation code and the job's a good'un. Thinking about it ...... it might be better to use B coils to replace the X addresses, as they are also HEX addresses. Not sure if the software would moan about the fact that there is no networking set up though .... doubt it.

Yes, I'm pretty sure you do need an older version of E-Designer. As you have discovered, V2.04 of the firmware was the cut-off point between the older and the newer versions of the E-Terminals range. Anything before or up to V2.04 cannot be upgraded above v2.04, while anything above v2.04 can be upgraded to the latest version (v6.1). There are certain things that can be done in the later versions that can't be done in the earlier versions, such as dynamic effects on graphics etc, addition of ethernet cards. E-Designer V6.00 will allow you to programme your E700 v2.04. E-Designer V7.xx is really designed for the latest range of E-Terminals .... it gave strange results when I used it on an E900 once, so I stick with E-Designer v6.xx.

Check your serial comms settings in Medoc. On the older screens and older PLCs, you would often use different RS232 serial settings if talking to the PLC in transparent mode through the screen than you would when talking direct to the CPU port. Try 9600, 8, odd,1 for a starter. I have also seen cpu ports where the pins have corroded, and a gentle squirt of WD40 has restored the comms.

As Gambit says, the data registers and programme areas are two separate things in the Mitsubishi world. If you come from an AB background, then the two are linked together. If you upload or download a programme, then the data register values ( the data tables) upload or download along with the programme. You have no option in this, which I think is wrong. I once had to download (to the SLC500) a security back up programme a few hours after we had made it. This meant that the data tables which were made at the time also had to be downloaded and the plant regressed to a state which existed a few hours before. The next 5 or 6 hours were spent having to change values to reflect the state that the plant had moved on to. Nightmare!! With Mitsubishis, whenever you download a programme (or programme and parameters), that is ALL you download. The security of the values in the data registers depends on how you have set them up. Latch 2 - Remain as they are unless changed by HMI, programming software etc. Cannot be reset by the key on the PLC. Latch 1 - As Latch 2, but can be reset by the key on the PLC. No Latch - Not sure if they change on programme download, but will certainly revert to zero in the event of loss of power to the PLC. If you want to upload / download data register values to the PLC, then you use DEVICE EDIT. I use IEC Developer, but the same thing will exist in GX Developer. On the attached graphic you can see the way to to do it. (Right click on the main box to get the smaller box.) So, if you want to upload the values that are in (say) D0 to D100, set up the range, then click on READ FROM PLC. To save these values to your PC, click on WRITE TO FILE. To write these saved values into a new PLC (or one that has lost its values), click on READ FROM FILE, then WRITE TO PLC to send those values to the registers shown. A much better way IMHO.

That's the one I always use, because they can't be cleared or altered by anything other than the programming software, HMI or similar. I think they're almost as secure as File Registers (as long as the battery holds up), but stand to be corrected. If you select Latch 1 then a maintenance guy can reset all the stored values to zero with the flick of a key on the CPU .... If you don't set them to either, then every time you download a programme or power down the PLC, they will all reset to zero. Most AB PLCs upload and download the data registers by default, but that can cause problems as well, as re-loading previous software version in the event of problems will re-instate the conditions that were current when the previous software version was uploaded. Personally, I find the Mitsubishi way less hassle, but it would be nice to have the choice with AB.

That was a classic case where Beijers would have been able to help. As you correctly say, the HMI Tools later versions do not allow the downloading of firmware to a unit that claims it is something else other than what you know it to be. However, the early versions of HMI Tools (v1.1) did allow you to do this. They changed it in the later versions as people were writing wrong firmware into units and getting into all sorts of problems with E150s that were trying to run E900 firmware and so on. The glitch that caused my problem with the E900 was an incorrect identifier in the E900's V4 firmware that made it identify itself as an E910 to HMI Tools (this is documented on a Beijers knowledgebase article). Stupidly, I assumed it must actually be an E910, so downloaded the firmware and ended up with a button based screen that thought it was a touchscreen. Luckily, Beijers support sent me the early HMI Tools version which ignored the identifier in the screen and allowed me to reload the correct E900 firmware. Saved me in the region of £1850 (about $3,700) for the cost of a new screen to replace the customer's perfectly good second hand screen that I'd apparently wrecked due to a glitch in somebody else's software. I also think that Mitsubishi support is reasonable (the dealers are excellent), but on obscure things like this, sometimes only the designers / manufacturers can help out. And the people at Beijers are top notch.

Whatever the commercial deal is between Beijers and Mitsubishi, the fact of the matter is that nobody knows the Beijers terminals as well as Beijers. After a firmware glitch in an E900 (which caused me to incorrectly download the firmware for an E910), I would have scrapped the screen if I'd listened to Mitsubishi support, who said that there was now nothing I could do other than try and get another EEProm from somewhere. An email to Beijers showed that it could be retrieved with software (and was). I recall a thread on here about an E700 that had been upgraded with the wrong firmware. Mitsubishi were talking loads of money to fix it, but a visit to the old E-Terminals site provided the correct firmware and the screen lived again. That old firmware version was not available on the Mitsubishi site. If I want an E-Terminal (bought from Mitsubishi) to provide a data exchange function between an Allen Bradley and a Mitsubishi PLC, if I need to talk to someone about the drivers and cabling between the screen and the Allen Bradley, Mitsubishi won't help. I know, because I've tried. On this thread, note where Transistor found the files needed to fix his problem. They were on a Beijers Swedish website. They may well be available from a Mitsubishi website, I haven't looked, but I'm sure he did. I once had an irate phone call from a Mitsubishi UK Sales Manager who claimed that I should be going direct to them and not to Beijers, as they provided all the support and files I needed on the website. When I told him the problem, he had to eat humble pie as he realised that the website only supports the newer kit, not the older stuff that we work with day in, day out. Don't get me wrong, I love the Mitsubishi PLCs and programming software to bits and strongly resist any pressure to make me change to something else. Dealer support in the UK is first class, but when it comes to working with the older E-Terminals, then you will rapidly run out of options without contacting Beijers.

Thanks for that ... have updated the drivers on laptop now as well. It can't be long before I try and mate an E terminal with an FX3U. Reckon you saved me a couple of days head scratching there. Incidentally, in the past I've found Beijers to always be excellent with support and drivers when you contact them by email. The problem always seems to be that Mitsubishi don't really want you to know that the E-Terminals are made by Beijers, so a UK support request to Beijers is normally bounced back to Mitsubishi UK, who are pretty good, but just don't have the same level of knowledge that Beijers obviously do, having designed, built and written the drivers for the terminals.

I fired up my copy of E-Designer 7.0 and updated the drivers from the Internet, which worked fine and installed all the newer drivers. However, I'm a little confused as when I select the FX series CPU drivers, virtually every FX version shows in the next box, except the FX3U. I would have thought that by now that the driver would have included the FX3U as an option to further define the PLC that's attached to it. The only driver that specifically mentions the FX3U is the ethernet one, which is a little odd. Confused ..........

I'm beginning to wonder if you've "fallen between versions" in a manner of speaking. I haven't used the FX3U yet (still seem to stick to the FX2N most of the time), but the FX3U is pretty new and the E910 has been around for a number of years. My verison of E-Designer is version 6.00. I have the new version 7.00, but have been advised not to use it unless working on one of the new range of terminals (the E1000 series). My E-Designer 6.00 doesn't know about the FX3U yet ( it hadn't been invented at the time), so it doesn't have a driver for it. I searched on www.e-terminals.com and found an FX3U Ethernet driver, but nothing else.... which makes me wonder where you found an RS422 driver for it? Seems strange that Beijers would put an Ethernet driver on the site, but not an RS422 one?

A mate of mine has got himself into a BIG problem. He's working on a project that demands a lot more knowledge, mathematics and equation solving than he thought it did. I did warn him, but there you go ..... The job is just at the commissioning phase, and I think that the brown murky stuff is just about enter to the air space of the revolving air handling mechanism, so he has to sort out a solution pretty quickly. The customer demands that the PLC on this piece of plant is an Allen Bradley, so a CompactLogix PLC has been installed. I know how to do all the maths, the equations, the data look up and the problem solving, but I do it using an FX2N or an FX3U. I've never used the CompactLogix PLCs, so to effect a reasonably quick solution, I'm thinking of proposing a "Black Box" solution, namely a FX3U that I can programme and test using the experience and routines that I've built up over the years. The theory is that the CompactLogix would handle all the analogue ins, anlogue outs and the PID control, but that the the FX3U would do all the number crunching to inform the CompactLogix of the setpoints that it should be controlling to. So, what I need is a reliable method of exchanging integer values between the two PLCs. The CompactLogix reads the analogue ins, sends them to the FX3U, which crunches the numbers and sends back PID setpoints for the CompactLogix to control to. Speed is not really an issue ... the system response time could happily be in the order of tens of seconds. So, can anyone recommend (have used) a comms method that will reliably allow an FX3U and a CompactLogix PLC to transfer data between each other, with update times in the order of a few seconds? Thanks.

I think the HMI is the solution as well, I just wondered if there was another way of connecting the two together. Hopefully the new range of MAC screens will have a CompactLogix driver available. The question regarding who specifies the PLC crops up a lot these days, and causes loads of problems. For "run of the mill" control then I can see that the customer has a case for demanding a certain "site standard PLC", so that he can add things to it, his maintenance guys can alter the code etc., etc. However for a highly specialised application, where the customer expects the programmer to guarantee the results in a measurable way, and to install it in a small downtime window, and to get it right first time or face the consequences, then there is no substitute for working with what you know and trust. For a small one or two man company, imagine the cost to have "up to date" working versions of all the software for all the major PLCs, and to keep up with all the changes and patches and updates that come so quickly now, just so that you can respond to every customer demand for a certain type of PLC. I did one job where the customer demanded a ControlLogix PLC to perform a task that a basic SLC500 or A series PLC would have "eaten for breakfast", but he insisted because it was the "site standard" ... just the CPU and the programming software license cost more than my car!! I always think it's a bit like me deciding to splash out on a new BMW M5, but then telling BMW that I didn't like the brand of controller that they used for all the car's engine management and other systems, and insisting that they change it all to another brand and that they guarantee the performance of the brand that I insisted on. On a highly specialised software package, that the customer will never touch, isn't it better sometimes to accept that the supplier knows best?

If you're thinking of trying to control PH by dosing acid or alkali, it can be a bit of a nightmare. Unlike most sensors, PH is not linear, it's logrythmic (sp?), which means that for a given flow, you have to add 10 times as much to go from PH8 to PH9 as you do to go from PH7 to PH8. Never did get enough time playing with the system to really work it out, unfortunately ...

I used to use STL programming a lot, especially back in the old days when an F1 was a state of the art PLC. Those were the days with no data registers as such and only about 24 (or was it 32?) timers. I used to write a lot of code for food processing cleaning systems and these normally were sequential and involved a lot of timers waiting for things to happen, then moving on. The beauty of the STL code was that it was OK to re-use timers as long as they weren't in adjacent steps, which meaned that I was able to use "multiple coils" without a problem. Without STL, I would have run out of timers on most jobs. Be aware (as far as I know) that it can only be used on the old F series and the FX range of PLCs. The A series, QnA and I believe the Q series of PLCs don't allow the use of STL, so if ever you think that you may be moving the code onto a larger platform, then you'll have a problem

Can't really comment on the installation, but we use quite a lot of volumetric flow meters (no moving parts) and the phantom pulses are just an everyday hazard with those things. The manufacturers just say that it's a common thing for moist air to appear to be moving liquid. There seem to be two options ... either fit an additional probe (called a discriminator and supplied by the manufacturer), or write the PLC code so that it ignores the pulses from the meter when it shouldn't be pulsing. I realise that that doesn't explain your problem ,as after 7 years, you would not expect things to change, but I've found that phantom pulses can defy logic and seem to happen when they feel like it, rather than in a definable way.

or http://194.130.244.64/branch/database/serv...amp;portal_id=1

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.

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.

You could check out this thread ... not exactly the same, but similar type of thing. http://forums.mrplc.com/index.php?showtopic=5864&hl=