Colin Carpenter

MrPLC Member
  • Content count

  • Joined

  • Last visited

Community Reputation

4 Neutral

About Colin Carpenter

  • Rank

Contact Methods

  • Website URL
  • ICQ 0

Profile Information

  • Gender Male
  • Location Trowbridge, England
  • Country England

Recent Profile Visitors

2914 profile views
  1. IEC Developer and the AS-i interface

    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 ...... 
  2. IEC Developer and the AS-i interface

    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
  3. IEC Developer and the AS-i interface

    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
  4. IEC Developer and the AS-i interface

    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 
  5. IEC Developer and the AS-i interface

    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
  6. IEC Developer and the AS-i interface

    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 
  7. IEC Developer Ethernet Peer to Peer Comms

    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
  8. IEC Developer Ethernet Peer to Peer Comms

    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
  9. IEC Developer Ethernet Peer to Peer Comms

    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)
  10. IEC Developer Ethernet Peer to Peer Comms

    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.        
  11. IEC Developer Ethernet Peer to Peer Comms

    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.
  12. IEC Developer Ethernet Peer to Peer Comms

    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
  13. What is the benefit of using Structured programming?

    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 ...........  
  14. How do PLCs fade away?

    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.
  15. How do PLCs fade away?

    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.