Цитата:
Сообщение от Gel
Здесь имеется в виду совсем не то, что вы подумали.
В свитче может использоваться очередь отправки, когда количество входящих пакетов оказалось больше, чем физически можно отправить.
Понятно, что данные в очереди расходуются со скоростью отправки данных, т.е. для сети 100 мегабит это будет примерно от 8000 тыс. до 100 тысяч пакетов в секунду, в зависимости от их размера.
Это совсем не то, что "свитч держит пакет в памяти, пока не убедится, что его принял получатель". Ничего подобного в свитче нет.
|
Спасибо. Начинаю помаленьку разбираться
Разделил циклы записи запроса MODBUS TCP (такт 100 мс) и чтения ответа (такт 50 мс)
При отключении кабеля от модуля ввода вывода данные сразу перестают поступать. Запись продолжается еще примерно 20 с.
Далее запись в порт прекращается.
Если в течении 15 с подключить кабель, передача данных восстанавливается.
При отключении чтения ответов запись запросов идет еще некоторое время (минуты).
Примерно через 1,5 минуты происходит сбой обмена по 2 параллельному каналу. Чтение по этому каналу не отключалось.
Примерно через 3 минуты происходит сбой и по 1 каналу.
Если не доводить до сбоя, то при включении чтения данные приходят старые, пока не вычитать все данные из буфера. Фокус в том, что если данные читать симметрично с запросами они всегда будут старые.
Вывод все-равно остается тот-же. Сбои обмена возможны.
Свич так же может задержать данные по причине неуспешности доставки. Это точно либо потеря несущей либо ошибка в CRC пакета.
Плюс сетевая карта модуля (согласно описания) может запросить повтор пакета от свича при ошибке CRC это как раз функции 2 уровня.
Буфер свича в данном случае ни при чем. Задержку дает скорее всего буфер сетевой карты или драйвера.
Старые данные приходить могут. Данные перепутываться могут. Задержка накапливаться может.
Transaction ID запроса контролировать нужно.
Способ закрыть TCP соединение открыть снова при любом сбое, ошибке таймаута и несовпадении Transaction ID правильный.
Не смог повторить сбой повторного соединения.
Видимо в заводском OPC сервере при неустановлении TCP соединения не производится посылка закрытия TCP соединения (несмотря на неуспешность). В этом случае возможно (учитывая буфер) полностью заблокировать модуль ввода вывода.
Неправильно определен источник в виде свича. И неправильно думал, что на 2 уровне есть квитанции на подтверждение получения пакета.
В этом описании ошибки больше не вижу. Инструмент под рукой, можно еще потестировать.