Quantum to M340 IO scanning sporadically failing

[MR3]

Hi all,

I've got a problem with a Quantum PLC set to IO scan to/from an M340 PLC. The connection is healthy when plugged in but at a random time later will go unhealthy. The only way to reset it is to physically unplug and re-plug the ethernet cable which is not feasible due to operational restrictions. The timeout setting is currently set to 10s and repetition rate to 200ms which seems like more than enough? Schneider's suggestion was that the internal memory buffer of the M340 might be filling up but haven't elaborated on whether this is diagnose-able. Has anyone encountered a similar problem or have advise on how to troubleshoot this?

It's 10 reads and 10 writes in total and the only warnings when the M340 builds are that there's an overlap where my code is trying to read from %MW400.0 at the same time the IO scanning is writing to it.

Thank you!

[Trinxs1]

What is the scan time of the M340?   I would hope that it is about 30-40ms or less.  

1.  I would suggest running this in periodic mode rather than cyclic mode.  Consider the typical and max scan times and select the period to be longer than the maximum with a margin of safety.  This should allow time for the communications to access the memory.

2.  Are you using read/write mode or read mode & write mode.  I would use Read / Write mode where both sets of columns have nonzero values.

3.  In the quantum i would set the timeout to 5 times the scan rate.  That way you can also detect potential network issues.  10s is a long time and the timeout may be masking other issues.

4.  Wireshark is a good friend.  If you can set up an intermediate ethernet tap to check the communications and capture the Modbus TCPIP traffic plus any other traffic this will be helpful.  What other devices are on the same network?  Can any of these interfere with the traffic?

[MR3]

Hi Trinxs, thanks for the advice! Looking at %SW30-32 I'm seeing a max scan time (in cyclic) of 10ms and min of 1ms with the average hovering around 3ms. I've swapped over to periodic mode with a period of 15ms (would you recommend higher?)  and my max time has gone up to 12ms. Given the comms stopping is random I won't be able to tell you if this has worked until later!

[MatthewM]

I have found that I/O scanning entries will very rarely lock up, and they can be reset by making use of the I/O scanning control bit.  Whilst this does not address root cause, it may mean you can get it to reset programmatically, rather than unplugging the ethernet cable.  Use the loss of the activity bit to trigger a pulse of the control bit for the corresponding I/O scanning entry.  If the activity bit remains off for another 5s for example, then you can treat it as an actual comms fault.

[MR3]

Hi Matthew, That sounds interesting and not something I've come across before! I've had a flick through the system bit & word reference manual and wasn't able to find it unfortunately. Please could you send me the %S value?

[MR3]

Hi again Trinxs, unfortunately no luck at a period of 15ms and the comms fell over again. Interestingly this time it at least gave a warning to say that the program period had been exceeded! I've bumped the period up to 25ms now but if you reckon it should go higher then I'm happy with that as well

[MatthewM]

It is not in system data.  Where it is depends on the platform.  For M340 I/O scanning you create instance of T_COM_ETH_BMX located at the CH of the ethernet port.  For Example on a BMXNOE card in slot 1:

The control bits (disable bits in this structure) are down the bottom:

For a Quantum you have to enable it, and then use located bits:

You will have to read the manual for the Quantum on I/O scanning, as the words are in reverse bit order and you need to take care to line up the correct control bit with correct line.

Because you are seeing this often, there must be some other root cause.  This is just a patch to reset it.  When I say I only have seen it rarely that the channel locks up, I mean a couple of times a year, until I put code in to detect and reset the channel, and since then never seen it lock up because it is self managing.

[Trinxs1]

I would double the scan time say to 50ms but ensure that the M340 period is less than or equal to half the quantum scan rate.  It is always good to ensure the scan time of the M340 has at least two PLC scans for each Quantum IO scan. 

if you find this stable the break point is somewhere between 15ms and 50ms so try halving the difference each time until you are satisfied.  If it is not stable try 80ms and then work out the balance point plus a margin.

Did you record the maximum M340 scan time (%SW31)?  This should give you some idea of the next value to use.

[MR3]

Interesting! Thanks Matthew. It's the Quantum that owns the connection/ is doing the scanning and while you're right this won't be a root cause fix it'll be a patch to hopefully get this piece of kit working while we investigate further.

Luckily the control bits are already enabled for %MW1 - 8 . In the data editor though %MW 1 - 8 already exists and is being used in the code as a variable in its own right... Does this mean the self declared variable is overwriting the control bit and the control bit range needs to be set to unused %MWs or am I misunderstanding how to access the control blocks?

[MatthewM · Accepted solution]

If I understand you correctly, the registers used for control are already used in code for something else?  You might have just found your root cause!  If they are being written already for code unrelated to I/O scanning control, it will be playing havoc with your I/O scanning.

[MR3]

Hi Matthew, You are quite right! A number was being set to %MW1 where the binary digit corresponding to my part of the scanning table was being set to 1/off . I ran a test yesterday to see if I could change the number and knock out the comms with a different PLC and it behaved as expected. Frustrating to think this is what I've been chasing for the last couple of weeks and that the network has been fine (or at least I hope so) but it's how it goes. Thank you for your help!