OPC DA в асинхронном режиме

[sergek]

Коллеги, вопрос скорее теоретический. Но поиск не дал результатов.
Как OPC-сервер, работающий в асинхронном режиме с использованием Modbus RTU, связывает ответ устройства с запросом?
Т.е. как он узнает, какому клиенту направить ответ?
В кадре Modbus TCP есть идентификатор транзакции, там понятно. В случае RTU в ответе может даже отсутствовать адрес регистра, т.е. единственная информация, по которой можно связать ответ с запросом - это адрес устройства и номер функции. Но этого недостаточно. Означает ли это, что два клиента, делающих запросы к одному устройству, могут получить чужой ответ?

[Yegor]

Означает ли это, что два клиента, делающих запросы к одному устройству, могут получить чужой ответ?

Два OPC-клиента или два Modbus-клиента (OPC-серверы)?

Если первое, то нет — в обязанности Modbus-OPC-сервера входит планирование очерёдности запросов, т.к. модбас рту это строго запрос-ответ-запрос-ответ-(...). Соответственно, адресов устройств в ответах достаточно для организации таких очередей, а асинхронность на уровне модбас-слейва будет мнимой.

Если второе (у вас в сети два и более мастеров), то да, можно ответов на чужие запросы нахвататься, ибо мультидроп, но в одной сети не должно быть несогласованно работающих мастеров.

[sergek]

Два OPC-клиента или два Modbus-клиента (OPC-серверы)?

Спасибо, что откликнулись, ибо чувствую, что спрашиваю азы Я спрашивал про OPC-клиентов, но мне кажется, без разницы - чьи клиенты - OPC или Modbus. Ведь если я не ошибаюсь, процесс передачи запроса в сеть и процесс ответа устройством не синхронизированы. Они последовательны, т.к. захват шины и передача данных может осуществляться одним устройством или мастером сети, но порядок не определен - по мере готовности ответа и освобождения шины. А отсюда и вопросы.
Например,
1) последовательно сделано два запроса к одному и тому же устройству, с одной функцией, но к разным регистрам. И ответ может быть разный (к примеру, один - ошибка). Как обязано устройство отвечать на эти запросы - в порядке поступления? Т.е. ответить сначала на первый запрос, потом на второй?
2) последовательные запросы к одному устройству, но разные функции. Что-то мне подсказывает, что есть принципиальная возможность, что время выполнения разных функций может существенно отличаться. Может ли в этом случае устройство на второй запрос ответить быстрее, чем на первый? Если так, то ведение очереди на OPC-сервере не поможет.
Чувствую, конечно, что я чего-то не знаю или не понимаю. Прошу, развейте мои сомнения или ткните неразумного в ссылку

[sergek]

Коллеги, в дополнение к предыдущему вопросу - существует аналог OPC DA в Linux?

[ASo]

OPC UA (независимая архитектура от системы).

По посту 3 - смешались в кучу кони, люди. OPC клиент обращается к OPC серверу, а не не MODBUS устройству.

[sergek]

По посту 3 - смешались в кучу кони, люди. OPC клиент обращается к OPC серверу, а не не MODBUS устройству.

Ну да, ну да! Клиент к серверу, сервер к устройству.. А потом обратно. Так как не перепутать, какой ответ серверу отдать клиенту? Они ж такие одинаковые?

UPD. Правда, очень надо понять

[Yegor]

1) последовательно сделано два запроса к одному и тому же устройству, с одной функцией, но к разным регистрам. И ответ может быть разный (к примеру, один - ошибка). Как обязано устройство отвечать на эти запросы - в порядке поступления? Т.е. ответить сначала на первый запрос, потом на второй?

Оно не обязано отвечать никак, пока от него не получен ответ на уже переданный запрос. Если вы сразу шлёте другой запрос вместо того, чтобы убедиться в получении ответа на первый (в том числе сделать повторную попытку), то пеняйте на себя.

Если так, то ведение очереди на OPC-сервере не поможет.

Нормальный OPC-сервер не будет вслепую слать запросы на устройство по прихоти клиента. Клиент подписывается на изменения в определённых тегах, и сервер сам планирует порядок опроса в соответствии со своей конфигурацией и ограничениями протокола между ним и устройством.

[ASo]

Ну да, ну да! Клиент к серверу, сервер к устройству.. А потом обратно. Так как не перепутать, какой ответ серверу отдать клиенту? Они ж такие одинаковые?

Элементарно, Ватсон!
OPC сервер просто не пошлет нового запроса в шину, пока не получит ответа или тайм-аута. И он "помнит", на OPC запрос какого клиента он посылал MODBUS запрос, и ответит именно этому OPC клиенту. Прочие будут ждать.

[sergek]

Клиент подписывается на изменения в определённых тегах, и сервер сам планирует порядок опроса в соответствии со своей конфигурацией и ограничениями протокола между ним и устройством.

Про подписку - отдельный разговор. Тут мне все понятно.

[sergek]

Элементарно, Ватсон!
OPC сервер просто не пошлет нового запроса в шину, пока не получит ответа или тайм-аута. И он "помнит", на OPC запрос какого клиента он посылал MODBUS запрос, и ответит именно этому OPC клиенту. Прочие будут ждать.

Ну вот! Теперь вы мне все разобъяснили, спасибо огромное!