Colin Carpenter

I'm afraid that's a new one on me ..... must admit to never having realised that "structured data types" actually existed.

Thanks for that, and it is probably the best way to do it, but it does involve a lot of typing or copying and pasting to do fifty or so global variables ....... It's really annoying as GX Works 2 should be an improvement on the "no longer in development" IEC Developer, and it seems obvious that they built in the mechanism to to do it, but a bug seems to stop it happening. The UK distributor says that he has raised it with Mitsubishi and hopefully there might one day be a fix that allows it to work correctly. Cheers

I've recently started using GX Works 2 ( the latest version V1.580E) having been a long time user of IEC Developer 7.04 and some things I like, and some things I'm not so keen on, but there is one thing that is really puzzling me. In IEC, if I change the name of global variable and click on the "check" button, then all instances of that global variable are updated automatically in the POUs in which that variable is used. Life is sweet. In GX Works 2, if I change the name of a global variable, then I'm told that I have to click on the "Reservation to System Variable" button and then click on the "Reflect to System Variable Database" button to allow all the POU instances of that variable to update, but when I do this, I get the message as shown in the attached png. It's a bit of a pain having to go through and change each instance in the POUs by hand, and am wondering if anyone can tell me what I'm doing wrong? Thanks, Colin

Got a reply from the UK distributor and it turns out that everybody gets this problem when they try to do this. Short of exporting the variables, changing them in a spreadsheet and re-importing, there doesn't seem to be a work around, though there's a video on Youtube showing that GX Works 3 can do it ....... doh!!!!  

As an update on this, we found that Mitsubishi seem to have missed a trick by not keeping up to date with the As-i standards. We installed the Mitsubishi As-i master (V2.11) to our Q01 test mule and then connected a V3.0 slave to it. Initially things looked good as we could address the slave and see the the inputs correctly coming back from the slave. So far, so good, but it all fell apart when we tried to actuate the three solenoid valves on the slave, and found that by activating the 4 bits in the 16 combinations possible, we could get solenoids 2 and 3 to go on or off but in a totally random / no sense order and solenoid 1 refused to actuate at all. Further reading reveals that the V3.0 "slave profile" of the slave is important, and this does not tally with any slave profile supported in V2.11, so we got nowhere. Bent Mitsubishi's ear about keeping up to date with things, but was told that as there was little take up on the card, they lost interest in it and stopped any future development. UK distributors have been very good, so now we're just about to try a CC Link card with a Pepperl and Fuchs gateway, which is pretty much guaranteed by the distributors to work, to the extent that they have promised to get Pepperl and Fuchs on site if it doesn't. Time will tell ...... 

Hi, I'm currently looking at a job involving the installation of lots of process valves, and the intelligent actuators on the valves are capable of communicating using the AS-i interface, and as the  Q PLC has an AS-i card available (QJ71AS92), was wondering if anyone has used this card, and if so, can it be installed and run with IEC Developer, our preferred software? All feedback gratefully received, Thanks, Colin 

The project has now been approved, we have a Mitsubishi AS-i card to play with and a test bench PLC ready to install it on, and in the next week or so, we should have a couple of  Thinktops complete with As-i interface capability to play with, as well as the power supplies, cable fittings etc. Total count of AS-i valves will be in the order of 72, so we'll be looking at two AS-i cards at least. HMI will be the IX Developer range from Beijers and we've already got a fair bit of experience on those, having converted code from older 1000 series HMIs to run on the newer screens, so comms and set up is not a problem now. I'm pretty clued up now about the buffer memories and how they hold the data "to and from" the AS-i slaves, but would appreciate some pointers in terms of "good practice" and spotting issues / errors on the loops to aid in future maintenance etc. Thanks Colin

As an update, I now have an AS-i master card and am looking into the programming of it using the manual, which, as usual is a massive amount of information, but little in the way of "good practice" advice. I've given up on the "configurator" package as it seems expensive and totally related to GX Developer and not to IEC Developer, so have had a good, in depth look at the single page of code in the manual that shows how the 16 bit buffer memory words are converted to individual bits and what those bits actually mean, and it's all starting to make sense. I would like to create a page on the HMI and some code in the PLC that shows dignostics for the AS-i loops (what is out there by comparison with what should be out there etc.) and wonder if anyone has been through this learning curve and could offer some advice. This seems to be one of those Mitsubishi cards that is really short on meaningful manuals, but I'm sure that once it's working it will be fine, and I have a few months to figure it all out. Thanks

