Q2AS Ethernet Problem

[Colin Carpenter 10]

 

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.

 

 

Edited 29 Nov 2017 by Colin Carpenter

[Gambit 324]

Well First of all if you use a Q2AS i would use a A1SJ71QE71 module if possible. An A1SJ71E71 should be possible though but than you can't use the parameter setting.
Do you get the error without the program for the A1SJ71E71.

 

 

 

[Colin Carpenter 10]

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

 

[Gambit 324]

Ok That should not be working it should only work for A1SJ71QE71. An A1SJ71QE71 has a dip switch for loading these parameters. SW3.

An A1SJ71E71 doesn't have this switch.

Are you sure you are not running an Ethernet init FB also?

I would take out the Ethernet parameters I am sure the System will not go into error at start-up

 

 

Edited 29 Nov 2017 by Gambit

[Colin Carpenter 10]

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

[Gambit 324]

ok than that should work but SW2 needs to be switched to accept the parameters. But not setting it should not create the error.

But can it be you have the same network number for ethernet as CC-Link or Melsecenet?

[Colin Carpenter 10]

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.

 

 

Edited 29 Nov 2017 by Colin Carpenter

[Gambit 324]

Although it's a slave and you do not have to configure. It is part of network 1. Can you check if the Ethernetcard is set to network number 2 or higher.

 

Edited 29 Nov 2017 by Gambit

[Colin Carpenter 10]

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

[Gambit 324]

The network no is for easy com via multiple networks. As you have melsecnet CC-Link and ethernet I would like to rule out some things like network number in this case

[Colin Carpenter 10]

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 

[Colin Carpenter 10]

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.

 

Edited 29 Nov 2017 by Colin Carpenter