Pull to refresh

Comments 32

Это комплекс управления обычно называютется ГЩУ — главный щит управления для контроля за производственным объектом.

В химической и нефтехимической отраслях это называется «Центральный пульт управления» или ЦПУ (прямо как Центр Управления Полетом или ЦУП). Или Объедененная операторная. Или Central control room / Central control facility / Integrated control room
Для заинтересовавшихся советую так же почитать про протоколы МЭК 60870-5, МЭК 61850
Они так же сильно распространены в современном мире
Спасибо за статью, но статья содержит некоторое на мой взгляд количество неточностей:
Общая схема автоматизации промышленного объекта  не имеет отображение исполнительных механизмов, странно так же изображать модуль cpu и писать что это микроконтроллер, в промышленной автоматики на структурных схемах и не только показывают, что модуль cpu, и чаще всего он в одной стойки и имеет общую шину туже что и модули AI/AO/DI/DO, если схема распределенная тогда возможно. Сам модуль cpu может быть как soc, как микроконтроллер, как микропроцессор так и fpga, так же я бы добавил специализированные модули, интерфейсные модули и т. п в общую схему автоматизации промышленного объекта. Странно что в статье нет упоминания scada систем, т. к. за hmi панель точно никто целый день не стоит, и это не предоставляет не удобств, конечно если у вас не ЧПУ тогда все возможно, но все сложные производства управляются через scada системы. «Качество и размер изображения на малоформатных панелях оставляет желать лучшего» достаточно высокого качества изображение возьмите например панели waintek или siemens hmi панели и других производителей. UART не использует такие как он есть, используют rs232 и rs485, внутри да конечно uart. Странно что в статье Modbus и HART старые протоколы а, вот ethernet то нет, хотя ethernet тоже достаточно старый протокол. «Второе поколение протоколов или не совсем промышленные шины ISA, PCI(e) и VME» не вписывается в вашу концепцию описания «Общая схема автоматизации промышленного объекта», либо я что-то не да понял.
Далее полевые устройства: датчик и исполнительные механизмы, в свою очередь так же имеют уже давно интеллектуальные интерфейсы для передачи данных пусть то (profinet, profibus или т. п.). Так же есть множество компаний который выпускают пром автоматику, где модули di/do/ai/ao и cpu соединены между собой не общей шинной, а посредством ethernet, modbus rtu или modbus tcp/ip. Да и де факто siemens, abb мировые лидеры пром автоматики, поэтому эти компании диктуют условия развития пром сетей и промышленного оборудования. EtherCAT разработан компанией Beckhoff. Beckhoff в первую очередь делали данный протокол под свои ПЛК, и почему в статье нет термина ПЛК(PLC), pac и т. п.?
Причём довольно популярен ещё ModbusTCP. Также есть Modbus over TCP/UDP.
В ModbusTCP немного другой заголовок, в остальной похоже на обычный Modbus.
А в Modbus over TCP/UDP по сути просто стандартный пакет Modbus передаётся.
Таким образом легко интегрируется старое оборудование в новую сеть.
Да и вообще, мне кажется, классический Modbus тоже помирать не собирается :-)
Очень много и современных устройств с его поддержкой выпускается.
Бывает ещё модифицированный Modbus с двухбайтной адресацией, его любят производители электросчетчиков.
Кстати, да! Крайне интересная шина. У нас сейчас набирает большую популярность в различных приборах учёта (воды, тепла). К одной двухпроводной шине 250 устройств можно подключить, так по ней же ещё и питание идёт.
Я как-то преобразователь Ethernet\COM <=> M-BUS делал. Схемотехника там довольно интересная.
Я как-то преобразователь Ethernet\COM <=> M-BUS делал. Схемотехника там довольно интересная.

