Вот опишите алгоритм идентификации пакета, пришедшего от разных соединений? Как прибор должен понять что это на самом деле попытка мастером опросить снова пакет, не полученный ранее? А не просто ещё один запрос, пусть по тому же адресу?Сообщение от melky
А если надо каждые 5 мс опрашивать - это повторы или уникальные запросы?
Тролль-наседка, добрый, нежный и ласковый
А что там описывать? вы знаете с какого IP и на какой порт пришел запрос, если у вас сквозной преобразователь протокола из TCP сети в RTU так сложно запомнить на какой адрес устройства и какие регистры запрашиваются и в каком количестве ?
Честно не сталкивался с преобразователями протоколов на лету, обычно железка сама настраивается на чтение регистров slave RTU устройств и предоставляет регистры для TCP, а там хоть пять подключений, это не мешает забирать данные, потому что сама железка читает slave со своим периодом, а ее опрашивают со своим и эти периоды никак не пересекаются.
Вы же сделали что-то уникальное и тестировали только на OPC, а с двух ПЛК тестировали?, а с двух ПЛК стороннего производителя тестировали ? Или подобные тесты отдали на откуп клиентам ?
Сколько угодно таких преобразователей на лету. Скажем так, их большинство. И это удобно.
Или устройство преобразователь (и тогда он НЕ ДОЛЖЕН трактовать/оптимизировать пакеты по модбас, это дело мастера), а тем более рассматривать 2 соединения с одного IP как одно!
Либо это коуплер, сам опрашивающий устройства и видимый во внешней сети как slave сразу по множеству адресов.
Во втором случаем можно играться с анализом и т.п. оптимизациями, т.к. уж в своём собственном ответе устройство уверено.
Тролль-наседка, добрый, нежный и ласковый
Только вот само RTU устройство не умеет работать с двумя мастерами, если нет разграничения во времени. А так то да, Ethernet-RS485 с TCP сервером так же на лету работают, если на ПК либо виртуальный COM порт, либо ПО может работать с портом сразу поверх TCP. Проблемы конечного устройства это не отменяет. Но тут то заявлено, что мы обращаемся именно по Modbus TCP, шлюз преобразует в RTU и отдает обратно в Modbus TCP...
У меня есть одна железка подобного рода, но руки не доходят потестить именно таким образом, чтобы ее двое опрашивали, посмотреть что из этого получится.
Последний раз редактировалось melky; 22.11.2020 в 10:29.
Простите, а кто в здравом уме будет настраивать опрос двумя мастерами с одного ПК ? этот режим как раз для разных мастеров с разными адресами.
И на прошлой странице вы кажется неправильно выразились, ранее писали, что у мастера таймаут должен быть заведомо больше двух опросов, так как МКОН ставит в очередь запрос, если в этот момент идет опрос другим мастером.
О, бывает и так. основной процесс управления и визуализация.
Таймаут должен быль более времени ожидания ответа шлюзом. Если же 2 мастера посылают пакеты так часто, что их переварить 485 не может - тут никакие таймауты не помогут...
Речь то идет не о обычном времени ответа модуля, а о максимальном.
Тролль-наседка, добрый, нежный и ласковый
Филоненко Владислав тут зависит как у вас работают timeout-ы. Если стоит 1000 мс, ответ пришел через 50 и 950 мс ваше ПО будет тупо ждать, то это простым словом "жопа" а не ПО.
Если ответ пришел раньше, то нафик остальное время ожидания.... пауза и новый запрос согласно периода опроса.
з.ы. вот не знаю, как у вас ОПС работают, стараюсь с ними не связываться вообще без крайней необходимости.
Скорости несоизмеримы.
К внешнему коммутатору.
Ваши права
Ответить с цитированием