Ага, как они с бесплатным членством-то будут четко следить?
Позасовывают все кому не лень свою проприетарщину.
Не вижу никаких мотивов тому же Сименсу давать своим контроллерами полнофункционально работать в среде Beckhoff.

Причем здесь среда Beckhoff к Ethercat и Сименсу?

Потому что без среды программирования нам от этого EtherCAT никакой пользы.
Вы например его использует только потому что имеете CodeSys
А не имей вы его, то отказались бы от EtherCAT еще на этапе знакомства с конфигурационными XML файлами.
Поскольку там черт ногу сломит, один парсинг займет неадекватные ресурсы. После чего еще остается риск нарваться на проприетарные данные.

Я использую EtherCAT только потому что заказчик потребовал цепь безопасности по SIL3, а объект в длину несколько сот метров.
Кстати посмотрим как EtherCAT потянет.

А так ассортимент модулей EtherCAT IO у производителей очень беден, цены на них вздуты, да еще и купить их так просто нельзя, месяц доставка.

Ну так у Сименса должна быть своя среда, которая должна поддерживать EtherCAT. Вполне допускаю, что Сименс специально не будет делать драйвер EtherCAT, чтобы проталкивать свой Profibus.

Как я уже писал в одном из контроллеров нами за основу был взят демо код от ETG и был сделан мастер, которому ни среда программирования, ни XML файлы не нужны.

Смотря где. У нас тут они даже на ebay продаются. Есть Beckhof, есть Phoenix, есть Weidmuller, есть Wago. По ценам я уже писал - прежде чем писать про вздутие, посмотрите на цены аналогичных модулей для Profinet или Canopen.

Я бы сравнивал с ардуино, а не с Profinet или Canopen.

Ну покажите мне индустриальный IO модуль Ардуино. Посмеемся вместе.

Наткнулся на неплохую презентацию по EtherCAT, правда от 2012 года.
https://indico.cern.ch/event/201794/attachm...CERN_120920.pdf

Возникли следующие вопросы.
1) Так он реально открытый и бесплатный? Или тебе только айсики могут продать в которых УЖЕ ВСТРОЕН код слейва, а сам код для плисины тебе не дадут бесплатно?
2) если каждый слейв вставляет свои данные в пакет "на лету", то получается, что CRC пакета, который получит мастер (после прохождения пакета через все слейвы) будет не верным? Но тогда такой пакет стандартный TCP|IP должен же отклонить? Тогда зачем мастеру в исходном пакете считать CRC зря теряя на это драгоценные такты?

3) А есть у нас в России люди, которые написали "с нуля" код етеркат слейфа для ПЛИСине?
4) Как слейф определяет в какое место "телеграммы" ему вставлять (доставать) данные? Тупо подсчетом числа тактов? А если у меня данные 1500 байт - это же гигантское число тактов будет?
5) Исходя из 4) полчучается, что достаточно испортить 1 бит (в цеху помехи дай божЕ)и вся телеграмма "псам под хвост" и 10000 тысяч устройств не получат команды в данном цикле? Или (что хуже) получат неверные команды? к примеру, вместо "включить клапан" слейв получит команду "выключить клапан" и произойдет катастрофа

Сообщение отредактировал Студент заборстроительного - Dec 30 2017, 09:59

Никто не в теме что ли?

Доступность спецификации не означает бесплатность реализации.

А причем тут tcp/ip? Правильно написанный tcp/ip stack этих фреймов не увидит вообще.

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

Т.е. полностью открытых прошивок для ПЛИС в общем доступе нету?


Т.е. то что мастер примет пакет с покоцанной CRC16 - это ничего?

А это возможно?
А то в инете разная инфа бродит.
Что якобы все равно пока фирме Bechhoff не отстегнёшь "мопед не поедет", так как есть некторые нюансы, которые не изложены в открытой спецификации.

Почему я и вопрос задал: есть ли тут те, кто сам, "с нуля" написал прошивку для ПЛИС на языке VHDL (или Verilog), реализующую EtherCAT-слейв, который успешно "внедрился как родной" в сеть из покупных EtherCAT устройств, изготовленных фирмой Bechhoff?

Сообщение отредактировал Студент заборстроительного - Jan 2 2018, 11:11

4) Как слейф определяет в какое место "телеграммы" ему вставлять (доставать) данные? Тупо подсчетом числа тактов? А если у меня данные 1500 байт - это же гигантское число тактов будет?

ЕtherСАТ применяется в промышленных системах управления. Там максимальная длина пакета около 100 байт. И счет идет, действительно, побитно вернее по два, четыре или восемь бит в зависимости от протокола чипа физического уровня. Реализовать слейв можно только аппаратно. А вот мастером может быть любой компьютер. Мастер выбрасывает пакет и задержка его прихода в приемник составляет длину в битах интерфейса чипа физического уровня.

Impartial
Скажите, а реализовать слейв с нуля самому реально? Ну, в смысле, имеющейся в открытом доступе инфы достаточно для этого?


Не факт.
Сам же Bechkoff пишет об охвате 10000 устройств одной телеграммой. Т.е. пакеты там явно длинней 1000 байт.


А если в цепочке 4 слейва и более?
А телеграмма должна пройти СКВОЗЬ них, то в принципе любой из них может "ЗАПОРОТЬ"телеграмму, "сбившись со счета" из-за помех и сбоев тактового генератора.
А если их 4 и более в цепочке, то вероятность этого вырастает многократно.

В связи с этим вопрос: какая практическая надежность EtherCAT в случае 4-х слейвов в цепочке и длине пакета 1500 байт?

Кто-нибудь проводил такие исследования?
Есть инфа по этому вопросу?

Т.е. какой процент битовых ошибок?

И по CRC16 не ясно.
Ведь когда слейвы вставляют свои данные в телеграмму они же CRC пакета не меняют.
Получается, что мастер получает пакет с испорченной CRC?