Что-то типа этого?
https://github.com/rscada/libmbus/blob/master/hardware/MBus_USB.pdf
Или совсем оригинальное? Ваши наработки не open source?
Смотрел на готовые решения, но ценник!
Мне для хобби, но я, увы, совсем не электронщик :(

Нет, я схему посложнее делал. На 250 устройств. Проект, правда, коммерческий был, поэтому итоговой схемой поделиться не могу. Но тема интересная, может быть по аналоговой части статью напишу как-нибудь.
Там именно вся сложность как раз в ней. «Цифру» прикрутить дальше элементарно.
Причём готовая схема есть в ГОСТ Р ЕН 1434-3-2006 (стр. 33):
www.decast.com/upload/iblock/112/gost_r_en_1434_3_2006_teploschetchiki._chast_3._obmen_dannymi_i_interfeysy.pdf
Но там имеется ряд неточностей, плюс отсутствует защита ОТ КЗ на выходе.
Собственно именно от этой схемы я и отталкивался.

Ясно. У меня есть дома 1 счетчик на M-Bus, который стоит в очень неудобном месте.
И есть идея-фикс:) Хочу с него данные передавать по воздуху. И если с последним проблем нет, то вот физически считать с M-Bus — временный затык.
Из готового "дешевого" нашел только https://ru.aliexpress.com/item/USB-MBUS-M-BUS-10/32854222405.html
Но мне USB на выходе избыточен, а вот обычный UART на 3-5V для микроконтроллера — нет таких готовых конвертеров :(

Мы как то, пока ждали заказанного конвертера, спаяли из горсти транзисторов конвертер M-bus to RS232. Еще бы схему найти, 11 лет назад было.
Дурацкая схемотехника, ИМХО. Если слейв еще более-менее адекватен, то мастер стоит безумных денег или реализуется кучей рассыпухи и компактно не получается в принципе. Медленный. В общем никаких преимуществ перед любыми другими, если нужно по двум проводам — есть 1-wire. Больше похоже что изначально был как проприетарное решение для попила бабла (не только у нас пилят), потом попытались протащить в массы.
ЗЫ: статья тоже ниачем. Смешались в кучу кони, люди. Если пром шины, то причем тут ISA и иже с ней. Если говорим про шины, причем здесь вообще модбас — это протокол, а не шина.
Схемотехника тут да, тяжёлая. Особенно для мастера. Интегральных решений мне не попадалось. Но в своё время я уместил мастера в корпусе D4MG на DIN-рейку шириной в 4 автомата.
Учтите, что в M-BUS напряжение на линии доходит до 42 В, а 1-Wire всего 5 В.
Кроме того, M-BUS поддерживает 250 устройств на линии. У него высокая помехозащищённость и низкие требования к качеству кабеля. Поэтому он и прижился для подключения приборов учёта. Получается простая и надёжная система. Скорость передачи данных тут низкая, но она и не нужна.Показания требуются довольно редко.
Честно говоря, для собственных нужд мастера можно собрать и на двух транзисторах.
А вот профессиональные решения для полной шины стоят довольно дорого. Но это не особо популярные вещи, поэтому и цена наверное такая.
D4MG конечно неплохо, мне в свое время нужно было в 5см2 нужно было уложиться, в итоге отказались от поддержки M-BUS.
Скорее высокая цена и сложность определяет низкую популярность. И еще момент, питание по шине данных при таких напряжениях сильно удорожает питание слэйва. Если слэйв имеет свое питание или питать по отдельной линии с низким напряжением, то никаких преимуществ перед 485 нет. Останусь при своем мнении, M-bus — мертворожденный интерфейс. Впрочем, думаю как и Лора в стратегической перспективе.
Питание, откровенно говоря, организуется очень просто. Я использовать повышающий преобразователь. Из напряжения 15-30В делал 42В. Максимальный ток потребления одного слэйва составляет 1,5 мА (по стандарту). Для 250 устройств получается всего 375 мА.
Зато вся линия — обычная «лапша» (2 провода). Очень удобно прокладывать. Полярность подключения к шине неважна! Для монтажников эта шина идеальна! :-)
Для 485 интерфейса потребуется 4 провода (A, B и два провода питания), плюс правильная распиновка.
я имел в виду питание на стороне слэйва. И что бы он потреблял <1.5мА, или это нужен импульсник с диапазоном 60В. Впрочем все решаемо, дело в цене вопроса, где будет дешевле бросить двухпарную витую пару, а где сэкономить на проводе и поставить дорогую базу.
M-bus — мертворожденный интерфейс

