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:

- Etherlab-Version
- Testmanger-Version
- Amount of Channels and Parameters

Good luck

regards Wilhelm.



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,

Sebastian





_______________________________________________
etherlab-users mailing list
etherlab-users@etherlab.org
http://lists.etherlab.org/mailman/listinfo/etherlab-users



_______________________________________________
etherlab-users mailing list
etherlab-users@etherlab.org
http://lists.etherlab.org/mailman/listinfo/etherlab-users

Reply via email to