Modbus TCP bug, SpaceLYnk

[FatMax]

Is there anyone here with Schneider Electrics development team or anyone with a email to the developers?

There's been a bug persistent since at least 2.1.0 (maybe even earlier) with regards to Modbus TCP. It seems as if you have multiple TCP devices configured and 1 or more of them doesn't respond (to ping, gets marked red in modbus pane), then no data is exchanged between any modbus tcp devices and SpaceLYnk. 

This bug is also on 2.3.0 FW.

[admin]

Can you post a screenshot of error logs in modbus tab?

[Erwin van der Zwart]

Hi,

I don't think there is a bug, i have done this setup multiple times with all firmware versions without any issues, i think there is another root cause that creates your issue.

To be sure i just created several connections to modbus TCP Smartlinks and Powertags and disconnected one device (red in the modbus tab), the other devices and values just worked as normal.

PS: Our developers / testers are also following this forum (: 

Can you tell me more about your setup, like what devices etcetera?

BR,

Erwin

[FatMax]

The devices are EVLinks from Schneider. All traffic looks normal on Spacelynk and no errors in logs. However, when one EVLink drops out of the network then errors occur on all EVLinks in the network. These are errors in the EVLink logs. We write to a lifebit object on the EVLinks every 8 seconds and if this object is not received then the EVLink goes into safe mode. When 1 or more Evlinks is unreachable then the result is that no EVLink in the network get the Lifebit object from the Spacelynk for some reason (to be clear, all objects behave like this then, we just noticed first on lifebit). This has no effect on the RTU devices, only TCP/IP.

I don’t have access to any EvLinks at the moment, so can’t provide the logs at this time.

[Erwin van der Zwart]

Hi,

The modbus error logs are not showed in the normal error log panel, you can see the modbus error log from the modbus tab and then at the bottom you have another error log button.
Press this button to see the modbus error log(s).

BR,

Erwin

[FatMax]

Hi,

The modbus error logs are not showed in the normal error log panel, you can see the modbus error log from the modbus tab and then at the bottom you have another error log button.
Press this button to see the modbus error log(s).

BR,

Erwin

Yes, I know. But there are only errors for unreachable devices (red ones), no errors upon sending object updates to “working” devices.

If I, for instance, send a 1 to the mentioned lifebit address then I’m expected to get a 0 back within 4 seconds as confirmation. If 1 device in my modbus list has connection issues then communication stops
With every device in the list. If I send a 1 to the same address then I never get that 0 back. It’s also stated in the EVLink log that no lifebit was received and that the EVLink has gone into safe mode.

[Daniel]

Hi
It looks to me that issue is on EVlink side. Nobody else reported any issue with modbus IP and it is widely used.
BR

[FatMax]

Hi
It looks to me that issue is on EVlink side. Nobody else reported any issue with modbus IP and it is widely used.
BR

Is there any logical explanation why a EVLink would not accept incoming communication when a random device is offline that it has no control over at all?

[admin]

For this case you should use scripts instead of modbus mapper. The problem is that all devices on first RTU line and TCP are polled in a single queue. Writing is blocked between reads. And if the device is offline it might time some time for timeout to occur. You can try lowering the timeout value for all TCP devices but it might now solve the issue completely if there are several offline devices at once.

[FatMax]

I see, then there's a logical explanation. Any specific reason why you need to poll in a queue over TCP? RTU i understand why.

Obviously, there should not be any devices disconnected that's setup in the SpaceLYnk, but it can happen and it breaks our software ;-)

I've just tested with lowering the timeout and it did work when 4 was out (bad electricians at work apparantly).We will lower the timeout by default and see if it helps short term - and completely rewrite the software for scripting long term.

Thank you very much!

[admin]

Queue is needed becase there's a single software daemon that handles all communication. It's possible to make it threaded or run a separate instance for each TCP connection but it's too much work at the moment.