Colin Carpenter

MrPLC Member
  • Content count

    436
  • Joined

  • Last visited

Community Reputation

4 Neutral

About Colin Carpenter

  • Rank
    Sparky

Contact Methods

  • Website URL http://www.dairystandardising.co.uk
  • ICQ 0

Profile Information

  • Gender Male
  • Location Trowbridge, England
  • Country England

Recent Profile Visitors

2764 profile views
  1. 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
  2. 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
  3. 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)
  4. 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.        
  5. 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.
  6. 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
  7. 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 ...........  
  8. 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.
  9. 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.
  10. Q2AS Ethernet Problem

    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.  
  11. Q2AS Ethernet Problem

    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 
  12. Q2AS Ethernet Problem

    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
  13. Q2AS Ethernet Problem

    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.    
  14. Q2AS Ethernet Problem

    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
  15. Q2AS Ethernet Problem

    I take your point, but we don't have a A1SJ71QE71 module (and you can't buy them now), however we have several A1SJ71E71N3-T  modules running on Q2AS processors and we've found that they need to be set up in the network parameters section to allocate IP address, group etc (see attached graphic of the currently fine other PLC). This will enable comms from IEC developer, but to allow multiple HMIs to access the PLC by ethernet, I have written a POU using Beijers Function blocks that when it runs in the software will enable all the 8 ports in the ethernet module and  allow the HMIs to talk to the PLC. We have had this running on the test PLC for several weeks without a problem, it's only when we try and install the A1SJ71E71N3-T on the "running" PLC that the problem arises. We cannot recreate the fault on the test PLC which works perfectly. I have tried not compiling the Beijers function block POU, and then downloading, but our issues start before switching into RUN mode, so the issue does seem to be parameter related. When I first dropped the software into the "running" PLC, I had forgotten to delete the parameter set up of the Melsecnet master module  that the test PLC had been using to run the new IO, and even though I discovered this immediately and deleted the Melsecnet parameters, re-downloaded and power cycled the "running" PLC, I'm wondering if the parameters configuration file is corrupted somehow and perhaps it still thinks that there is a Melsecnet master in there somewhere? The only reason I think this is that Error 3101 seems to be related to Melsecnet Link Parameters. Am currently trying to find how to look at the parameters file and determine how to ensure that the new one is written to the PLC without error as this problem defies common sense. Even though I've read all the data register values from the "running" PLC, saved them as a xls file ( to be able to download them if required)and taken photos of all the HMI screens that contain them, I still feel nervous about losing them ...... Thanks