А что на форумах Симы говорят?Сообщение от Серджиус
А что на форумах Симы говорят?
Тролль-наседка, добрый, нежный и ласковый
По поводу чего? Как конфигурируется сеть в NetPro? Так это я и так знаю, как бы не впервойА что на форумах Симы говорят?, кроме того у меня есть пример проекта с обменом по МодбасТСР от сименса (в смысле пример от них). Я его запускал у себя (у меня контроллер тот же, что и в семена проекте) - результат, я думаю, понятен. Короче проект семена и мой работают с овеном одинаково.
По поводу ретрансмиссий. Явно это не нормально.По поводу чего? Как конфигурируется сеть в NetPro? Так это я и так знаю, как бы не впервой
Тролль-наседка, добрый, нежный и ласковый
Ну тут напрашивается вывод, что это генерирует сам Ethernet CP.По поводу ретрансмиссий. Явно это не нормально.
Тут дело такое: Если используется Ethernet CP, то связь конфигурируется через NetPro, и контроллер сам пытается ее установить вне зависимости от того, используются ли функции для работы с сетью (т.е. от меня это не зависит). А вот если используется Open TCP/IP Communication, тогда я в программе сам определяю когда мне надо законнектиться и когда отключиться. Вот например сейчас я немного изменил программу (функции связи не вызываются), гляжу NetPro онлайн - соединение установлено! Стало быть для Ethernet CP это нормально.
Я конечно напишу на форум про это дело, как ответят, отпишусь.
Владислав, а вы считаете, что у меня все коммуникационники нерабочие?По поводу ретрансмиссий. Явно это не нормально.
Я подозреваю, что попытки переподключится по 3 раза за мс - это ЖЖЖ неспроста. Обычное Ethernet устройство так себя не ведет, таймаут на ретрансмиссию от 200 до 30000 мс.
Значит CP работает в режиме RealtimeEthernet, когда весь канал отдан по сути под одно соединение и можно ожидать (при соотв. аппаратной поддержке) времени ответа на уровне десятков мкс.
The standard CP 343-1 is used to connect the SIMATIC S7-300 to Industrial Ethernet In addition to communication with other Ethernet stations (т.е. как slave?), the CP as PROFINET IO controller or as IO device connects distributed I/O modules.
Как мы видим, CP может работать и как средство доступа к IO, где важна скорость ответа и как устройство доступа к обычным TCP/IP устройствам.
Однако режимы работы явно различаются.
P.S. Почитал про CP модули - они же для IndustrialEthernet сделаны, про обычный Ethernet не нашёл. Там совсем другие тайминги.
P.P.S. Стек на старых ПЛК весьма ограниченный, возможно он эти ретрансмиссии вообще игнорирует, т.к. у него в принципе нет окна и не надо обрабатывать out-of-order пакеты.
Последний раз редактировалось Филоненко Владислав; 16.08.2018 в 09:27.
Тролль-наседка, добрый, нежный и ласковый
Посмотрел ещё раз логи.
Похоже дело в несоответствии CP стандарту TCP/IP соединения.
По стандарту, после посылки Syn клиент должен дождаться SYN,ASK, послать в ответ ASK и после этого начать обмен.
В реальности, после посылки SYN, CP, не дожидаясь ASK, начинает слать SYN снова и снова, уменьшая TTL при каждой посылке.
Стек старого ПЛК настолько тупой, что не реагирует на нарушение стандарта и всё же высылает SYN,ASK на каждый SYN, и обмен, со скрипом идёт.
Более продвинутый стек фиксирует нарушение и не выдаёт SYN,ASK 118 раз, а при достижении TTL=1 ретрансмиссии прекращаются (что логично, пакет на следующем гапе умер).
И спустя паузу, не видя ASK (а пакет потерялся) ПЛК резетит соединение.
Что ясно.
1. Где-то есть петля, из-за которой пакеты раз за разом возвращаются с уменьшающимся TTL.
2. Пока в сети идут ретрансмиссии, ответ с ПЛК в принципе не доходит (что в старом, что в новом), он "теряется" где-то по пути.
3. Т.о. ответ SYN,ASK от нового ПЛК теряется, SYN,ASK от старого ПЛК в силу простоты стека дублируется 118 раз и 118-й таки может достичь адресата, т.к. ретрансмисии заканчиваются "естественным" образом
4. Запросы от сименса доходят до ПЛК и он генерит ответ, но ответ "затирается" штормом ретрансмиссий
5. Ответ ПЛК в петлю не попадает (что позволяет предположить, что петля программная, в CP)
Что можно сделать?
1. Убрать петлю, если удастся понять где она.
2. Снизить TTL до 1 - тогда ретрансмиссий не будет, а пакеты вс1 еще смогут при локальном соединении достичь ПЛК и вернуться.
P.S. "оглупление стека делать не будем"
Последний раз редактировалось Филоненко Владислав; 16.08.2018 в 09:31.
Тролль-наседка, добрый, нежный и ласковый
Развернул на ноуте МодбасТСР клиента и подключил к нему S7-400. Записал лог. Ретрансмиссий нет.PLCS400_new.rarЧто можно сделать?
1. Убрать петлю, если удастся понять где она.
Думаю, что все дело в сетевке моего компа. А проблема подключения S7-400 к новому ПЛК, который я цеплял напрямую разными паткордами, существует. Как с этим быть?
Вопрос лога поднимается опять. Хочется увидеть что с обменом. Как-то надо снять лог.
Тролль-наседка, добрый, нежный и ласковый
Завтра попробую снять лог, но придется опять через шлюз. А то Wireshark ничего кроме арпа не фиксирует.
Ваши права
Ответить с цитированием