Colin Carpenter

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).

When you say an output fault, could you say a little more about how the fault shows up. The output lights on the A1sY10 card will come on using power that the PLC picks up from the back plane, but there are separate 24VDC+ and 0V connection that need to be wired to the card to actually cause the relay contacts to change state. Without that 24 VDC, the lights will come on but nothing will happen at the output terminals. The relay contacts are rated at 2 Amps, and seem very reliable. I have occasionally know an output relay with a faulty terminals, but they're rare. I think I'd be looking hard at the field wiring of the items connected to the outputs that are playing up?

Wonder if I could tap on the assembled knowledge for a bit of advice please? For donkeys years, I've been programming Mitsubishi PLCs without ever really using latch coils (L) and have always used non latching coils (M). I always set up the PLCs so that the data registers (D) are battery backed and cannot be cleared by the key on the PLC, meaning that setpoints etc are never cleared by using the key switch. I currently have a Q2AS PLC which is operating a busy food processing plant and doing online changes are becoming a bit of a challenge, as any changes that need to be done are invariably changes throughout the entire programme, and the online change mode shows that the changes are normally just too big without stopping the CPU and downloading the programme. To do this, I normally have to negotiate a time with process operator when the plants are all on water so that I can stop the PLC, download the programme and restart the CPU (and the plant) in the same state that it was when I stopped the CPU. I generally use SET flags to indicate the status of the plant, so that as long as I don't have to use the key to reset the CPU, everything fires back up OK. Most of the time it works fine, but no comms process is totally reliable in my opinion, and yesterday, the STOP CPU command sent by IEC to the CPU via the E71 card stopped the CPU and then stopped the comms as well .... a kind of a limbo land. I whipped out the trusty SC09 cable, went diirect from my serial port to the CPU and downloaded the programme OK, but when I tried to restart the CPU from IEC, it said that the CPU was waiting for something else to do that. It was, frankly, confused. So I had to resort to a reset, the CPU fired up and all was well, but of course it had reset all my SET M coils, so the plant forgot where it was and I spent the next hour having to go through the programme to get the plant back where it was before I started playing with it. Now, part of me says, well just change all the M coils in the software to L coils, then a normal key reset ( not a Latch Clear reset) will allow the coils to remember where they were before the PLC was stopped, but I have a strange reluctance to do that which I cannot really explain ...... hence the question. All advice gratefully received. Thanks.

I seem to remember that was the case, because instead of buying a Q03, I actually spent more money buying a Q02 with an E71 ethernet card thinking that ethernet comms would be the way to go on this particular job, and I actually have a couple of PDFs from tech support showing how to set read and write up using the E71s. Eventually we went for Melsecnet as well, because it seemed that most of the ethernet comms set up was a bit vague, and the PLC I had to talk to could be shut down once in a blue moon and only at around 3 am for about 10 minutes. Like you, I wasn't going to buy another couple of Q02s with E71 cards to play about with to make sure that I could get the comms working, so decided that the best way was the bombproof, foolproof Melsecnet cards that only require a reset on the master (station 0) card, and it worked like a charm. On another site, I've used the Beijers Mac Terminal to transfer the data between a Q03 and an old Q2AS, and that works fine. You can either write some code in the PLCs and set up the BDTP options in the screen (Beijers Data Transfer Protocol) or you can use the Beijers data exchange function. Initially I couldn't get that to work, but in hindsight, I think the Q03 requires a "power off" reset to force it to read ethernet parameters and we hadn't realised that. By the time we did, the BDTP comms was working fine so I just left it. Better the devil you know. Only thing about the BDTP option though is that it's not that fast .... update times measured in seconds rather than milli seconds, which I think is down to the handshaking and the fact that the HMI is also displaying screens and talking to the Q2AS at the same time. "MItsu" is pretty good at this, so I may well be barking up the wrong tree, it's just that with a 20,000 line programme to commission, I just want the comms to work "out of the box". "Maybe" is not an option.