Только большинство мало-мальски хороших счетчиков тепла, как назло, используют именно его.

Вот у меня как раз обратная ситуация, за все время только два счетчика видел с M-bus. Да и как правило интерфейс — это опция, какой заказали (завезли на склад), тот и будет.
На смену протоколам Modbus и HART пришли не совсем промышленные шины, такие как ISA (MicroPC, PC/104) или PCI/PCIe (CompactPCI, CompactPCI Serial, StacPC), а также VME.

Бред какой-то. Впрочем как и вся статья.
старые, но не устаревшие :)
самые популярные на объектах добычи газа для полевого оборудования в том числе и на тех, что еще только будут вводиться.
Статья тянет на реферат для первых курсов, но не больше, чем на 4.
Но радует факт наличия на Хабре коллег — асушников)))
Автор, пиши ещё!
Протокол довольно тяжеловесный и медленный, скорость обмена зависит от характеристик приемника и передатчика, но обычно счет идет чуть ли не на сотни миллисекунд

А почему, собственно, тяжеловесный? Помимо переданных 16-и битных регистров, передается header который всегда 7 байт:
— Transaction ID (2 байта)
— Идентификатор протокола (2 байта)
— Длинна пакета (2 байта)
— Адрес slave устройства (1 байт).
При этом можно 1 запросом получить (если я не ошибаюсь) 125 регистров.
Тяжеловесный — скорее всего по архитектуре, т.к. имеет место циклический опрос, на который тратятся ресурсы.
Более того, регистр передачи данных Modbus является 16-битным, что сразу же накладывает ограничения на передачу типов real и double. Они передаются либо по частям, либо с потерей точности

Писать надо: real и lreal (в языках МЭК), либо float и double (C/C++). Сам modbus не ограничивает точность передаваемых данных. Что передаёте — то и получаете.
Именно! Никто не мешает и строки передавать по Modbus'у. Протокол довольно гибкий и легко реализуется даже на слабом «железе». Его спокойно на 8-битном контроллер запрограммировать можно.
Более того, регистр передачи данных Modbus является 16-битным, что сразу же накладывает ограничения на передачу типов real и double. Они передаются либо по частям, либо с потерей точности.
Никто не мешает опрашивать блоками по 2 регистра и получить 4 байта, интерпретируемые потом в тот же REAL. Так же, кстати, и со всякими DINT, DWORD и т.д. Более того, часто в средах разработки есть ФБ для работы с модбасом не на уровне протоколов, а на уровне данных, которые позволяют не задумываться, что и как там передается.
Большим плюсом модбаса является его простота. Когда, например, заказчик вместо какого-нибудь MGate ставит NPort, и приходится самому реализовывать Modbus over TCP. Поэтому, чую, долго он еще проживет!
Если уж EtherCAT «не привязан конкретному производителю», то POWERLINK тем более.
А так да его разработала изначально B&R, как Beckhoff изначально разрабатывала EtherCAT.
Спасибо! Подобных материалов не хватает.
Кстати о Modubs-e

Строго говоря, редко встретишь Хорошую реализацию протокола Modbus в устройстве, как и Всеобъемлющее понимание оного у разработчиков.
Даже у таких вполне уважаемых компаний, с Большим количеством Хорошо реализованных устройств.

Вот к примеру утверждение, которого в этой статье не было — о том, что передаются в этом протоколе только регистры и только 16 бит или биты состояний.

К примеру 43-я функция с подтипом 14-м вполне себе позволяет получать ASCII строки
с параметрами, до 256 штук из которых только 3 обязательные.
И эти строки вполне себе могут изменяться в процессе работы slave устройств.

Или к примеру 7-я функция диагностики устройства.
Или к примеру такая функции анализа количества ошибок ( отсутствует в реализации tcp ввиду отсутствия необходимости)

А уж если проанализировать сколько производителей плохо перевели с английского языка стандарт 1996 года, который уже в самом документе указан как устаревший и не рекомендуемый к реализации, то становиться весьма грустно.

С нетерпением ждём продолжения, обещанного в конце статьи!

Sign up to leave a comment.

Articles