Recently we have upgraded a 140 NOE 771 00 to kernel+executive version 3.0.

Since that change we have found that the MSTR tasks stopped working.

The project is programmed with Concept v2.5 SR2. We use both Ethernet IO Scanner to aquire data from 10 Momentum I/O bases with 170 ENT 110 01.

In the other hand, we have three Modbus to Ethernet Bridges (174 CEV 300 20). Each Modbus network has 10 slaves, the communication routine is written as a cycle for each bridge/network. 1st slave is polled, then 2nd slave, 3rd...

With only 1 bridge routine programmed, the communication works fine, but when we use the three MSTR routines, the MSTR block starts giving errors and answering the hex status code: 5050!!!

Thanks in advance.

Braulio

 

Additional data:

This error code (5050 hex) has been detected since one of the modbus-ethernet bridge has been disconnected for maintenance tasks in the cabinet it is installed.

As a first aid solution, the reaction has been disabling the polling seqüence to that device.

With a deeper analysis, we have found that after disabling this MSTR block, the other MSTRs recovers in 10-20 seconds.

We will try to improve the communication routines, but we think that the new firmware instead of crashing in case of polling overflow, simply reports 5050 to the program.

Regards,

Braulio

 

I cannot help with the error code you mention and am not completely sure what you are doing, but I know a lot about the internals of the older CEV v1.0 to v1.6 - you have a v2.0, but I assume not much has changed.

The CEV could support at most 10 concurrant sockets - it was published as 8, but that leaves 2 "spare" to handle close/reopen situations & system dynamics. You meanion 10 slaves - that in itself can be a problem with some Masters; some will attempt to open 1 socket to every "destination", which in your case is 10. If the new firmware opens 1 socket per slave (10 per CEV), that could explain why one what you call "bridge routine" would work. It may use 10 sockets to talk to 10 slaves - likely not exactly in parallel, but each open shifted in time a bit. At any time, at least 1 free socket exists in the CEV.

However, your 2nd & 3rd "bridge" would break this if they also try to open 10 sockets each. In a big race condition they'd start to steal closing sockets from the first routine and eventaully ALL routines would be unhappy as NONE could get 10 sockets in the expected time.

If that isn't an answer, perhaps you are hitting up against an internal socket limitation in the Modicon. However I seemed to remember they handled at least 64 sockets in-coming - but I don't know how many out-going. You may need to find some way to run these sequentially - run first "bridge routine", then 2nd, then 3rd. I don't know if that is possible.

I think the only answer will be for you to use an Ethernet sniffer to confirm what is actually happening. This will confirm how many sockets are being used. www.ethereal.com is what I normally use, plus it decodes Modbus/TCP nicely. Frontline and others sell fancier tools that also handle decoding serial Modbus.

- LynnL, www.digi.com

 

Thank you very much for your reply,

We have finally fount the origin of the status code 5050. I think it has some relationship with the number of concurrent sockets opened with the slaves.

The problem was solved increasing the timeout of each MSTR request, instead of going too low (600ms) it was increased to 4000ms. The MSTR auxiliary logic punishes this remote for some cycles, so the impact of a higher timeout in the comm. throughput is reduced.


Regards,

braulio

PD: I'll take a look ath ethereal, sounds very useful, specially on those "strange" cases!

 

I am facing the same problem when trying to read 96 devices from 140NOE77101. I try to program it to enable 16 MSTR blocks each time and using Multiplexer block to take turn to set 16 devices parameter to MSTR.Control.

For one device to update the data, it need to wait the stated MSTR block Enabled another 5 times. (96/16 = 6) The problem is, whenever the MSTR block disable and re-enable. It need some delay time and it is not constant. It will shows error code 5050 at the beginning.

Why will it happen? What is the limitation of the MSTR block? I just know max. 16 blocks can call at the same.

Please help.