In my humble opinion, ethernet "peer to peer" comms is something that Mitsubishi needs to address to make it so much simpler for the end user. I may well be wrong in this, but I seem to remember being told by Tech Support that it wasn't possible to do "PLC to PLC" comms using the built in ethernet ports on the Q03 CPUs. That may be wrong and it may have now been fixed, but I came to the conclusion that it wasn't worth the effort to find out, and we installed some Melsecnet cards that are an absolute doddle and need no code written at all ..... soooo simple. When I spent a day or so looking into Mitsubishi ethernet comms using E71 cards, once again, it's poorly documented and expects me to be an expert in ethernet comms as well as in the plant I'm trying to control. The only IEC function blocks I could find were by Beijers ( the best), but even those seemed to require resets of the PLCs which is not simple on a running plant. Allen Bradley really has got this so much better .... insert the read command, specify the IP address of the other PLC, the starting register and the number of registers you want read, the comms interval and where you want those registers to go in the local PLC and it just works. If you want to write to the other PLC, just use a different command. It's that easy and Mitsubishi should really be following their example on this one. Mr Grumpy.

There are two ways that an FX can store the program - either in battery backed RAM or using an EEprom module. To find out if an EEprom module is fitted, pull the front cover off of the FX and you will see an EEprom fitted if there is one. On the top right (I think) there is a switch that enables or disables writing the programme to the EEprom. If disabled, then nothing you do send will be remembered, though the download will appear to go fine. The rules are: If no EEprom is ftted, then the PLC will read the programme stored in RAM. If the battery is good, then the programme will be retained on power off. If the battery is bad, then the programme will be lost on power off (few minutes). If an EEprom is fitted, then the PLC will always run the programme on the EEprom, regardless of what is in RAM. If it was me, I'd make sure the battery was good, pull the EEprom out and programme the RAM. If it works well, then leave it in and run it on battery backed RAM. I've never used EEproms unless working on someone else's PLCs with EEprom fitted. As long as it is an FX, it's all pretty easy. If it was on old F1 or F2 then that's a very different animal when it comes to EEproms.

Not exactly sure how or if you can do it direct to USB, but you can certainly do it by connecting to the screen with Beijer's HMI Tools FTP client software. The directory structure in the HMI will then show itself and any trends that you have set up will automatically create *.CSV files which can be transferred by FTP and opened in a spreadsheet. The number of readings available depends on the settings in the trend.

Well, I'm getting there, but not quite there yet. I downloaded the files from Beijers and opened the ASCII file into IEC. Downloaded the programme into the Q2AS-S1 and couldn't get anything to run, so deleted th parameters code and set the parameters in IEC. Downloaded and the ethernet comms now works. Have managed to get an E900 with ethernet card happily talking to the PLC through ethernet now, but it will only read from the PLC. As soon as I attempt to write from the HMI to the PLC I get a comm error. Noticed that connection type is being set to 8003h, which enables the HMI to read from, but not write to the PLC. E71 manual suggests that I have to set up two connections to make it read and write by enabling "pairing", but can't work out whether a connection is a port or something else. Still playing but hair is rapidly disappearing. This is the hardest thing I've ever done I think ... nothing should be this hard to set up in 2011 surely??? EDIT. Solved it ... switch 7 on the ethenet card has to be ON

Does anyone know of an "Idiot's guide to installing ethernet cards" on a QnA? Am trying to retrofit an A1SJ71QE71-B2 ethernet card to a Q2AS-S1 so that it will talk to my laptop ( IEC Developer) and three E1100 HMIs. I have the card and have sorted out the RJ45 to BNC connections, terminators etc and can now go online to the PLC using ethernet .... lost a bit of hair along the way and the rack was in dire danger of ending up in the garden at some points, and it's now working, but I'm not really sure how. To cut a long story short, it seems to me like the old A series with their E71 cards had to be set up using code in the PLCs ( buffers, from, to etc) and the new Q series PLCs have no need of any any code, as everything is configured in the parameters section - the number of connections, type, port numbers etc. But the QnA range seems to be a halfway house between the two, in that you can define the cards IP address, station number etc in the parameters section, but the section that allows you to set up the number and type of connections is missing, therefore I assume that it must be done in the code, and that's where I'm drawing a blank. I've downloaded the manual (all 38 mb of it) and it sets new standards in gobbledegook. Bits are starting to make sense, but every page I read, I end up with more things that I don't know and as the manual is scanned, searching for text is impossible. I like a challenge, but just fitting an ethernet comms card to something so that it talks to something else should really be a bit easier these days?

Thanks, Patrik, I think you might have just saved me a lot of work, yet again. Have downloaded the file and will try them out tomorrow. While you're here, could I just ask one more question - there seems to be a general feeling that Beijers screens are better set up for comms using UDP rather than TCP. In your experience, would you say that was true? Thanks again, Colin

