Комментарии 57
По EtherCAT у вас немного неточная информация:
Сеть EtherCAT успешно используется в распределенных системах автоматизации, где взаимодействующие узлы разнесены на большое расстояние.
Скажем так — EtherCAT — это как раз та самая полевая шина, предназначенная для связи центрального контроллера с множеством разнесенных I/O. Это не сеть для равнозначных узлов или распределенных вычислений.
Протокол EtherCAT использует стандартные Ethernet-фреймы для передачи своих телеграмм, поэтому сохраняется совместимость с любым стандартным Ethernet-оборудованием и, по сути, прием и передача данных могут быть организованы на любом Ethernet-контроллере, при наличии соответствующего программного обеспечения.
Это очень неоднозначное определение и может привести к непониманию. Во первых инкапсуляция информации в фреймы там да, сделана по стандарту Ethernet и физический уровень там 100Base-TX. Но на этом сходство с Ethernet заканчивается. Вы не можете использовать Ethernet свичи или топологии построения сетей, обычно используемые для Ethernet. Также вы не можете использовать стандартный Ethernet c EtherCAT в одной сети.
Использование стандарта и физического уровня Ethernet позволит вам использовать обычную PC-шную плату Ethernet контроллера в качестве мастера сети, но не в случае слейвов — там нужен специфичный контроллер с двумя EtherCAT портами.
А вообще если говорить о применимости этих протоколов в промавтоматике — то самое широкое их применение наблюдается в качестве расширения портов ввода-вывода для промышленного контроллера. Т.е. на шине сидит один контроллер, который выполняет всю программу и обменивается с сотней или даже тысячей дачтиков, кнопок, реле и прочими сигналами через полевую шину.
ПС мы применяем очень серьезно EtherCAT и CANopen. В подстанциях сейчас развивается IEC61850
Как практически решается задача контроля целостности кадра на лету? Насколько я понимаю, кадр ещё не успевает даже приняться, а его уже надо на лету передавать дальше?
Да. Но там все просто — каждый кадр сопровождается CRC. Если CRC принятого фрейма в порядке, то ничего не происходит. Если же принятый кадр поврежден, то передаваемый тоже искусственно повреждается путем искажения его CRC. Но искажение CRC делается таким образом, что следующий слейв может определить — именно этот фрейм испорчен, или этот фрейм нормальный, но предыдущий слейв специально испортил кадр. И дальше оно передается по кругу до самого мастера.
Использование стандарта и физического уровня Ethernet позволит вам использовать обычную PC-шную плату Ethernet контроллера в качестве мастера сети, но не в случае слейвов — там нужен специфичный контроллер с двумя EtherCAT портами.
Но по идее можно использовать две PC сетевые карты… и на них эмулировать EtherCAT.
Можно, но так мало кто делает.
Мало того — они не смогут сгенерировать этот пакет "налету" так как каждый слейв должен поменять как минимум один байт в отдаваемом пакете(т.н. Working Counter — по нему мастер определяет не изменилась ли топология сети) и соответственно пересчитать СRC. Поэтому слейв — это обычно ПЛИС или специализированный ASIC, который может быть отдельно, либо в составе микроконтроллера..
OPC UA сейчас мигрирует в сторону поддержки time-sensitive network и претендует постепенно вытеснить powerlink.
Поддержка кастомных (своих) устройств powerlink есть. Диссектор для wireshark также свободно доступен для скачивания.
Кстати в начале статьи обещали CAN — а ведь там много чего интересного есть: DeviceNet, CANopen, а в итоге остановились на Ethernet. Про Profibus вообще забыли.
И, внезапно, powerlink = canopen+ethernet
https://www.ethernet-powerlink.org/powerlink/technology/canopen-and-powerlink
Она популярнее, чем вы думаете, но не у интеграторов, а промышленность (пищевая, например, пластмассы) закупает готовые станки и понятия не имеет, как оно там всё устроено и работает. Ну и продвинутые системы управления движением изготавливают продукцию высоких переделов, коей в стране в принципе мало производится.
Ну вы ж хотели как дешевле? А дешевле оно только как сервис и только на проприетарщине. Я много таких распределенных систем видел для покупки. Спрашиваешь:
- Что у вас за протокол?
- CAN, все чики-пуки
- А над CAN что?
- Нуу… наш протокол.
- Спасибо, до свиданья.
А находишь аналогичное на CANopen — оно хоть и дороже, но хоть с этой штукой разобраться самостоятельно можно. И даже девайс от другого вендора в сеть подключить, если предыдущий исчез — многие, кстати, такой конкуренции как огня боятся.
Зашёл, чтобы увидеть этот комментарий. До сих пор волосы шевелятся от прочитанного… И вроде блог такой нормальный типа...
И огромный минус несогласованных линий — малая допустимая скорость, их стоит использовать только если совсем питание некоего датчика ограничено автономностью собственного источника питания.
Шаг 2. Из спецификации приемопередатчика RS-485 найдите его минимальное время нарастания (tr min). Например, для MAX3471 оно равно 750нс.
Шаг 3. Разделите это минимальное время нарастания на 4. Для MAX3471 получим tr min/4 = 750нс/4 = 187.5нс.
Шаг 4. Вычислите максимальную протяженность кабеля, для которой не требуется согласование: 187.5нс (230мм/нс) = 38м.
из моих заметок.
Чуть подробнее простым в принципе языком тема раскрывалась ранее на хабре:
habr.com/ru/post/183006
товарищем zirus
Понятно что все это более-менее грубо, тк расчет идет для прямого кабеля, в случае нестандартной прокладки и наличия других шумов придется бороться и с ними, но для первого приближения и прикидок по месту мне в принципе помогало=)
P.S.И даже при такой поверхностности, не коснулись даже всех протоколов из приведенных иллюстраций.
P.P.S А еще забыты целые разделы сетей «умного дома» типа BACnet, и новых разработок для IoT
Сам работаю Embedded разработчиком и программистом PLC. Думаю, что это хороший вариант для повышения квалификации, так как подобные курсы и сертификация от, например, Siemens стоят в разы дороже.
Материал, посвящённый протоколу FBUS от Fastwel, мягко говоря, не соответствует действительности
Представленная информация об FBUS вроде той, что "подчиненный узел FBUS может содержать только 64 модуля ввода-вывода" вводит в заблуждение непосвященных читателей
FBUS это не "отечественная реализация промышленного протокола FBUS", это собственный протокол межмодульной шины для ПЛК Fastwel I/O, который был разработан в 2002 г. задолго до начала импортозамещания и никогда не претендовал на статус "промышленного протокола"
Просьба к авторам, перед публикацией не полениться и ознакомиться с предметом публикования, благо в интернете есть практически полное описание того, что такое FBUS https://www.cta.ru/cms/f/352126.pdf
Вспомнился Schneider со своим ERIO — реально это CIP (хоть они и не афишируют). А протоколы и шины самих контроллерных корзин и корзин ввода-вывода — уже коммерческая тайна вендоров.
Почему это хорошо?
Можно долго спорить 80,90 или 95% автоматизации в России это Modbus, но достаточно открыть сайт хэдхантер чтобы понять, что если бы у нас был расклад как на прилагаемой картинке — то в автоматизации было бы от силы человек 300 на всю страну. А так, " автоматизация в каждый дом"
Модбас это конечно как английский язык — все его понимают, но он чаще вторичный протокол, чем основной.
Для Модбаса — реалтайм — нет, синхронизация времени — нет, уведомлений нет, обменной модели тоже нет — довольно таки устарел.
.
Достаточно странное заявление о знании разделение рынка по производителям.
Для начала надо бы огородить Какого рынка. Какой автоматизации. Потом пойти на сайт хэдхантера и попытаться опровергнуть простым набором букв в поиск. по очереди каждого из протоколов. Не сильно репрезентативная операция, но хотя бы Порядок специалистов с знаниями разных протоколов может дать. И этот порядок говорит о подавляющем доминировании модбаса на нашем рынке.
Интересно, а читать на английском языке крайние спецификации хотя бы 2015 года никто не пытался? Вера совсем не позволяет?
Или как некоторые производители — прочитали стандарт 1996 года. и «не делайте так больше, это устаревшая модель для легаси, дальше поддерживать не надо и даже не пытайтесь, это пришло со времён релейной логики» приняли за " ух ты, а модбас это только так и ни как иначе" (с)
Modbus RTU — вполне себе реалтаймовый протокол. Только медленный.
довольно таки устарел
Что предложите взамен на RS485?
Для шинных соединений я бы предложил рассматривать CAN bus и его производные — DeviceNet, для телемеханики IEC60870-5-101. Хотя сильно зависит от задачи.
(и видимо я один из первых сторонних попытался получить прошивку под модуль интеграции к оному).
А так то рано или поздно взамен физики rs485 придет что-то другое, это очевидно.
Гложат, конечно, сомнения что это что-то будет существенно более сложное чем текущие массовые реализации. Есть склонность считать что маятник прогресса пока движется в сторону упрощения.
взамен физики rs485 придет что-то другое, это очевидно
Тут надо решить — оставаться на шинной архитектуре (т.е. пассивная общая шина, доступная всем узлам в режиме TDM) или переходить на switch-технологии (т.е. посередине активный свитч, занимающийся пересылкой пакетов от узлов, имеющих индивидуальные соединения с ним)
CAN и RS485 относятся к первым. Ethernet — ко вторым. Понятно, что основной фактор — стоимость активных компонентов. В switch-технологии количество трансиверов как минимум в два раза больше. Т.е. она будет как минимум в два раза дороже. Но и скорости можно достичь гораздо более высокие. Но всем ли это нужно?
А физический уровень Ethernet прекрасно подходит для реалтайма, если его правильно использовать — тот же EtherCAT тому пример.
Жабка мешает. Железки-то бывают довольно примитивные — например 8 логических входов или выходов. А тут на тебе — свич на два порта с обвязкой.
Удивитесь но это для данного сегмента слишком дорого. Ну и убеждать приходилось чуть ли не полгода, и то не «пробил». В результате они имеют то что имеют и переключатели с хорошей схемой.
Я это к тому, что Массовое применение сети связи для диспетчеризации и автоматизации это для
меня скажем примерно в цифрах начинается от 200 000 устройств в месяц плюс-минус. Какого либо рода устройств диспетчеризации и автоматизации
Если про более менее открытые протоколы — то примерно в 200 интеграций в месяц с Большими системами посредством Modbus.
При этом читать что — то про EtherCAT Profibus и прочие протоколы мягко говоря немного странно.
Ничего не понял.
первая часть это собственно ответ про Овен, там надеюсь понятно.
вторая часть — про то, что протоколов и интерфейсов строго говоря Весьма много.
Если Более развернуто, то
И если писать про какую-либо часть рынка — надо обозначить какие-либо характеристики — количества устройств, цены устройств.Я примерно обозначил.
В этих цифрах Если сравнить протоколы по применяемости — то к примеру Два Больших применения KNX и Backnet в Башне Федерации ( крупнейшие в Европе) не дали по сути никакой доли применений в рынок. Потому как они сделаны раз в 10 лет когда рынок Автоматизации и Диспетчеризации ежедневно потребляет тысячи устройств.
Соответственно основная проблема любых интерфейсов и протоколов — это
1) цена
2) наличие компетенций у инсталяторов
И если с ценой всё ещё решаемо, то с уровнем знаний все не так однозначно. С моей точки зрения, к примеру — есть явная тенденция на упрощение. То-есть интерфейсы и протоколы должны быть проще в применении чем текущие масс-применения.
ethernet сложнее RS485.
объективно два провода сложнее 8-и со специальной обжимкой и наконечниками. Про оптику там вообще не массовый сегмент ещё (а жаль).
Если коротко и объективно — Ethernet лучше 485? да. сложнее? да.
как скоро Ethernet -а будут протягивать в сетях автоматизации хотя бы примерно столько же сколько «лапши» 485? вопрос интересный и достаточно спорный (ну а вдруг уже больше, кто знает...)
Я так понял, что вы из области домашней автоматизации. Здесь же больше обсуждается промавтоматизация. Есть некоторые нюансы.
Про Промышленную Автоматизацию и Диспетчеризацию. Я имел ввиду Охранно пожарную сигнализацию и автоматику пожаротушения. Странно звучит, но достаточно сложно сказать что пожарная сигнализация это не пром. Диспетчеризация. А противопожарная автоматика не автоматизация. Ну то есть кроме дров с дымоудалением она стоит на всех пром. Производствах и обеспечивает не менее важный для создания добавленной стоимости технологический процесс
)))
А этот рынок в моем видении не сопоставим по размерам со всеми вместе ПЛК в нашей стране. После Овена я могу примерно сравнивать.
И это Весьма Маленькая компания в ОПС, у них и меньше процента рынка. Не на один объект на который выйгран тендер раз в два года, а каждый месяц.
И эта часть рынка Автоматизации и Диспетчеризации Более упорядочена чем многие другие.
Центральные пульты и Шкафы автоматизации у них уже подчиняются законодательству, а не " кто как придумал так и сделал". И требования более жесткие и чёткие.
Ну и как результат — инженеров в этой части рынка Инсталляции систем Автоматизации и Диспетчеризации существенно больше.
ну как пример — я полагаю на вскидку по стране больше 35 000 инженеров инсталяторов только той компании где я сейчас работаю. это заниженная оценка.
Это инженеры. Контроллеры программируют каждый день,
под каждый объект уникальные настройки и программы, в соответствии с нормативами.
Я пытался донести мысль о том, что достаточно интересна идея удаленных модулей, питаемых от интерфейсной линии.
Это исключительно в плане Фантазии. Представьте, через 5 лет если был бы протокол, обеспечивающий большую скорость, реальное время и прочие прелести жизни, но работающий со модулями ввода-вывода по физике не требующей дополнительного питания — это было бы весьма интересно.
Бэкхов со сдвиговым регистром, конечно, востребован в быстрых применениях и к примеру в метро, но если бы были модули с другой архитектурой но сопоставимой скоростью — было бы как минимум интересно
Да, это скорее всего в текущем понимании это не достижимо. Как добиться таких скоростей и задержек непонятно.
Но, строго говоря — то чего мы не знаем не обязательно не будет существовать когда_либо. Ну или на крайний случай в другой вселенной))). С реальным 1-wire конечно хотелось бы чтобы не в нашей))
А так то PoE весьма интересен. В пром зону его врятли вставить прямо нормально — но… как описано выше… может быть, когда нибудь…
AS-Interface
modbus.org/docs/Modbus_Messaging_Implementation_Guide_V1_0b.pdf
там можно попытаться почерпнуть знание о разнице между «master- slave» и «Сlient- Server» в части ModbusTCP.
Зависит от того, на каком уровне вы хотите эти протоколы использовать — если на прикладном, то нет смысла углубляться в детали имплементации и можно по быстрому изучить несколько самых распространенных. Если же будете сами что-то мутить, то надо выбрать один и уже читать его документацию. Следует отметить, что не все протоколы одинаково открыты для изучения.
Обзор современных протоколов в системах промавтоматики