Colin Carpenter
MrPLC Member-
Content count
471 -
Joined
-
Last visited
Posts posted by Colin Carpenter
-
-
I once had an E900 that was set up for FTP transfer, but for some reason, over the course of time, it lost the setting and refused to communicate. You set it up for FTP under SETUP / NETWORK / SERVICES and make sure that the FTP server box is checked. On the older E900s you could hit a combination of keys and check that it was still set up, but not sure about the newer ones. Probably can be done through the dip switches. -
Be careful that you know the differences between firmware and drivers .... I've never yet come across a firmware update for a Mitsubishi A Series PLC (or any other Mitsubishi PLC for that matter.) By that I mean the firmware in the PLC CPU. They are what they are and will always be as far as I know. The driver is the communications software that resides in the HMI only and is used to communicate with the PLC and display the values on the screen etc. You can upgrade firmware on the HMI but be very careful here as I managed to turn one into a doorstop the other day. You are right in that you can select NEVER on the "download driver" option, in this case, E-Designer is comparing the driver on the laptop with the one on the HMI and will update the driver on the HMI if there is a newer one on the laptop if you select ALWAYS or AUTOMATIC. I tend to use NEVER when downloading screens onto systems that are talking to old PLCs ... based on the principle that it works now, it ain't broke, so don't fix it. I assume that the issue with inverting the X addresses works something like this: The PLC knows it's addresses and the programme runs fine. When the HMI driver asks for those X addresses, the PLC hands them over, but then the HMI reads them backwards. So if you put X0 on the screen, it may well show the XF address, or something similar .... but only in the older driver versions? Logically, if you are now using the latest driver (V5.07) and the bug was fixed in V5.04 then it shouldn't happen now. The only way it should happen now is if the latest driver works fine, but the screens were written in a way that reversed the bug (the programmer would have put in XF rather than X0)? But that does seem like a long shot ..... -
I'm a little confused on this, so I downloaded the A Series CPU driver and checked the release notes. As you say, V5.04 "corrected inverted X bits for some models" and was released in Sep 2011. The latest version is V5.07 and was released in Dec 2011. The information would seem to indicate that the fault was noted and corrected in V5.04 and that V5.07 should be fine, so I can't quite see why you have the problem now. Regarding the copying of files, I'm not quite sure how it works, but I get the impression that as E-Designer downloads drivers from the net, I think it "installs" them by writing information to the windows registry. If you run REGEDIT and search on Beijers, you will come across quite a few registry entries that give the information on the drivers. Haven't done that much research to work it out When you install drivers from the net, they definitely do go in the OPC Drivers folder ...... but I also found V5.01 in C:\Program Files\Common Files\Beijers Shared\Micro Drivers ..... More questions and no real answers I'm afraid ...... -
I have a Q03UDE with built in ethernet port, and the IP address is set up by clicking on PLC, then "Built in ethernet port" .... at least it is using IEC Developer. -
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 :) -
Thanks to MItsu for the advice about resolution in Q series PID loops.. I borrowed a Q02 and sure enough, I can now output the MV from the PID loops as 0-12000, which makes my demo run much better. -
That's a bit of a sweeping statement .... for example a Q2AS can handle up to 32 PID loops, while a Q01 can only handle 8 PID loops, and there isn't a Q CPU out there than can handle more than 32 loops that I could find. -
Hmmm .... looks like I'm going to have read up a bit more on PID loops in the Qs. A couple of years ago, I did a job that had 10 PID loops on a Q02 and assumed that the PID loop was working on the 0-2000 range, so multiplied the MV by 6 and fed it to the analogue outputs that were scaled as 0-12000 bits equals 4-20 mA, and sure enough it worked fine in all cases. Would have have been a strange control loop if it had been working on a -32676 to +32767 range!!! Looks like I got lucky on that one. Edit: Further reading confirms the SD registers that you mentioned as being key to how they work. As long as those registers are set to 0 (all bits are 0) then all the PID loops will work on a 0-2000 range. It's only when you set the relevant bits in those rgeisters to 1 that the PLC starts operating on the higher ranges. -
Thanks for the replies. It's got me wondering now if the Q / QnA CPUs can actually have a higher resolution PID loop. For the last 15 years I've been using some PID function blocks that I created using the AnA / AnU PID Programming Manual, and they work fine on QnA and Q CPUs in the real world. Maybe the PID instruction set has moved on without me noticing? Have now downloaded and looked at the PID instruction manual for the Q / QnA / L CPUs, and it seems like the QnA is stuck with a 0-2000 range, Q02 and above can go much larger, but I then bumped into the terms "incomplete and complete derivatives" which seem quite important in the manual, but made me shudder with apprehension. -
Hi, I'm currently working on a demonstration display unit to show the concept of a particular control system. I have a Q2AS-S1 PLC and a nice touch screen. Effectively, I'm trying to demonstrate how the system calculates a "litres per hour" setpoint and then PID controls a valve to land on that setpoint. I'm using real engineering units and the setpoints can range from 1,000 - 11,000 lph depending on the variables. So far so good, but as the PLC is sat on a bench, it has no connection to the real world, so what I would like to do is simulate a flow rate as a function of the PID output, and I would like a high resolution flow rate so that the process value can exactly equal the set point - if the set point is, say, 2546, then I would like the flow rate to be 2546, as this is important for other calculations. Simplest way to do it would be to take the PID Loop output ,multiply it by a factor and asssume that that figure is the flow rate ( a linear relationship). This works fine, apart from one thing. The Q PID Loop works on a 0-2000 basis, so if I multiply the output by 6, then I end up with a 0 - 12,000 lph figure, but the resolution is still only effectively 0-2000, meaning that my flow rates can only be 0, 6, 12, 18, 24 etc. In other words, it can only be exactly the same as the setpoint if the setpoint happens to be divisible by 6. In practice this can lead to a +/- 6 lph error that cannot be improved on. Can anyone think of a mathematical way of simulating the flow so that the resolution can be improved? Thanks. -
I'm really confused now ..... the text from the email from Beijer tech support stated: All QnUDE should be configured with the MC protocol: Our MC protocol driver is considered to be the replacement for the old QnA/Q-series (E71) driver. Which would make me think that the MC driver is a new one? If it was old, I would have thought that it would have installed when installing E-Designer 7.5? Time will tell, will be playing with it soon. Best regards. -
Hi Kaare, I guess it is a little confusing. A couple of years ago, one of the sites that I work on had an anaerobic digester / CHP plant installed and the PLC that controls it is a Q03-UDE. The screen is an E1151 which talks to the PLC by ethernet into its integrated ethernet port. The software that was used for the screen was E-Designer 7.5, and, at the time, there was no MC driver that came with E-Designer. The guy who programmed it asked support what driver he should use and how he should set up the comms in IEC Developer for the Q03's ethernet port. He was told that if he used a later version of the E71 comms driver, that would work. I'm not sure if the MC driver was available at the time, but the system worked OK with the E71 driver, apart from when he was monitoring the PLC with IEC which would then cause other screens on the network to occasionally throw up a BDTP error and require re-booting. I could never get to the bottom of this error, and a few weeks ago, I was chatting to a Mitsubishi engineer and he told me that new ethernet drivers were available, Beijer support told me it was the MC driver, so I went online with my version of E-Designer 7.5 and found this MC driver, which wasn't installed on my version of E-Designer 7.5 I guess the reason for the post is just to say that this driver now exists, and that if you're programming Q or QnA ethernet with Beijer screens, that it's worth downloading, as many of us simply won't be aware that it even exists. I suppose it would come with the later versions of E-Designer, but if you haven't upgraded it is out there. -
Have had a fair amount of experience with this kind of thing, and Kaare makes some very valid points. When you can't get any comms on ethernet, the first thing to start with is the PING command. If the E1000 is out there, then it should reply .... assuming your crossover cable is OK. Using XP Pro, make sure your laptop is set with a fixed IP address in the TCP/IP parameters. If your laptop is (say) 192.168.1.55, then the HMI should be 192.168.1.xxx (where xxx can be from 0-255) I'm sure you know all this, but it's worth saying again. I've also used a Tibbo virtual comm port solution and it's a bit of a nightmare. It kind of works, but often it doesn't. The timeout on the HMI needs to be set to as long as possible when doing online changes on big programmes and it makes a scary scenario into a heart attack scenario because sometimes it will just "hang" with no reason. I had Tibbo working OK with the 32 bit version of Medoc on an FX2N, but when I upgraded the programme to IEC Developer, it just wouldn't work ....... The E71 card is the best option, but they're not that cheap. Failing that, transparent mode works pretty well if you use a null modem cable and the RS232 port on the HMI ..... as long as the cable is less than about 10 metres. Note that the cables for the E1000 range and the earlier range are different .... the main differences being the way pins 2 and 3 are connected. You will tear your hair out using the Tibbo virtual ports .... they're free, but you get what you pay for. -
You learn something every day. Was informed the other day by Beijer tech support that they recommend the MC driver for ethernet comms between their screens and all Q, QnA, E71 comms cards and Qxx-UDE integrated ports. Haven't used it yet, but plan to as I know that using the E71 driver with a Q03-UDE can give some strange results...... Update from the internet with E_Designer and look for the Melsec_MC_ driver. I'd never heard of it and probably wouldn't have found it without a bit of help. Cheers. -
As an end to this tale, I feel I should add that Mitsubishi UK have been very good about this problem and have come up with a solution that I'm very happy with. So, fair's fair, thank you Mitsubishi UK. -
What PID loop software are you using? I've used dozens of PID loops that were written many years ago after wading through the Mitsubishi PID Manual and using the code that was shown in that manual. This code was converted into function blocks for IEC Developer and I now have an ASCII file for 10 loops that I import into most new projects which sets up all the Global Variables and installs the function blocks. I've never actually used the D term (always set this value to 0) and just use the P&I values. These seem to work fine on flow control and temperature control. I generally find that values of 300 to 400 in the P and I constants seem to give a good starting point, and, in the absense of a true understanding of the intricacies of 3 term control, I work on the basic premises that: If the process variable takes a long time to see the effect of a change in the control valve ( say the temperature probe is a long way down the line or there is a lot of thermal inertia in the system), then increase the I constant. A larger I constant makes it more relaxed about changing things too soon .... a kind of "Don't worry .... be happy" approach. The bigger the P constant, the twitchier the system will be and will apply larger corrections which can result in instability. The rest is more guesswork than planning I reckon ..... Oh, and one thing you must be aware of is that PID blocks only work on a 0-2000 range, so if you are using analogue inputs with 0-4000, 0-6000, 0-12000 input ranges, be sure to scale them either in the function block or outside so that they match the 0-2000 bit range. -
I know what you mean .... I don't really like doing screen updates on live systems, as an operator always decides that he needs to get to it immediately after I've started the download. At the moment, the talk is of a new CPU board for the doorstop, but I still find it incredible that you can download software from a manufacturer's website that will effectively kill that manufacturer's products, without so much as a warning screen to tell you that you really ought to check that the software you're using could potentially do this. If it was a cheap phone firmware upgrade using flaky software from a dodgy website, then fair enough if I lose the phone ..... but to be able to toast £2k's worth of equipment using software download from that same respected manufacturer's own website is not really acceptable. Apparently, I'm not the first to do this either ....... which again begs the question of why it's still possible. Grumble, grumble, mutter, mutter ...... -
The sun is shining and the birds are singing and I've got a couple of PLCs with ethernet cards on the bench and a really nice E1101 all powered up and ready to do some testing. I write a small programme to go to the E1101 and E-Deigner tells me that the screen has a firmware version of 1.3 and not the 1.5 version that I was expecting. I remember downloading the V1.5 image loader software from the Beijers web site a while ago, so I fire it up on my laptop and go through the splash screens. Yes, I've got the dip switch in the right position, the HMI screen is waiting for the new software, the MAC address on the screen matches the MAC address showing in the image loader software and all looks good. I press NEXT and the system starts to transfer the software. The green progress bar on the HMI starts to grow, the progress bar on my laptop starts to grow and the birds are still singing. But suddenly the birds go silent, my blood starts to run cold and panic starts to take over. Now the progress bar has stopped growing ..... so I wait, and wait, and wait, and wait, and wait for about half an hour when it becomes clear that the transfer has just stopped. So I stop it, and cycle the power on the HMI ( or should I now call it a dooorstop?) The upshot (according to Beijers) is that I have now corrupted the firmware that allows the HMI to boot to a point where it can communicate. All dip switch positions are tried, but the HMI just sits there showing nothing and refusing to talk to the image loader software. So what did I do wrong? The attached graphic shows the three download options from Beijers, and as you can see, I used the wrong one. I'm pretty disappointed at this state of affairs now ( fuming actually). I'm mad with myself for not taking enough care in ensuring that I was using the right software, but very disappointed that the image loader software wasn't sophisticated enough to realise that the HMI I was trying to modify was not compatible with the software I was using, or, at the very least, it could have included a cautionary splash screen warning that the only firmware it carried were for certain HMIs and to check that the one you were using was in that range. This would have stopped idiots like me from causing mayhem. Luckily the HMI was on a bench, but just imagine if I'd done that on an HMI that was controlling a running process plant!! If anyone knows how to get round this problem without replacing the boards, I would be eternally grateful. Thanks Colin -
I'm currently planning an upgrade of a mish-mash of old FX, FX0 and FX2n PLCs, which will all be replaced by one Q series PLC to do the whole lot. No problems, apart from the fact that one of the FX2Ns uses a high speed counter on X0 to count the pulses from a mass flow meter (somewhere in the range of 100 - 200 pulses per second). As far as I know, the more normal Q PLC don't have high speed inputs as standard, and as I expect that the final programme scan time will be greater than 5 ms, I'm looking for a way to count those pulses. I know that there are dedicated high speed counter modules, but I have in my possession a QI60 16 way interrupt module that I have a suspicion might do the job, but am struggling to find an English manual for the modue, so wondered if anyone has used one and could advise. I've never used pointers and interrupts in a Q before ... so any advice would be very welcome. Thanks, Colin -
I assume that the A1SD62E is a high speed counter card? You can just count pulses in on normal inputs without the need for one of those as long as the pulse width (the time that the input is on) is longer than the scan time of your PLC programme then you will have no problems. It's only when the pulse width is less than the scan time that you need the complexity of high speed counter cards. The reason for this golden rule is that the input image is refreshed at the start of each scan, and if a pulse comes and goes during the time period that the PLC is running the programme ( the scan time) then it just won't notice that pulse. It will notice some (maybe most) of the pulses, but not all. -
These are the settings that worked fine for me with IEC Devloper -
That's a great first post. Thanks for that, it defines the problem beautifully ..... and the work around is nice and elegant as well. -
Thanks Ken, that's interesting ..... do you know if there is a fix for this problem, or is it just one of those things that you have to put up with? I think it would be awkward to use an integer accumulator and still maintain the accuracy of the floating point accumulator. In this instance, the "litres per second" (the number that is being added to the accumulator each second) will range from 0 - 2 lps, so it means that if I used an integer, it would probably round to the nearest whole number (normally either 1 or 2) but the change in accuracy would be huge. In reply to Kaare, the real number is set up as D702 and D703 in global variables, and there are no other references to either of these values anywhere else. The data registers used for the real number that has happily counted to 65 million are the next two (D704 and D705). -
I'm really baffled by this one and wonder if anyone has come across anything like it. I have a Q03 UDE PLC which has happily been integrating a flow meter analogue signal to calculate the amount of litres of a fluid that has passed through the flow meter. Every second, the PLC caculates the "litres per second" from the "litres per hour" signal that is being read into an anlogue input. It then adds this value to a real number that is an ever growing accumalator. Essentially it is a slightly crude integrator that works at 1 second intervals. This has worked fine for many months, but the other day I noticed that the real number had stopped growing, so assumed that the flow meter signal must have developed a fault. I checked it and it was fine, but the accumulator just wasn't growing. It had stopped at 33,554,300 (decimal) and just wouldn't go any further. I wondered if I had exceeded the limits of a real number, but it appears from the manual that real numbers can go up to massive values ..... 10 to the 129 I believe, and there is another real number accumulator in my software that was happily still counting at 67,305,589, so I figured that it was still a valid number. I gave up trying to work out what was wrong, so using IEC, I changed the value of the real number to 0.0, and off it went, happily integrating away as before. Anyone any ideas? Thanks.
Mitsubishi E1101 Recipe
in Mitsubishi
Posted