OP C UA Milo - Коллекция отслеживаемых элементов в обратном вызове onDataChangeNotification - PullRequest
Новая
       23

OP C UA Milo - Коллекция отслеживаемых элементов в обратном вызове onDataChangeNotification

0 голосов
/ 22 января 2020

Я тестирую некоторые вещи с помощью SubscriptionExample проекта Eclipse Milo OP C -UA (https://github.com/eclipse/milo) и обнаружил поведение, которое, я не уверен, предназначено. Я создал два MonitoredItemCreateRequests для каждого из двух разных узлов на тестовом сервере Milo (op c .tcp: //milo.digitalpetri.com: 62541 / milo /) и передал их методу createMonitoredItems () подписки. Код статуса для обоих предметов хорош. Поскольку я хочу получить все собранные значения для обоих отслеживаемых элементов одновременно, я добавил NotificationListener в подписку. 

NodeId dynNodeId = NodeId.parse("ns=2;s=Dynamic/RandomInt32");
NodeId statNodeId = NodeId.parse("ns=2;s=Dynamic/RandomDouble");

Вот метод обратного вызова для получения значений данных: 

@Override
public void onDataChangeNotification(UaSubscription subscription, List<UaMonitoredItem> monitoredItems, List<DataValue> dataValues, DateTime publishTime) {
        Iterator<UaMonitoredItem> itemIterator = monitoredItems.iterator();
        Iterator<DataValue> dataValueIterator = dataValues.iterator();

        while(itemIterator.hasNext() && dataValueIterator.hasNext()) {
            logger.info("subscription value received: item={}, value={}",
                    itemIterator.next().getReadValueId().getNodeId(), dataValueIterator.next().getValue());
        }
    }

Я ожидал, что список monitoredItems содержит элементы с идентификатором узла OP C -UA в порядке, соответствующем списку dataValues. Отладкой можно увидеть, что размеры обеих коллекций равны - это нормально. Но все отслеживаемые элементы в обратном вызове имеют одинаковый идентификатор узла? Идентификатор узла для зарегистрированных значений Double должен иметь идентификатор ns = 2; s = Dynamic / RandomDouble. 

15:32:01.221 [milo-shared-thread-pool-0] INFO  o.e.m.e.client.SubscriptionExample - subscription value received: item=NodeId{ns=2, id=Dynamic/RandomInt32}, value=Variant{value=0.19167566173987927}
15:32:01.221 [milo-shared-thread-pool-0] INFO  o.e.m.e.client.SubscriptionExample - subscription value received: item=NodeId{ns=2, id=Dynamic/RandomInt32}, value=Variant{value=0.17914743791503218}
15:32:01.221 [milo-shared-thread-pool-0] INFO  o.e.m.e.client.SubscriptionExample - subscription value received: item=NodeId{ns=2, id=Dynamic/RandomInt32}, value=Variant{value=-1911450762}
15:32:01.221 [milo-shared-thread-pool-0] INFO  o.e.m.e.client.SubscriptionExample - subscription value received: item=NodeId{ns=2, id=Dynamic/RandomInt32}, value=Variant{value=-238565139}
15:32:02.172 [milo-shared-thread-pool-1] INFO  o.e.m.e.client.SubscriptionExample - subscription value received: item=NodeId{ns=2, id=Dynamic/RandomInt32}, value=Variant{value=0.004420353528696297}
15:32:02.173 [milo-shared-thread-pool-1] INFO  o.e.m.e.client.SubscriptionExample - subscription value received: item=NodeId{ns=2, id=Dynamic/RandomInt32}, value=Variant{value=1391780361}
15:32:03.171 [milo-shared-thread-pool-2] INFO  o.e.m.e.client.SubscriptionExample - subscription value received: item=NodeId{ns=2, id=Dynamic/RandomInt32}, value=Variant{value=0.5815483661983246}
15:32:03.172 [milo-shared-thread-pool-2] INFO  o.e.m.e.client.SubscriptionExample - subscription value received: item=NodeId{ns=2, id=Dynamic/RandomInt32}, value=Variant{value=560950904}
15:32:04.245 [milo-shared-thread-pool-2] INFO  o.e.m.e.client.SubscriptionExample - subscription value received: item=NodeId{ns=2, id=Dynamic/RandomInt32}, value=Variant{value=0.18123040450226635}
15:32:04.246 [milo-shared-thread-pool-2] INFO  o.e.m.e.client.SubscriptionExample - subscription value received: item=NodeId{ns=2, id=Dynamic/RandomInt32}, value=Variant{value=521198031}
15:32:05.258 [milo-shared-thread-pool-2] INFO  o.e.m.e.client.SubscriptionExample - subscription value received: item=NodeId{ns=2, id=Dynamic/RandomInt32}, value=Variant{value=0.42193483414925215}
15:32:05.258 [milo-shared-thread-pool-2] INFO  o.e.m.e.client.SubscriptionExample - subscription value received: item=NodeId{ns=2, id=Dynamic/RandomInt32}, value=Variant{value=680732464}

Мне известно о возможности использования отдельного обратного вызова для каждого узла, но я хочу обрабатывать их все сразу.

Это поведение предназначено или это может быть ошибка в реализации сервера?

Редактировать:

Во время отладки я обнаружил, что коллекция monitoredItems в обратном вызове содержит x раз один и тот же объект (один и тот же адрес памяти), но x dataValues ​​различаются.

То же поведение, если я попробую его с локальным сервером OP C из примера milo.

1 Ответ

0 голосов
/ 23 января 2020

Возможно, вы использовали одно и то же значение clientHandle в обоих ваших элементах MonitoringParameters, когда создавали их.

Если нет, вы можете опубликовать весь пример кода?

...