If your'e using IEC Developer, you're welcome to use the Scale with Parameters Function Block that I wrote the other day. It can be found in the thread here

I'm often baffled, but this one has really got me stumped and I think I may be missing something that's staring me in the face because it's so obvious, but I just can't see it. Attached is a graphic of the code that's baffling me. PLC is a Q02 and software is IEC DEveloper v7.04. Effectively, there are three flags which are "pulse set" whenever certain conditions become true. Any of those three flags being set will cause the timer to run for half a second and the timer timing out will "pulse reset" all three flags. Works fine when I toggle on any of the three flags, so I know the addresses are correct etc, and there are no other instances of the flag addresses being written to anywhere in the programme. Last night I got the call that there was a problem and when we went online to have a look, all three flags were set ON. PLC was running fine, no errors, no other problems. Toggled off the three flags and toggled each one on in turn, and they correctly reset half a second later. Question is, how could that happen? I have no idea other than a quantum fluctuation, but that's a bit of a cop out. Have since re-written the code so that each flag has an individual timer which just resets that particular flag as I think that having three inputs related to the timer may have something to do with it, but I can't make it go wrong, and it obviously did.......

I take your point, but when I test it, it works .... but last night all three bits were set and not re-set. Spooky

Well spotted, I think you're right that it would be ENO bit that would enable something else to be tacked onto the timer. Which timer do you tend to use most often?

Absolutely ... they are definitely system generated variables, in fact that's one of big advantages of IEC in that you don't have to define the addresses of bits that you don't need to know. For example, I don't define the address of the PLS bits, but the compiler creates them for me when it produces the IL code, and it uses addresses taken from the defined system address area. I just can't work out why it produces an OUT M5787 instruction with the OUT instruction for T58. It has no use as far as I can see ......

Thanks, you're right ... I never knew that ... learn something every day. Have attached the graphic of the IL code of that network and it all looks perfectly OK to me, apart from a couple of OUT instructions system M coils that have been added for some reason ( marked in red). I have no idea what these are used for in the programme, especially the second marked one which comes on when T58 is timing?

That was quick. Thanks for that and I see your point, but when the code is compiled, downloaded and tested and it works, then surely it must have compiled in the correct way. Once downloaded, the compiled code won't change in the PLC, so it should just carry on working? I have used hundreds of examples of similar code working with the same rungs and never had such a strange problem before and one which I can't simulate at the moment. I often wish that IEC would let you export the compiled code to a text file so that you could check it out without having to download it to a PLC and then pull it back up again into an instruction POU. Sometimes it would make life a bit easier at times like this. And won't the PLS instructions mean that the sets and resets are carried out at different times? Thanks.

Thought I'd try that in IEC Developer V7.04 and sure enough, you can actually give a name to a single bit of a D word. Well spotted.

I've been given a job to convert a programme from an Allen Bradley SLC500 to an existing Mitsubishi Q02 PLC. I have the programme from the AB PLC and can view all sections, addresses, comments etc. The Mitsubishi programme will be written in IEC Developer V7.40 in "graphic ladder" mode. Although the Allen Bradley IO count is not huge, ( 8 analogue ins, 4 analogue outs, 24 digital ins, 16 digital outs), the programme is pretty long and complicated and it's controlling a set of equipment that I know very little about, so I have two methods that I can employ .... either go through the code and work out how the thing works, then write new Mitsubishi code accordingly, or, just copy all the code from the SLC500, work out how to re-programme some of the AB commands that I'm not sure of, and hope that I work out how the hardware works as I'm going through it. I get the impression that the first method would take a long time to understand, and my resultant code would probably be strewn with bugs as there are bound to be things that I don't really understand about the hardware, so I'm tempted to go for the "mind numbingly boring" second option, which just copies the code. So, if I did go for this method, I now have the problem of making sure that I get all the internal bits and words correctly translated to their correct Mitsubishi addresses. I've thought of various ways of attacking this, but to date haven't really come up with a perfect method. Human errors in translating the addresses will be the biggest problem for me as concentration wanes. The SLC500 uses "word and bit" addressing for it's internal elements, for example B3:10/7 means (File 3) (Word 10) (Bit 7), but Mitsubishi internal bits are just defined as Mxxxxx where xxxxx is a decimal number. The SLC500 is adress based, so the address has to be typed in and the description and symbol names will come in accordingly. The IEC software is "name based" with the address lookup table being defined in the global variables. I have considered using the "word and bit" addressing system to write the code ( say I map B3:10 to D2000, then B3:10/7 can be writted as D2000.7 in IEC), which I'm tempted to do for accuracy, but then I end up with a programme written with addresses not names, which will make fault finding a little difficult, and I don't know a way in IEC of converting the addresses to names without lots of cutting and pasting. I'm rambling a bit here, but you can see the things I've considered, and I just wondered if anyone else has had to do this and what method they employed? Thanks, Colin