Thanks again for the info. The project is looking like it will involve around 100 "stainless steel process valves" as used in the food industry. The valve type varies, some being simple butterfly valves, some "3 port" divert valves and some "4 port" mixproof valves. The valves will almost certainly be fitted with Alfa Laval "Thinktop" heads, each one of which can be fitted with "from 1 to 3" solenoids and each one having two feedback sensors to indicate if the valve shaft has reached the end of it's travel. All are operated by compressed air, with springs to return the valve to the default position. In the past, we've done things the simple way, by having a dedicated PLC output for each solenoid and two dedicated inputs for the "energised" and "de-energised" feedback sensors, with the PLC code flagging up a valve alarm if the the positions of the feedback sensors are wrong for whatever reason. However, to do this job would mean say 120 outputs and say 200 inputs, so the attraction of the As-i interface is much reduced wiring and a much reduced PLC cost, so I can see the benefits. Looking at the manual for the thinktops, AS-I is one of the standard interfaces on those units (Device Net being the other one) and I've heard good things about how well it works and how easy it is to install.  As you rightly say, the AS-i version in the thinktops is V3.0 while the Mitsubishi module still runs at V2.xx, so hopefully this is OK. Reading the manuals of both the AS-i module and the thinktop seems to make perfect sense as all the IO will be binary (on or off) and we're not planning to use it for any analogues (still like the reliability of a 4-20mA signal). I think we'll order up the Mitsubishi AS-i module and have a play on the test rack, but I'm still confused by the constant references to GX Configurator in all the manuals??? Colin 

Thanks for the replies. At the moment the project is still in the "loose stage" in that the only thing that has been defined is that the PLC will be a Q series and that it will communicate with an older Q2AS by ethernet ( which I got working a while ago). I have downloaded the manual for the AS-i card and it does seem fairly straighforward in the way it uses buffer memories to send outputs and receive inputs, but the frequent mentions of "configurator software" confuses me as well as I've never used anything other than IEC Developer ....... must look into it. What is an AS-i gateway .... is that a standalone box that enable comms to Mitsubishi ethernet? Colin

Just as an update, I used the Write_done[0] and Read_done[0] bits to pulse a local variable bit and used the relevant pulsed bit to initiate the read or write instead of the 100ms timer bit and it all works perfectly.  Cheers

Hi, I know this is an old topic, but I'm still not sure how to do this. I have two PLCs that I need to get to communicate with each other .... a new one, yet to be defined, probably a Q03UDE or similar, and an existing Q2AS-S1 with an E71 ethernet card. I have a test bench that allows me to play with a similar set up, and am looking for a fairly simple exchange of data registers going each way. I have downloaded a pdf that explains how to do it in GX Developer, but as always, there are some differences with IEC Developer regarding the settings, and wondered if anyone has actually done this and can, perhaps, point me to some ready made function blocks (perhaps by Mitsubishi or Beijers) that will aid in what should be a fairly simple thing, but probably won't be.... We need to ideally programme in IEC Developer V7.04 for consistency. Thanks in advance, Colin

I'll give it a try next week and see which one of those "done" bits will do the business and report back when I find out which one it is. Thanks for your help, Colin

Thanks for that. Any idea which bit would be the best to use for that ACK bit? I assume it would be one of the bits in the two Boolean Arrays Read_Done and Write_Done, which are set up to be 3 bit arrays (0 - 2)

Good news, I got this working yesterday and it is remarkably simple to do by following the PDF in the link that Daniel provided. I had a Q2AS-S1 CPU and a Q01 CPU, both fitted with relevant E71 ethernet cards at the first slot and just used 2 PLCs rather than the three that were detailed on the PDF. The Q2AS ethernet setup dialogue was missing some of the boxes that the pdf talked about, but the Q01 had them as shown, but it seems that that's not a problem for the Q2AS. I decide to write all the code in the Q2AS ( so that it would READ FROM and WRITE TO the Q01), and the code is shown in the attached graphics. The Q01 just had a single line of meaningless code so so that it had something to work on when switched into RUN mode. It took a while to work out that the READ and WRITE commands happen on the leading edge of the enable signal, so just used a 100 ms pulse bit and everything sprang to life and is still running this morning. Looks good, thanks Daniel.        

Thanks for that Daniel, that looks like it addresses all my requirements, specifically IEC Developer. Will give it a go and report back, Thanks again.

