mappView - handling the time-datatype

Share Info & Ideas
1

Problem

The TIME datatype is a basic-datatype (see Automation studio help)
This data type primarily offers the advantage that times can be written more readable (e.g. T#2s_100ms)
If a variable of type TIME is released in OpcUa, it is assigned as an Int32 value in milliseconds and no unit can be assigned accordingly.
Node binding is therefore not possible.

The display and manipulation in mappView involves some difficulties:

  • Since the variable cannot be assigned a unit, node binding is not possible. The conversion from milliseconds to seconds is not possible as the conversion is not known due to the missing unit.
  • No limits can be assigned to the data type in the OpcUa view.
  • The DateTimeInput widget only offers the option of adjusting times up to seconds. It is not possible to set milliseconds.
    In this case, the widget looks as follows.
    chrome_rxj0TlxvwO
    Milliseconds cannot be set and the display of the buttons is unsatisfactory.

The problem can be solved in different ways:

Variant 1 - Change to integer data type and use NumericInput

A simple variant is to change the variable in the code from the TIME data type to an integer data type. This then still displays milliseconds, but can be provided with a unit. Node binding to a NumericInput is then possible.

Disadvantage
In this variant, the advantage is lost that the values in the application can be written in the style T#2s_200ms. All values must be specified as integers in milliseconds (e.g. 2200).

Variant 2 - NumericInput in a Compound-Widget

Another variant is to place a NumericInput in a compound widget.
However, the value of the application is then not bound directly to the widget, but to a local property.
If the value of the widget changes, this can be recognized in the event action system and the value of the local property multiplied by 1000 can be set.
Conversely, if the local property changes, the value of the widget is divided by 1000.

In this variant, a TIME data type can be bound directly to the compound widget and the value can be specified in milliseconds.
chrome_cHegnH4SsC

Disadvantages
Although the implementation works in this way, the following disadvantage must be taken into account.
If the value cannot be changed due to the permissions of the variable, the widget accepts the value anyway. This must be prevented by the permissions on the compound widget (PermissionOperate).

5 Likes
2

Variant 3 - Use UDINT with unit for mappView and conversion UDINT_TO_TIME/TIME_TO_UDINT at backend side for recipe

Example of test solution:

  • I declared 3 variables
    plcTime - can be used in sw or for recipe
    timeToVisu - plcTime converted to time for visu
    timeFromVisu - time from visu that is converted to plcTime

Time1

  • time conversion logic

Time2

  • Engineering unit configuration, our UDINT variables represent ms

Time3
Time31045×510 89.8 KB

  • in mappView two widgets were added (numeric input and numeric output). Configuration is the same for both of them.
  1. unit was configured to s
  2. node binding was used

Time4
Time41225×589 96.6 KB

  • testing, value 3.2s was inserted using numeric input, value was converted to TIME and back from TIME to UDINT and sent back to numeric output
  1. frontend

Time6

  1. backend

Time7

3

Hello Jaroslav

Thanks for your response and your solution.
Of course, this would be a possible solution.
However, it has some serious disadvantages that you need to be aware of.

  • It needs 3 variables to handle
  • It needs two widgets to handle a time in a configuration.
    This means that 2 bindings are also necessary.
  • It needs two lines of cyclic code for every configuration-variable

This variant works for simple applications where a one-off conversion is required.
However, if countless configuration values of the TIME data type of a machine configuration are to be mapped and changed via the visualization, this variant quickly becomes very time-consuming.

In such situations, it is much easier to handle it in a compound widget as proposed.

Best regards Hannes <°///—<

4

Hi @FIH-RSB, I would say that none of these 3 variants can be marked as a perfect. All of them are in fact workarounds. I just added variant 3 because for the most of the application it can work just fine. The true is that you need at least 2 variables and some logic on backend and this can be seen as a disadvantage.