Thanks for all the replies and it's good to know that I've not missed anything and that there is no real foolproof method of doing this. I exported the database from the AB software into Excel, then spent a morning going through and allocating Mitsubishi addresses in the form Dxxxx.x to keep faithful to the word and bit address format of the original, then imported the database back into the software to have a look and it possibly looks larger, scarier and more complicated than it did before. I'm coming to the conclusion that this is one piece of software that's better left on an AB PLC ... especially when I noticed that there are DH+ comms involved to other PLCs, so I think I might be stepping backwards from this one, after strongly suggesting to the customer that he stays with the AB. I'm sure it could be done with a lot of time and effort, but I could also end up in a right old mess .....

In the end I scrapped the idea and used a BDTP slave / master configuration to use the 2 HMIs to exchange data between the 2 PLCs. It seems like I missed a major point that the Q03 PLC must be powered down and then powered back up to make it see the new channel that has been configured, then apparently the comms will work. I think that 4 channels is the way to go, but remember to cycle the power on the PLC. In the end, the data exchange side was worrying me as there were odd random things happening and bits being switched on that should never have come on, so I abandoned the idea. Even now, we believe that we have found a weakness in the BDTP protocol, as whenever the effluent plant programmer goes on line with IEC through the ethernet to talk to the Q03, then any of the 4 screens that are plugged into the network will come up with an obscure error message saying something like "max no. of clients greater than max no. allowed." and the screen then requires a reboot.. This only ever happens when the programmer is on site and communicating with the Q03, and it happens to one screen or another at about 20 minute intervals. Oh the joys of comms .... it's still a black art ....

Well, after many years with all sorts of Mitsubishi's, the time has come for my first "new build" project using the Q series, but the question is, what do you think I should use? I have three or four systems using Q2AS-S1 CPUs, each of which has the maximum number of three extension racks, so they're reasonable size projects. The maximum number of steps is around 22,000 out of the 64k allowed, so they're easily big enough. Tend to use 32 way digital input cards, 16 way relay output cards, 8 way analogue input cards (both voltage and current) and 8 way analogue output cards. Comms is generally through the RS422 CPU ports and generally in transparent mode from Beijers HMIs. They all work fine and maximum scan time is in the region of 50 ms, which would be nice if it was a little quicker, but it's not really a problem. Would be good if floating point calculations were quicker as these seem to slow the QnAs down fairly rapidly. So please could you tell me which CPUs you tend to go for given that I'd like to at least emulate the old faithful Q2A-S1 breed that I'm very familiar with.

In the Allen Bradley world there's a very useful function called SCP (Scale with parameters.) This means that you can chuck a value into it, tell the command the start and end points of the two straight lines and the command will convert the value into the new value. This is very useful when scaling analogue input bits into engineering units for use in the calculations in the programme. For example, using a Q68ADI analogue input set at high resolution and at 0-20 ma range, a 0-100C temperature probe would scale 2,400 - 12,000 bits. Without the function, it's a case of solving two simultaneous equations to calculate the m and c values of the straight line equation y = mx+c. In my case, I tend to cheat and use the analogue scaling box in E-designer to give me the m and c values (called the gain and offset ), but it's a bit of a fiddle and often I have to guess the ranges of the instruments that the customer is supplying then go through the process again when commissioning. It would be really handy if this function existed in the Mitsubishi world, but I've never seen it or heard of it. Has anyone else? Cheers

Thanks for all the replies. I figured I'd dust off my old function block skills and see if I could come up with a FB that worked, and it seems fine, so have attached it with a screenshot showing four instances running on a Q02 PLC. All the inputs on the left are integers (should be self explanatory from the screenshot) and there are two outputs - one an integer and one real number for proper calculations. The FB uses real numbers to solve the two simultaneous equations, calculates m and c and uses them to scale the output depending on the input. Hope you like it. Cheers FB_SCP_INT.zip