Basic questions:

  • What is the fastest possible update time of values in e.g. WebVisu?
  • Is there a general empirical value for the update time of 'VISU_TASK'?
  • How does the system behave if the update time is set to 'only' 50 ms?
  • Are higher refresh time over 200ms useful to reduce system load?

Answers:

Basically, the limiting values for the CODESYS visualization are always depends on the used system itself.

The standard update times of 150-200ms in the target settings (WebVisu, TargetVisu) under the 'Update rate', and 100ms in the task processing of the 'VISU_TASK':

       

Explanation of the 'Visu-Update Task' rates:

The interaction of the values is as follows:

                  The visible update rate (without inputs) = MAX (cycle time of the VISU-TASK + update rate of the target).


If the VISU-TASK runs fast enough and inputs are pending (e.g. mouse movements), there may be faster updates here.
The default settings (update rate of 200ms, VISU_TASK of 100ms) are a compromise resulting from the following considerations:

  • In the Codesys visualization, it is so that the VISU_TASK can run theoretically arbitrarily fast.
  • In fact, it is only calculated if there is a "request" of a client.
  • Corresponding requests arise on the one hand for cyclic updating of the visualization (redrawing of the visualization), or when inputs are executed in the visualization.
  • The rate at which cyclic updates occur is configured with this property for Target and WebVisu.
  • For cyclic updates, an update rate of 200ms is normally sufficient. With the double rate of the VISU_TASK a sufficiently fast reaction to inputs is usually also possible.
  • With the double rate of the VISU_TASK, a sufficiently fast reaction to inputs is usually also possible.

To the combination of 'Update rate' and 'VISU_TASK':

  • A (numerically) smaller update rate leads to a higher load of the controller because the visualization must be calculated more often.
  • A (numerically) smaller cycle time of the VISU_TASK allows a faster reaction to inputs.
    As long as no inputs are pending, the load on the system does not increase (if the update rate remains constant).

See also....