We use DasyLab to record and process measurement data from a PLC. Among others, the ICom-In module is used.
In our case, several TCP servers send streams of (32-bit float) measurement data at 2.5 resp. 10 kHz over a peer-to-peer connection, which are received by DasyLab. The data is bundled into blocks of, for example, 1000 consecutive data points. Each stream uses its own ICom module. The servers use the same IP but different TCP ports. This method generally works fine.
However, the following two problems occur:
DasyLab displays incorrect measurement data.
Below you will find two screenshots of the same data streams. The first one with correctly displayed data on channel 2 and the second one with implausible data (see ordinate). In both cases, the data is correctly received by the DasyLab device (verified by analyzing and visualizing the received TCP packets using Wireshark).
Therefore, we conclude that the problem lies with DasyLab. The issue occurs sporadically on different channels. Restarting the measurement occasionally fixes the problem but potentially leads to the same problem on another measurement channel. If all channels work correctly at the start of the measurement, they will do so for the entire duration of the respective measurement.
DasyLab fails to receive higher throughput data in real-time.
For example, if two channels at 2.5 kHz and one channel at 10 kHz are streamed, the display of the 10 kHz channel falls further and further behind until the connection aborts. By analyzing the TCP traffic, a filling receiving buffer of the DasyLab-side 10 kHz TCP socket can be discovered. It was also demonstrated with a dummy application that it is generally possible to receive the data of a 10 kHz channel and additionally that of 10 (!) 2.5 kHz channels without any problems network-wise and system-wise.
Therefore, we conclude that there is a performance problem with DasyLab. This limitation is permanent. Streaming 10 channels at 2.5 kHz each (without an additional 10 kHz channel) is possible in DasyLab without any problems. Below you will find the exemplary configuration of an ICOM module.
Both problems occur in the utilized DasyLab version 2016 as well as in the current version (2022). The performance of the DasyLab system and the server PLC is also not a problem.
With the described methods, we were able to rule out an error on our side. Please let me know what we can do to fix the issue.
Question
PLCuser
We use DasyLab to record and process measurement data from a PLC. Among others, the ICom-In module is used.
In our case, several TCP servers send streams of (32-bit float) measurement data at 2.5 resp. 10 kHz over a peer-to-peer connection, which are received by DasyLab. The data is bundled into blocks of, for example, 1000 consecutive data points. Each stream uses its own ICom module. The servers use the same IP but different TCP ports. This method generally works fine.
However, the following two problems occur:
Below you will find two screenshots of the same data streams. The first one with correctly displayed data on channel 2 and the second one with implausible data (see ordinate). In both cases, the data is correctly received by the DasyLab device (verified by analyzing and visualizing the received TCP packets using Wireshark).
Therefore, we conclude that the problem lies with DasyLab. The issue occurs sporadically on different channels. Restarting the measurement occasionally fixes the problem but potentially leads to the same problem on another measurement channel. If all channels work correctly at the start of the measurement, they will do so for the entire duration of the respective measurement.
For example, if two channels at 2.5 kHz and one channel at 10 kHz are streamed, the display of the 10 kHz channel falls further and further behind until the connection aborts. By analyzing the TCP traffic, a filling receiving buffer of the DasyLab-side 10 kHz TCP socket can be discovered. It was also demonstrated with a dummy application that it is generally possible to receive the data of a 10 kHz channel and additionally that of 10 (!) 2.5 kHz channels without any problems network-wise and system-wise.
Therefore, we conclude that there is a performance problem with DasyLab. This limitation is permanent. Streaming 10 channels at 2.5 kHz each (without an additional 10 kHz channel) is possible in DasyLab without any problems. Below you will find the exemplary configuration of an ICOM module.
Both problems occur in the utilized DasyLab version 2016 as well as in the current version (2022). The performance of the DasyLab system and the server PLC is also not a problem.
With the described methods, we were able to rule out an error on our side. Please let me know what we can do to fix the issue.
Thank you and best regards
Link to comment
Share on other sites
0 answers to this question
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now