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