Вне зоны доступа, я вначале писал насчет проблем 6мкс только потому, что самый минимальный Ethernet фрейм имеет длину 70 байт и на 100мбит его длительность уже составляет 6мкс, точнее 6,42, как мне написал Twincat. Поэтому цикл опроса в 6мкс Вы по-любому не сделаете.
Для EtherCAT цикл опроса обычно 50мкс или медленней.

Сделать фрейм с двумя разными временами опроса - быстрым и медленным в EtherCAT можно без проблем. При этом трафик будет расходоваться эффективно, как вы хотите.

Это не так. Максимальный пакет 64 байта. Плюс 8 байт преамбулы. Получается 72 байта.
Или 576 бит. или 5,76 мкс.

Цикл 6 мкс вполне себе часто используется


Как?

Как split transaction в USB.

Еще вроде есть минимальный межкадровый интервал, который надо учитывать.


В EtherCAT?

Да.
5,76 мкс + 0,96мкс = 6,72 мкс

Т.е. с таким периодом вполне можно опрашивать 3 слейва в сети


Да. Именно в EtherCAT
В этом главная прелесть EtherCAT - сверхмалый цикл шины.


Всё гораздо проще.
ЭТУ картинку видели же?
Мастер устанавливая соответствующий [LOGICAL ADDRESS] логического пространства задачи может опрашивать слейвы с любым периодом независимо друг от друга.

Так?

За счет логической адресации. Допустим у вас имеется 2 EtherCAT устройства, одно из которых надо опрашивать каждые 6мкс, а другое - раз в 10мс. В EtherCAT слейвах есть такая штука, которая называется FMMU, которая позволяет отобразить физические сигналы слейва в общее логическое адресное пространство по определенным адресам. При чтении/записи мастером по этим адресам командами LRD/LWR слейв будет вставлять свои сигналы, если совпадут запрограммированные адреса. Допустим и тот и другой слейв - это 4 канала АЦП по 16 бит каждый. Т.е на каждый слейв нам надо 16*4=8 байт логического адресного пространства.
Отображаем слейв, который будем опрашивать каждые 6мкс по логическому адресу 0х1000, а второй слейв -по адресу 0х1008. Тогда команда LRD по адресу 0х1000 и длиной 8 байт с автоинкрементацией адреса прочитает первый слейв - ее будем слать в фрейме каждые 6мкс. А команда LRD по тому же адресу, но длиной 16 байт, прочитает оба слейва. Ее можно слать раз в 10мс. При этом у вас в этом фрейме нагрузка возрастет аж на 8 байт.

Теперь вопрос на засыпку. Что мешает слать второй фрейм каждые 6мкс, а не 10мс?

А кто нибудь в курсе?
Почему "отцы основатели" EtherCAT (фирма Beckhoff) не торопятся переходить на 1G и 10G EtherCAT?
Случайно наткнулся где-то в дебрях их сайта на инфу, что даже теоретические работы в этом направлении пока не ведутся.
Хотя их конкурент POWERLINK уже выкатил 1G и 10G решения.
Или там какие-то сложности принципиального характера?
--------------------

Я это уже сказал выше.
Но спасибо что "разжевали" более подробно

А не рассматривали такой вариант, что может это и не нужно? Сейчас, когда поголовно все лезут все быстрее и быстрее, то в основном это касается передачи интернета с его постоянно распухающими html, xml, json и прочей текстовой фигней, непонятно зачем передающей все в текстовом виде, тут же все довольно консервативно, скорости всегда хватало. Плюс если переходите на гигабит, уменьшается длина сегмента, увеличивается вероятность ошибок, а это явно не в пользу устройствам промавтоматики...

"Хватало" потому лишь, что не было относительно дешевых и технически относительно просто реализуемых решений увеличения скорости на порядки.

Знаете же поговорку "Аппетит приходит во время еды"©

А теперь, когда это всё есть - приходит и "аппетит".
Появляются такие возможности, о которых раньше мы (АСУТПшники) даже мечтать мы раньше не могли.

Например, если довести время цикла опроса до 1 микросекунды и засинхронизировать слейвы с точностью 1 наносекунда, то можно...
Впрочем, это уже не относится к теме.


Оптоволокно спасёт отца русской демократии
Там хоть 10 Терабит в секунду передавай. На 20 километров

Помоему, Вы далеко от АСУТПшников. Я вас спрашивал выше, откуда у вас 6мкс, и вы тут рассуждаете еще и о 1мкс времени опроса, когда в АСУТП время выполнения цикла самой быстрой программы - основного потребителя и производителя информации для EtherCAT >50мкс и ему еще долго уменьшаться... Поэтому всем в АСУТП и хватает 100Мбит.

А у вас что-то другое... признавайтесь :-)

С чего Вы взяли?
Когда в инете есть инфа, что есть системы на EtherCAT где сервопривода управляются с частотой от 30 кГц, а это уже никак не 50 мкс, а поменьше.

Существует АСУТП быстропротекающих процессов.
Там нужны короткие циклы.

И даже не так.
Важен не цикл как таковой, а обеспечение маленькой латентности реакции на события.
Т.е. чтобы реакция на некие события появлялась через единицы микросекунд.

А для этого нужные микросекундные циклы опроса

Ну 30кГц - все же это не 6мкс, а немного больше. :-)

Ну я бы сказал, что для этого, прежде всего, нужен процессинг, который способен в реальном времени обрабатывать события в течении нескольких микросекунд и выдавать управляющие сигналы. В моей отрасли так умеют ПЛИСы и некоторые DSP, но это дорогое удовольствие и их сложновато программировать АСУТПшникам. А что в мире АСУТП быстропротекающих процессов так умеет? Просветите плиз, мне действительно интересно.

А то что десятки устройств будут соединяться в цепочку не увеличивает ли вероятность обрыва кольца?