Комментарии 21
По-уму, туда давно уже пора прикрутить CAN. Отпадет очень много вопросов по организации протокола обмена.
CAN вполне себе используется давно, в частности CANOpen если об автоматизации говлрить. Но профибас гораздо шире распространен, так уж сложилось. И если подстраиваться под готовые системы - с этим придется считаться...
У автора в статье применялся Lenze i550. А мы с ним работали через MODBUS например.
Они и с CAN также продаются. Там интерфейс отдельным накладным модулем определяется.
Но потом отказались от Lenze. Они у нас постоянно зависали и их программирование особенно замороченное на фоне других производителей.
Поэтому говорить о некоей распространённости PROFIBUS я бы не стал. Тем более что это морально устаревший протокол. На сегодня требуются более быстрые и риалтаймовые протоколы типа EtherCAT.
Ну как бы Lenze != Profibus я полагаю И Если он зависал под modbus то это даже не означает что он обязательно будет виснуть под profibus, равно как и любой другой девайс. Если очень грубо то Profibus это навороченный Modbus и все эти усложнения надо хорошо отлаживать и тестировать А если требуется что то более быстрое то это повод задуматься не разместить ли управляющую программу более локально
Мы с проблемой долго боролись. Lenze свою вину не признал. Но небольшой реверс показал, что гальвано-изолированный их интерфейс на полевую шину сделан непрофессионально. Центральный микроконтроллер на интерфейсе у них XMC4400, он имеет и CAN и SCI/UART. Поэтому не думаю что схемотехника у них сильно отличается между CAN и RS485 (об этом говорят и лишние посадочные места на плате). Виснет и причём железно их интерфейсный микроконтроллер. Оживает только после полного выключения питания. Типичный Latch-up.
Проблемы с полевой шиной, по-моему опыту, в основном связаны с именно с полевой шиной) За 2 года я заменил около 3х десятков приемопередатчиков RS485 в различных девайсах. И понял, что к выбору микросхемы тоже нужно подойти с "подветренной". Могу посоветовать ADM485 исключительно от Analog Devices (частенько встречаю их в девайсах B&R), а также SN75ALS176x. Я бы не грешил на какие-то недочеты парней из Lenze, по крайней о софтверной стороне...
Два года в индустрии довольно мало. Мы в индустрии около 20 лет.
У нас лежат горы просто сгоревших инвертеров от разных известных производителей.
Про софт я бы даже не начинал.
Поскольку в ЧП вся ответственность за безопасную настройку лежит на пользователе. Если сгорает инвертер из-за неудачно выбранной дюжины настроечных коэффициентов, то виноват всегда пользователь. Никто и не заметит багов софта на фоне таких неоднозначностей. Кто виноват - сбой фирмваре в обсервере в FOC или неправильно выбранные пользователем индуктивность статора и сопротивление ротора мотора, никто не ответит. Но любой ЧП можно вывести на режим, где он убьёт либо себя, либо управляемую систему.
Зависания тоже никто не заметит, если мотор кратковременного действия и каждый раз после использования выключают питание.
Поэтому у нас императивная установка такая - сбивается всё. А если не сбивается значит недостаточно наблюдали.
Помехи в полевых шинах тема отдельная, и тот же Lenze даже имеет счетчики битых пакетов. И все же спорадически Lenze висли даже когда на пути было две! гальванические развязки. Даже на стенде.
Драйверы шин и мы меняли. Это приходилось делать из-за длинных полевых шин, где разность потенциалов земель между дивайсами превышала допустимый уровень смещения для драйвера. Беда в том, что выбросы на переходных процессах, индуктивность заземления и просачивание в землю от ЧП рассчитать невозможно, можно только эмпирически прийти к необходимости усиливать драйвер.
Соглашусь с сегодняшней нуждой в рилтайме и смертью профибаса, а особенно с замороченным программированием драйверов от Lenze) Но сегодня еще остается туча технологических линий, особенно в СНГ, которые собирали на трехсотке... А про зависание вообще впервые слышу. На производстве около сотни приводов, проблем таких ни разу не было...
Во-первых, по оценкам того же ARC Advisory - PROFIBUS существенно более распространен.
Во-вторых, есть миллионы устройств, которым этот ваш реалтайм более чем не нужен.
Довольно печально звучит когда мощного STMа хватает по сути только на сам обмен
Есть такое. Но, такие проблемы сегодня неизбежны. Поэтому в обиходе и появилось такое понятие как контроллер интерфейса. Даже специфичные архитектуры разрабатывают для этих целей, либо реализовывают на FPGA. А по поводу стмки, по сути, любой контроллер возьми - такие же проблемы будут. Очень быстрый период запроса посылки, процессору просто некогда делать что-то другое. Либо делать это по частям/аппаратно/дополнительное ядро для программного когда, а аппаратные возможности у конкретного контроллера неплохие. Конечно, я бы добавил всяких интересных фич, но для этого лучше взять FPGA... Как и говорилось, для реализации входа/выхода этого достаточно. Вообще, в планах портануть на f103c8, но это когда будет скучно)
Материал для тех кто не просто очень очень в теме не промэлектроники, а конкретно в профибасах-сименсах, более того - уже знает как работает этот протокол и как пользователь (это еще ладно) но и изнутри. Начало вроде расжеванное, а потом бац - SAP, PDU. Расшифровки понятия PDU не приведено нигде. Некая табличка и это это сразу надо уяснить. С постоянной отсылкой на другой сайт, даже без указания пунктов... понятия о работе протокола это не дает, а для описания работы конкретной реализации многовато всего "азбучного" - зачем это все?
Можно согласиться с тем, что статья была написана не совсем корректно - мой первый опыт. Но тема здесь специфичная, ищущая человека, который достаточно скиловый в теме микроэлектроники. Это не для "подпивасного" скрола... Зачем? Когда мне поставили этот вопрос, я был бы рад найти какую-то интересную информацию, тем более пример кода. Может кому-то это поможет...
Те кто в теме- вот на этом:
PROFIBUS, она же Process Field Bus, она же полевая шина, она же так называемый RS485
в удивлении поднимут бровь и спросят, а знаком ли автор с моделью OSI? Потому что совершенно не всякий PROFIBUS - это RS-485 и уж тем более наоборот.
А как выбирается первоначальная скорость обмена? Как настраивается и согласовывается? Что если на шине несколько устройств с разной скоростью?
PS: спасибо за статью, очень интересно!
Для шины UART скорость должна быть известна и для слейва и мастера, т.к. нету сигнала тактирования. Однако, есть аппаратно-софтверные решения определения скорости тактирования. Смысл в том, чтобы за несколько фреймов определить период 1 бита. Есть и метод по проще - перебор настроек приемопередатчика. Каждый фрейм принимается с определенной скоростью тактирования UART слейва и проверяется кол-во принятых бит, ошибки, старт и стоп биты. Если на текущих настройках байт принят без ошибки, то эту скорость и устанавливает слейв. Siemens в своих решениях использует метод посложнее, реализованный аппаратно. И на шине не могут быть устройства с разной скоростью...
Публикации
PROFIBUS DP-V0 & STM32