I started programming Mitsubishi's back in the days before the PC had been invented, using a plug in programmer and a cassette tape recorder to store the programmes on (or maybe not in a few cases) The arrival of a laptop and DOS Medoc transformed the whole situation and I found that I always programmed in Instruction Mode (text commands) because it was much quicker, but often checked the ladder option and usually monitored in ladder, and the ability to work in either mode was a huge advantage. I never liked the early Windows versions of GX Developer and remained faithful to DOS Medoc which seemed to do everything  better and faster. About twenty years ago, I was dragged screaming and kicking into the world of structured ladder in Medoc +, which eventually evolved into IEC Developer V7.04 and is still there in GS Works I believe, though I've yet to give up on IEC Developer. Initially I hated structured ladder, but now I would never use anything else, the main reasons being the flexibility, ease of use, and crucially the ability to design the ladder so that when monitoring, all the relevant components can be grouped together in one or two rungs so that everything relevant can be seen on the laptop screen at once. As my programmes kept getting bigger (some are in excess of 30k lines now), this has proved invaluable many times. I also love the "system variables" approach when doing complex calculations in the PLC, as I'm not forced to specify an address for each stage of the calculations, meaning that complex calculations can easily be done in one rung which is easy to monitor. Interestingly, I taught IEC Developer structured ladder to my "young apprentice" and he then went on a Mitsubishi programming course that taught simple ladder (GX Developer) and he is of the same opinion as me. Have never used the structured text option, mainly because in most industries, maintenance electricians can readily understand and monitor ladder (it's so similar to a wiring diagram) but very few will know how to use or read structured text.   I realise I'm probably in the minority, but I guess it's what suits you best ...........  

Like everyone else, my experience of Mitsubishi PLCs is generally one of absolute reliability, with units "just working" for years and years.  The only issues I've had are several output relays failing after tens of thousands of operations, occasional individual analogue inputs failing for some reason on 8 way modules and heat related issues in enclosures that are closed in the height of summer, when temperatures can get pretty high in some locations. The issue on this PLC (which has been running for about 12 years without issue) possibly relates to my programming style, but maybe not: I tend to use a lot of SET and RESET commands for internal flags ( M coils) and then group those flags together on the Y outputs of the various valves and pumps etc to cause things to happen in the real world. This means that if I have a valve or pump that's not running, it's easy to have a look at the flags and determine where the problem is. Without exception, I always use a PLS command to operate the SET or RESET function so that it only happens once  on the rising edge of the relevant rung going TRUE. This is very easy in IEC Developer as the software compiles using a system variable M coil as the pulse address without me having to specify it. This works fine and the software has been "rock solid" for many years, but sometimes (maybe once a year)  I get something I can't explain and my suspicions always fall on whether or not the PLS command M coil was actually active on that one cycle scan when when it's supposed to be, and of course there's no way of monitoring that because it's been and gone in an instant. This can work either way - sometimes Flags don't SET ON when they're supposed to and in the latest instance, it seemed like a Flag SET ON when it was "impossible" for it to do so without a lot of other flags being in the right state. This last instance has never happened before in the 12 year lifetime of the code and is puzzling me because I can't recreate the issue or even see how it happened. Let's say that one of these issues happens once a year and that the cycle scan is 100 ms (it's a big programme), then that means that I'm suspicious once in every 315,360,000 cycles  or so. In most cases I just leave it to see if it happens again and it never does, but it can be hard explaining that to a production manager who has just lost some product. They say that all quantum theory depends on probability, and it almost seems like every so often, things happen that can't be explained ..... or is that just a "get out of jail free" excuse. Puzzled.

In your experience, do old Mitsubishi PLCs just give up the ghost and fail catastrophically , or do they start doing one or two odd things that you can't explain? I just wondered, as an "old faithful" Q2AS-S1 did something the other day that I just can't explain after tens of thousands of hours without issue and a good few hours since without issue. I normally find that it's me that's wrong and not the PLC, but I just can't explain this one without reverting to my "quantum fluctuation" reasoning when all else fails.

