caxapa.ru :: Кто в этих ваших Эзернетах понимает, объясните темному. Будет ли нормально работать такая система?

ИвaнII (Вчера, 12:31, просмотров: 1083)

Кто в этих ваших Эзернетах понимает, объясните темному. Будет ли нормально работать такая система?

Задача. Обеспечить одновременное включение нескольких исполнительных механизмов, с точностью до миллисекунды

Топология сети. Комп и устройства на МК - W5500 воткнуты в коммутатор.

На компе Модбас мастер шлет широковещательные UDP на порт Х. Слушает ответы на портах Y+N (где N номер МК)

На МК поднят UDP сокет на порту Х, порт слушает Модбас слейв.

Комп посылает широковещательный (192.168.0.255) пакет на порт Х. МК принимают команду и каждый МК отвечает по UDP на адреc компа. При этом порт ответа у каждого МК свой (Y+N).

Будет ли нормально работать такая система? Не потонет ли в коллизиях?

- Есть коммутаторы store and forward емть cut OlegPowerC(409 знак., Вчера, 20:22)
- Это один коммутатор? Т.е. расстояние от мастера до любого из слейвов не более 100м? Я бы сигналы типа "открытый коллектор" передавал. Все же 1мс это довольно жестко. - Cкpипaч(Вчера, 15:12)
  - По харду так и есть, ОК или сток, пулл апы на прием и на передачу 49.9 Ом к 3.3 В или 2.5 В. Потребление порядка 100 мА минимум. Канальное кодирование манчестер для восстановления синхронизации. В продвинутых чипах еще кабельный эквалайзер адаптивный есть, они до 150 м могут. - Visitor(Вчера, 16:06)
  - 1мс нормально на сотке, но потери пакетов будут неизбежно. - LightElf(Вчера, 15:50)
    - Запустил пинг на свой маршрутизатор (вааще не нагруженный): 5-10ms. Ок, допустим на UDP будет в десять раз лучше и чо? - Cкpипaч(Вчера, 15:56)
      - ping на маршрутизатор/коммутатор, это вобще ничего не говорит ни о чем. трафик на маршрутизатор / коммутатор бывает транзитный , и на саму железку, так вот сетевое оборудование строится так, чтоб переваривать много трафика от хоста к хосту (в одной сети или в разных), а трафик который идет на процессор самой железки может быть например: OlegPowerC(312 знак., Вчера, 22:55)
      - Вы экспериментально установили, что в вашем компьютере и маршрутизаторе не используется RTOS :-) - LightElf(Вчера, 16:00)
        
        А в условиях задачи об этом что-то было? - Cкpипaч(Вчера, 16:05)
        
        В условиях задачи стоят МК, которые вполне осилят и 0.1мс (но Ethernet не даст) - LightElf(Вчера, 16:12)
        
        Я не говорю что такой результат недостижим, я говорю что "сходу" результат может быть другой и еще придется глубоко нырнуть в настройки стека. Cкpипaч(408 знак., Вчера, 16:24)
        
        Маршрутизатор - это на 99% линукс, типичные настройки которого заточены на максимальную пропускную способность, а не на минимальную задержку. У вас же, скорее всего, какое-то энергосбережение гадило. Грета Тунберг дотянулась. - LightElf(Вчера, 19:27)
        
        Меня всё устраивает. Мне быстрее и не нужно. И Гретту, очень прошу, без нужды не упоминайте. А то мало ли :) Cкpипaч(176 знак., Вчера, 19:53)
        
        Упоминать не буду, но факт остаётся. Многие девайсы обрели Link Power Management без особых упоминаний. 100мс как раз похоже на время подъёма линка. - LightElf(Вчера, 19:57)
        
        Были еще рекомендации от производителя ПЛК, не дёргать чаще чем 100ms. Да и по задаче достаточно было одна-две секунды. Если не хотеть странного, то и результат будет без неожиданностей :) - Cкpипaч(Вчера, 20:04)
- IEEE 1588? Или - по ссылке? Toчкa oпopы(1 знак., Вчера, 15:11, ссылка)
- Зависит от уровня ответственности. Я использую похожую схему, но не механизмы включаю, а показания с датчиков собираю. Причём эпизодический сбой обмена для работы не критичен - мастер просто отбрасывает этот цикл измерений. LightElf(195 знак., Вчера, 15:00)
- я не особый знаток, но ответ - однозначно нет. LordN(282 знак., Вчера, 12:39)
  - Ethernet не гарантирует доставку. - LightElf(Вчера, 14:48)
    - Уже и не помню, есть разница в пакетах TCP/UDP. - Visitor(Вчера, 15:15)
      - TCP/UDP ходят поверх IP, который ходит поверх Ethernet, это разные уровни. - LightElf(Вчера, 15:53)
      - UDP не гарантирует доставку. Пакет уходит "в никуда" без обратной связи. - bodis(Вчера, 15:29)
        
        раз уж такой интересный разговор. Мне как раз предстоит общаться по TCP-соединению. Что получу в обратной связи, если не доставлено? Так-то вижу что просто прозрачный канал, как в диалап-модеме. - Лaгyнoв(Вчера, 15:53)
        
        TCP подтверждает прием определенного количества данных (окна) флагом ACK и в этом же сегменте будет acknowlegment number, он будет указывать на номер sequence который следующим ожидает приемник. OlegPowerC(206 знак., Вчера, 23:03)
        
        Мы сейчас Profinet RT/IRT изобретем. Если коротко, то протокол работает на 2-м уровне модели OSI, прям в "голом" фрейме Ethernet и на специальных ASIC чипах. bodis(2 знак., Вчера, 22:33, картинка, картинка)
        
        А ты различай TCP и UDP соединения, для начала :) На удалёнке получишь необъяснимые паузы до пары секунд. Иногда. В основном, норм. Cкpипaч(133 знак., Вчера, 15:59)
        
        К сожалению SCTP не взлетел, в отличие от UDP/TCP. - LightElf(Вчера, 19:22)
        
        ну пара секунд - ерунда. На модеме SIM800 я могу ждать ответа на команду HTTPACTION и 8, и 10, и 15 секунд. :-) - Лaгyнoв(Вчера, 16:17)
        
        Обрыв соединения по таймауту. - LightElf(Вчера, 15:56)
        
        это хорошо, модуль мне тогда покажет это. - Лaгyнoв(Вчера, 16:15)
        
        Да. TCP не гарантирует доставку, но гарантирует, что о недоставке вы узнаете. Сразу или чуть погодя :-) - LightElf(Вчера, 19:25)

Микроконтроллеры