Posts: 219
Threads: 44
Joined: Nov 2015
Reputation:
2
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.
Posts: 7720
Threads: 42
Joined: Jun 2015
Reputation:
446
Can you post a screenshot of error logs in modbus tab?
Posts: 1759
Threads: 6
Joined: Jul 2015
Reputation:
115
28.09.2018, 07:32
(This post was last modified: 28.09.2018, 07:38 by 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
Posts: 219
Threads: 44
Joined: Nov 2015
Reputation:
2
28.09.2018, 08:45
(This post was last modified: 28.09.2018, 08:49 by 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.
Posts: 1759
Threads: 6
Joined: Jul 2015
Reputation:
115
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
Posts: 4572
Threads: 23
Joined: Aug 2017
Reputation:
206
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
------------------------------
Ctrl+F5
Posts: 7720
Threads: 42
Joined: Jun 2015
Reputation:
446
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.
Posts: 219
Threads: 44
Joined: Nov 2015
Reputation:
2
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!
Posts: 7720
Threads: 42
Joined: Jun 2015
Reputation:
446
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.