OK, it looks like we might have made a break through in this ..... (credit goes to Ryan, my "partner in crime"). On our Melsecnet network, we have a master PLC which has an ethernet card and a Melsecnet Master card. Both have to be defined in network parameters and there is no issue. Everything works well. We had 4 Q2AS PLCs all operating as Melsecnet Local stations, none of which have the Melsecnet Local cards set up in network parameters, but also and crucially, none have an ethernet card fitted. Yesterday we fitted an ethernet card to one of the PLCs and that's when the problems arose on that PLC, with the PLC seemingly confused regarding ethernet and Melsecnet, with the error coming up seemingly defining a Melsecnet problem. Ryan has been trying things out on the test PLC and has discovered that he can re-produce the error message by fitting a Melsecnet Local card into a PLC that has an ethernet card fitted, and has found that he can solve the problem by defining the Melsecnet Local card in network settings (only the address needed, nothing else), and then the error goes away. We'll be testing this out further tomorrow by setting up two test PLCs in their own Melsecnet network and checking that it all works, but it's looking very promising and it actually makes sense, which is always a bonus. Thanks Colin PS I did find a manual that says that ethernet and Melsecnet II are incompatible on the Q2AS - glad we didn't go down that route.  

  Hi, I wonder if anyone has any suggestions for solving a problem that I came across yesterday and have no idea what is causing it. For several weeks now, we have been working on an extension to a process plant that will use a separate PLC complete with a Melsecnet "remote IO" card to run all the IO. To enable testing, we have been using a test base rack with a Q2AS CPU, a Melsecnet card and an ethernet card to run all the new IO. Everything works fine. Yesterday we were due to install the software in the "running PLC" so that it would actually take over the operation of the IO with all the existing IO and negotiated a 2 hour shut down to do this. The running PLC has to have an ethernet card fitted because there will now be three HMIs instead of the one obsolete E900, and this became the the problem. We have also correctly configured the the ethernet card in the network section of IEC and have checked and double checked that this matches  known good settings, and it works perfectly on the test rack. Thanks in advance, Colin The Problem The "running" PLC was installed in 2003 and has run pretty much perfectly ever since. I have attached a graphic of the  IO that is installed on the rack and the problem relates to our attempt to install an A1SJ71E71N3-T ethernet module in the last vacant slot on extension rack three, which would have a start address of 0340h. This set up is very similar to another Q2AS(H)-S1 PLC installed on site which also has three extension racks installed and has an A1SJ71E71N3-T in the last slot. This PLC also has an RS485 module and a twisted pair Melsecnet module attached and has no issues with operating the ethernet module. Perhaps crucially, this other PLC does NOT have a CC Link module (A1SJ71QBR11) installed, but apart from that all the other modules are “run of the mill” modules the same as the problem PLC, but at this stage that is guesswork. The Symptoms. Whenever we power down and  install the  A1SJ71E71N3-T, power back up, the PLC flashes a red light in STOP mode suggesting that the parameters are incorrect. Resetting makes no difference. The red lights on the analogue modules all go off, which they do when the PLC flashes its error liight. The PLC is showing Error 3101 which seems to be related to a MelsecNet/H module and talks about link parameters, incorrect networks etc. This error might suggest that the PLC is confusing the A1SJ71E71N3-T with a MelsecNet/H module??? Using IEC Developer 7.04 ethernet diagnostics, the ethernet module seems fine and monitoring shows exactly what would be expected. It is possible to ping the ethernet module from a laptop and get a reply as expected. We have confirmed that the base address of 0340 is correct by operating Y33F which is the last output on the module before the ethernet module. We suspected it may be an issue with the addressing or perhaps that particular extension rack,  so moved the   A1SJ71E71N3-T to Slot 0 on the base rack, re-configured and still got the same error message. We swapped the CPU with one that we have been using to test with and still got the same error. We changed the A1SJ71E71N3-T to another  (known good) one and still got the same error message. We put the spare CPU and one of the A1SJ71E71N3-T module into our test base rack (no other IO installed), dropped the software into that and everything works fine. The CPU faults out even when in STOP mode, so we are coming to the conclusion that the A1SJ71E71N3-T is clashing with another module installed, and would like to have the time to pull all the modules and test, but the PLC downtime is very limited and any information would be very welcome.    

Yes, you may be right.  Do you know how to discover the network number that CC Link uses? I've attached the graphic of the POU that sets up the CC Link to talk to the FX, and also the (unused) CC Link parameter settings. Spoke to our Mitsubishi suppliers today and they have sent the information on to Mitsubishi as it's such a strange problem. Good talking to you. Thanks 

OK, but the graphic in my second post shows the configuration of the Melsecnet system on the "Melsecnet Master PLC"  and there is no network number assigned to Melsecnet.  I would imagine that this is because our Melsecnet uses the A1SJ71AT21B cards which are Melsecnet/B (I believe) and they use a twisted pair (RS485) communications method, so no network number is required? Presumably they work on a "daisy chain / multi-drop" system as many RS485 systems do? Our problem PLC is currently set to Network 1 on the A1SJ71QE71N3-T, (as is the master PLC and there are no issues with the ethernet on the master PLC.) Thanks

I've attached the photo of the ethernet card with the settings that we are using, but am a bit confused by the SW2 setting, which the manual says should be set to OFF.(also shown on the graphic) Also, I can't work out how the ethernet card would know its IP address if the network parameters were not being used? This problem PLC does have a MelsecNet card in it, but as it's a Local Station, there is no need to configure the MelsecNet card as this is only done in the "Master PLC", and in fact we did this OK yesterday by telling the Master PLC that it had a new slave station attached. None of our other ethernet enabled PLCs are connected to this  this one, and in fact, the problem arises when there is no patch lead into the A1SJ71QE71N3-T. The CC Link card may be the problem as it is unique to this PLC, but it works without any CC Link settings in the parameters. The only setup for the CCLink card is done in software, and the PLC never gets to a point where it will allow the software to run at the moment. Thanks. PS. I've just noticed that the manual says to put SW1 to OFF in normal running, but I know that we also tried this yesterday without any success, but we will put it to OFF in normal running now.    

My apologies. I've just checked with the site and it is actually a A1SJ71QE71N3-T. We'll try what you suggest on the test PLC and see what happens. Pretty sure that SW1, SW3 and SW7 are on, but will have a photo soon to confirm. Thanks