[etherlab-users] Limit of process values in Testmanager/Etherlab App
rehberger at tum.de
Thu Dec 15 19:46:51 CET 2016
Dear Dr. Hagemeister,
thank you very much for the quick feedback. We tried to start Testmanager with above 8MB (e.g. --buffersize=9000000).
Unfortunately either in Windows (Host PC) or Linux (Wine, on the Master-VM) the Testmanager crashes immediately after connecting to the regarding Etherlab app (Etherlab 2.1.0).
We're using the newest Testmanager version 3.6.4. I could not find the documentation for the startup parameter in the about dialog of Testmanager?
Maybe I should mention that the app exchanges data within itself via UDP. Would this interfere with the TCP/IP server of the target app?
We would very much appreciate any further hints and assistance.
Dear Mr Rehberger,
the Testmanager has an internal ringbuffer for storing the process response data (stupid design: I didn't know better at the time I designed that interface). During the connection process the Testmanager requests the channel and parameter lists. If you have really a lot parameters and channels the ringbuffer might overflow resulting in the observed loss. Depending on your version of testmanger the default ringbuffer sizes varies. On newer versions: 3.6.xx it is 8MB big. One can modify the size with the command line argument --buffersize=SIZE [byte]. Other arguments are documented in the text box in the About-Dialog.
Try to incrementally increase the buffersize until the observed behavior vanishes. If that does not work, please provide feedback with:
- Amount of Channels and Parameters
Am 13.12.2016 um 17:37 schrieb Rehberger, Sebastian:
> Dear Etherlab Users,
> is anyone aware of a limit for process values / Simulink blocks used
> for an Etherlab application?
> We're experiencing the following effect: Having a certain amount of
> Simulink blocks and model-depth results in two behaviours:
> 1) the values loose the possibility to be live-tuned / adapted
> during run-time and
> 2) that certain blocks are not shown in the Testmanager process
> tree. That means process data cannot be efficiently logged any more.
> Is there any workaround for that issue, or can anyone guess what we
> are doing wrong?
> Kind regards,
> etherlab-users mailing list
> etherlab-users at etherlab.org
More information about the Etherlab-users