Comments 32
Это комплекс управления обычно называютется ГЩУ — главный щит управления для контроля за производственным объектом.
В химической и нефтехимической отраслях это называется «Центральный пульт управления» или ЦПУ (прямо как Центр Управления Полетом или ЦУП). Или Объедененная операторная. Или Central control room / Central control facility / Integrated control room
Они так же сильно распространены в современном мире
Общая схема автоматизации промышленного объекта не имеет отображение исполнительных механизмов, странно так же изображать модуль 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.
А в Modbus over TCP/UDP по сути просто стандартный пакет Modbus передаётся.
Таким образом легко интегрируется старое оборудование в новую сеть.
Да и вообще, мне кажется, классический Modbus тоже помирать не собирается :-)
Очень много и современных устройств с его поддержкой выпускается.
А почему про M-Bus ни слова?
Я как-то преобразователь Ethernet\COM <=> M-BUS делал. Схемотехника там довольно интересная.
Я как-то преобразователь Ethernet\COM <=> M-BUS делал. Схемотехника там довольно интересная.
Что-то типа этого?
https://github.com/rscada/libmbus/blob/master/hardware/MBus_USB.pdf
Или совсем оригинальное? Ваши наработки не open source?
Смотрел на готовые решения, но ценник!
Мне для хобби, но я, увы, совсем не электронщик :(
Там именно вся сложность как раз в ней. «Цифру» прикрутить дальше элементарно.
Причём готовая схема есть в ГОСТ Р ЕН 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 для микроконтроллера — нет таких готовых конвертеров :(
Хм, еще недавно ничего не находил, а вот только что глянул, что-то похожее на то, что мне надо нарисовалось: https://ru.aliexpress.com/item/100pcs-lot-Free-shipping-SMD-resettable-fuse-SMD1210P100TF-30-1210-1A-1000MA-30V/32806628015.html
ЗЫ: статья тоже ниачем. Смешались в кучу кони, люди. Если пром шины, то причем тут ISA и иже с ней. Если говорим про шины, причем здесь вообще модбас — это протокол, а не шина.
Учтите, что в M-BUS напряжение на линии доходит до 42 В, а 1-Wire всего 5 В.
Кроме того, M-BUS поддерживает 250 устройств на линии. У него высокая помехозащищённость и низкие требования к качеству кабеля. Поэтому он и прижился для подключения приборов учёта. Получается простая и надёжная система. Скорость передачи данных тут низкая, но она и не нужна.Показания требуются довольно редко.
Честно говоря, для собственных нужд мастера можно собрать и на двух транзисторах.
А вот профессиональные решения для полной шины стоят довольно дорого. Но это не особо популярные вещи, поэтому и цена наверное такая.
Скорее высокая цена и сложность определяет низкую популярность. И еще момент, питание по шине данных при таких напряжениях сильно удорожает питание слэйва. Если слэйв имеет свое питание или питать по отдельной линии с низким напряжением, то никаких преимуществ перед 485 нет. Останусь при своем мнении, M-bus — мертворожденный интерфейс. Впрочем, думаю как и Лора в стратегической перспективе.
Зато вся линия — обычная «лапша» (2 провода). Очень удобно прокладывать. Полярность подключения к шине неважна! Для монтажников эта шина идеальна! :-)
Для 485 интерфейса потребуется 4 провода (A, B и два провода питания), плюс правильная распиновка.
M-bus — мертворожденный интерфейс
Только большинство мало-мальски хороших счетчиков тепла, как назло, используют именно его.
На смену протоколам Modbus и HART пришли не совсем промышленные шины, такие как ISA (MicroPC, PC/104) или PCI/PCIe (CompactPCI, CompactPCI Serial, StacPC), а также VME.
Бред какой-то. Впрочем как и вся статья.
самые популярные на объектах добычи газа для полевого оборудования в том числе и на тех, что еще только будут вводиться.
Но радует факт наличия на Хабре коллег — асушников)))
Автор, пиши ещё!
Протокол довольно тяжеловесный и медленный, скорость обмена зависит от характеристик приемника и передатчика, но обычно счет идет чуть ли не на сотни миллисекунд
А почему, собственно, тяжеловесный? Помимо переданных 16-и битных регистров, передается header который всегда 7 байт:
— Transaction ID (2 байта)
— Идентификатор протокола (2 байта)
— Длинна пакета (2 байта)
— Адрес slave устройства (1 байт).
При этом можно 1 запросом получить (если я не ошибаюсь) 125 регистров.
Более того, регистр передачи данных Modbus является 16-битным, что сразу же накладывает ограничения на передачу типов real и double. Они передаются либо по частям, либо с потерей точности
Писать надо: real и lreal (в языках МЭК), либо float и double (C/C++). Сам modbus не ограничивает точность передаваемых данных. Что передаёте — то и получаете.
Более того, регистр передачи данных Modbus является 16-битным, что сразу же накладывает ограничения на передачу типов real и double. Они передаются либо по частям, либо с потерей точности.Никто не мешает опрашивать блоками по 2 регистра и получить 4 байта, интерпретируемые потом в тот же REAL. Так же, кстати, и со всякими DINT, DWORD и т.д. Более того, часто в средах разработки есть ФБ для работы с модбасом не на уровне протоколов, а на уровне данных, которые позволяют не задумываться, что и как там передается.
Большим плюсом модбаса является его простота. Когда, например, заказчик вместо какого-нибудь MGate ставит NPort, и приходится самому реализовывать Modbus over TCP. Поэтому, чую, долго он еще проживет!
Строго говоря, редко встретишь Хорошую реализацию протокола Modbus в устройстве, как и Всеобъемлющее понимание оного у разработчиков.
Даже у таких вполне уважаемых компаний, с Большим количеством Хорошо реализованных устройств.
Вот к примеру утверждение, которого в этой статье не было — о том, что передаются в этом протоколе только регистры и только 16 бит или биты состояний.
К примеру 43-я функция с подтипом 14-м вполне себе позволяет получать ASCII строки
с параметрами, до 256 штук из которых только 3 обязательные.
И эти строки вполне себе могут изменяться в процессе работы slave устройств.
Или к примеру 7-я функция диагностики устройства.
Или к примеру такая функции анализа количества ошибок ( отсутствует в реализации tcp ввиду отсутствия необходимости)
А уж если проанализировать сколько производителей плохо перевели с английского языка стандарт 1996 года, который уже в самом документе указан как устаревший и не рекомендуемый к реализации, то становиться весьма грустно.
С нетерпением ждём продолжения, обещанного в конце статьи!
Шины и протоколы в промышленной автоматике: как всё это работает