Дмитрий Бала @dbalabolin
Радиоинженер, изобретатель, программист
Information
- Rating
- Does not participate
- Location
- Москва, Москва и Московская обл., Россия
- Date of birth
- Registered
- Activity
Specialization
Embedded Software Engineer, Chief Technology Officer (CTO)
From 15,000 €
People management
Business development
Optimization of business processes
Startup management
Project management
Information Technology
Strategic management
Company management
Полезные данные о формате, но неизвестно насколько они точны. Официально этот формат не попадался опубликованным.
Это команды работы именно с Instruction set - то есть в режиме НЕ загрузки а когда работает сама прошивка.
Надеюсь, что материал исчерпывающий и комментариев не будет
Кстати говоря прекрасная характеристика для аудитории. Буду знать
Скажу я вам, что есть просто говнюки на которых мне глубоко плевать. А есть люди, которым очень даже полезно получить новые полезные навыки. На 500 просмотров я вижу 5 закладок. А те кто думает, что они и есть соль земли, то думаю что это серьезное заблуждение.
Средний уровень закладок менее 0,5 процента. Они и определяют полезность.
А мерять говнистость мне не интересно. Это обычная зависть.
"Низкий технический уровень материала 36.36%
Больше рекламы, чем пользы 9.09%
Не соответствует тематике Хабра 27.27%
Кликбейтный заголовок 27.27%"
Ну вот набор от бедолаг. Низкий технический уровень? Да вроде бы нет. Это кроме методики еще и хороший обзорный материал по теме. С полным охватом."
Тематике не соответствует? Ну давайте посмотрим что такое "тематика" и какие есть статьи в хабе "Управление проектами*
"Мечтают ли сотрудники о целях компании?"
Эффективное управление отношениями со стейкхолдерами
Как превратить сырую идею в реально успешный продукт: полезные советы, лайфхаки и немного личных историй
Трактор, смузи и одна старая логическая игра: как мы ездили на Joker и Heisenbug - как они дули смузи это тоже пропроеты?
Наш самый психоделичный бизнес-проект
Как презентовать дизайн-концепцию, чтобы не обосраться перед заказчиком. Готовый скрипт + чек-лист
Некоторые особенности голосового ввода на реальном производстве
Вобщем голосование свидетельствует больше о голосующих. А вовсе не о материале.
Есть множество людей, которые заказывали обучение этому простому способу.
Сложно меня заподозрить в стяжательстве. Я ничего никому не продаю тут.
На Хабре никаких моих покупателей нет. Они вообще все за границей находятся.
Ну дело житейское. Тут похоже все считают себя сильно умнее всех остальных
наверно в спаме было, уже все в спаме найдено и обслужено
Чисто для информации. Я - дипломированный магистр по климатической технике. Кроме того что радиоинженер.
я ответил на одно письмо уже с приложением спецификаций. с какого адреса было Ваше? не дошло пока.
Если Слейву надо обратиться к мастеру, то он в специальном окне выставляет запрос со своим адресом.
Мастер видит, что есть сообщение типа ALARM и знает от кого. И уже начинает со своей стороны выяснять что там произошло прямо следующим обращением к слейву. И слеву дает информацию, что его сообщение дошло.
Если слейвов несколько то сообщения они накладывают одно на другое Так как формат сообщения одинаковый но отличается адрес и CRC то мастер ничего им не отвечает и продолжает свой цикл опроса.
Все слейвы, которые не получили немедленного к себе запроса, но находящиеся в состоянии ALARM будут повторять свой выход на линию. Но каждый из них сделает случайную паузу от нуля до нескольких пакетов. То есть они разойдутся по времени. Такой же механизм и в других протоколах используется.
Как раз наоборот. Наши устройства с самыми дешевыми контроллерами 8 бит и этого достаточно и на преобразование форматов и на поддержку протокола. Это в заголовке статьи. Цена на цифру сегодня буквально ноль. В отличие от какого-нибудь встраиваемого датчика давления.
Огромная масса дачников выпускается сейчас с интерфейсами 0-10 или 4-20.
И коробочка с цифровизацией добавляет к цене 10 процентов. И пожалуйста уже можно пользовать. И в приборах внутри корпуса и удаленно.
Скажу даже, что излучался вопрос о том, что бы на этом всем управление судами сделать.
И никаких противопоказаний не обнаружилось.
Другой протокол по сумме затрат на все части процесса - от проектирования до обслуживания и от изготовления самих контроллеров до их корпусов дороже. Прибавим еще затраты на монтаж устройств в каждом из которых своя распиновка подключения вместо унифицированных разъемов. Зарплаты программистов отличаются на разных языках. Соберется общая цена.
Количество приборов я вполне могу представить. Мы раньше делали очень большие проекты по вентиляции и кондиционированию/очистке воздуха. Прямо на кварталы из зданий.
Вот там кстати надо температуру знать. И разницу давлений при открытии заслонок и влажность. Потому что это такой огромный PID регулятор по факту.
А изобретения вообще дело неблагодарное. У меня есть международный патент к примеру. Так и денег и сил это стоит неразумных.
Всегда что-то начинается и заканчивается. Пока мы видим путь внедрения в устройства, а не в большие системы. Станки и теплицы. Зарядные станции и вообще всякое оборудование.
За последние годы появился далеко не один протокол и строить прогнозы об успешности явно рано. Проблема российских протоколов и вообще всех разработок это русский язык. Потому что его никто не знает и весь мир пользуется английским.
Наши кое=как выучили английский, но заставить иностранцев учить русский невозможно. А для целого протокола одной России маловато. И это более важно чем новизна чего бы то ни было из РФ.
А со всеми спецификациями мы ознакомились по всем наиболее популярным протоколам. И CAN и HART и прочие FIELDBUS.
Взяли все лучшее постарались снизить влияние природных недостатков таких как Master-Slave например.
А "по необходимости" поверх любого протокола можно натянуть что угодно. Хоть шифрование хоть передача видео. Можно даже в протоколы туннели включать. В мастер-слейвы элементы peer-to-peer. Только управлять этой бедой крайне сложно.
На счет поддержки будет кстати такая вещь. В нескольких ВУЗах будет обучение автоматизации на примере idiBus. Лабораторные работы и практикумы.
"А как устройство понимает, что оно не одно передаёт? Слушать шину в RS-485 в момент передачи нельзя — вы услышите сами себя, а другие что-то случайное."
Оно не понимает что одно. Оно не получит подтверждение, что его сообщение дошло.
115200 на 1,2 км это реальная скорость при использовании экранированной витой пары Cat5e. Если прямо через ядерный реактор протянуть кабель, то наверно нужно будет снизить скорость.
"Сомнительные" лендинги? С чего вдруг сомнительные? Внутри этих устройств все и работает. Все управление как раз и сделано на idiBus. Буквально как и описано в статье. Вместо разработки новой специфичной электроники все собрано на готовых модулях idiBus. Есть АСУ внутри аппарата а есть АСУ размера предприятия или производственной линии.
В этом случае все внутри.
Инерционности кстати никакой нет. Если вдруг давление скакнуло, то надо немедленно что-то делать. Пока не разорвало все. Управление инерционным процессом требует крайне быстрой реакции на аварии.
Программиста я имею ввиду того, который станок автоматизирует. Или теплицу. Или прокатный стан. Вот он в системе idiBus это просто любой программист.
Иногда создается ощущение, что АСУшники считают себя некоей высшей кастой.
А заказчикам как раз требуется ровно обратную задачу решить - иметь возможность нанять на рынке сотрудника, выбирая из максимально широкого круга кандидатов.
И тогда идеология, когда любой С++ программист может делать эту работку очень устроит заказчиков. А сейчас он вынужден выбирать (а в его городе может и вовсе не быть) из тех, кто изучил проприетарную систему какого-то производителя.
А ему надо обустроить свою бетономешалку. И вообще не нужен человек для этого на постоянную зарплату.
Я стою в логике решений на стороне заказчика. То есть на стороне экономики.
"А, то есть речь о программисте софта верхнего уровня. А кто делает эти устройства — вы сами? Тогда выглядит как способ подсадить пользователя на ваше оборудование и чтобы он никогда не слез."
Мы делаем устройства и любой другой тоже может делать устройства.
В чем разница между регистрами и функциями? В том что функции у всех одинаковые. Логика, обработка ошибок и функций и протокола. А регистры у каждого свои и своя логика конвертации внутренней структуры в эти регистры.
Да это более высокий уровень абстракции, вынесенный на уровень протокола.
Но уже давно никто не придерживается сетевой модели OSI.
Даже ему дадим базовые библиотеки от протокола, на которые он допишет только свою специфику. О монополии речь не идет. Наоборот. Это возможность для производителей датчиков и других устройств очень дешево их "оцифрить".
В конкуренции протоколов и систем АСУ выиграют тот у кого цены ниже и ниже себестоимость. А те у кого оно все дороже пытаются всякими путями защитить свои цены.
А государство тем временем уже не первый год импортозамещает
"Тендер на проведение ОКР был опубликован 27 октября 2022 г. в формате открытого запроса предложений с начальной ценой договора в 284,9 млн руб. Претендентами, помимо РАСУ выступили НТЦ «Интернавигация» с предложением в 235,5 млн руб. и НИИ «Солитон», готовый выполнить работы за 196,6 млн руб., однако их заявки были отклонены." Даже вот люди хотели на 100 млн дешевле сделать да им не дали. Развивают кота в мешке и монополию на этого кота.
https://www.cnews.ru/news/top/2023-02-28_promyshlennye_kontrollery
С аудиторией мы конечно не честны. Скоро на всех кредитов наберем.)
Ну "ваша" это означает где вы работаете. Ну так что вам как пользователю не нравится? что есть новый стандарт и устройства к нему? Или что система так устроена, что любой школьник может с ней работать имея багаж кружка робототехники?
Нет задачи заставить всех создавать паровозы. Наоборот. Есть задача создать такой паровоз на котором любой ребенок может кататься.
"Поделие" вовсю работает и не ломается.
Шифрованые данные это уже не оригинал а новый протокол. Цитата тут: https://modbus.org/docs/Modbus-SecurityPR-10-2018.pdf
Обновление прошивок возможно как и вовсе передача любых данных в пакетах. Однако есть разница между единым механизмом и чисто теоретической возможностью которую каждый реализует по-разному. В idiBus вы можете узнать у устройства оно вообще имеет прошивку или нет? это обязанность устройства так как часть протокола.
Выдачу данных через сервер конверсии бит в физические величины можно применять вообще с любым устройством. Взяли слева биты и послали направо. и справа пришли значения. Но тут то речь идет о том, что само устройство уже вполне может это делать и само цена этой функции - ноль так как в любом устройстве уже стоит чип как в телефоне.
Можно уже в тетрис играть на датчиках давления.
Коллизии разруливаются как в других протоколах.
К мастеру можно обращаться вне очереди. В случаях повышения или снижения давления, температуры или по любой срочной надобности что бы не ждать своей очереди в опросе.
Групповые опросы масками не решить. Это механизм для разных устройств. Любого типа. В физических процессах часто надо мерять не один параметр а несколько но нужны их значения именно в один момент времени. Когда они динамичны. Например давление и температура. Измерение происходит в один момент, а получение этих данных может быть и последовательное.
Безопасный режим это способ сохранения системы если имеются сбои и надо ввести систему или ее часть в состоянии когда она своими действиями не может себя разрушить.
Совместимость по линии это означает что логика протокола такова, что к стоящим на линии устройствам MODBUS можно от мастера обращаться без изменения логики и без изменения физики. Устройства MODBUS просто не замечают траффика idiBus.
в протоколе только базовый набор функций. В этом наборе вообще нет ничего про передачу конкретных данных. И есть способ для расширения числа функций. Их самих в протоколе нет но процесс их обслуживания уже есть. предусмотрено количество функций от 1 до 219. И есть набор стандартных для всех модулей команд. Init, Shutdown, Sleep.
Набор данных для каждой функции может быть большим. И ответ от частотника тоже.
Приборы которые имеют MODBUS можно непосредственно подключать. И пользоваться как обычно. Регистры и все прочее. Можно миксовать на одной линии. И постепенно менять иностранное на наше.
У меня партнер был 10 лет главным импортером Эмерсона. Теперь вот сложности с импортом.
Мы говорим о том, что данфосс не дает Драйверов. Ибо в мире компов есть линукс яблоко и виндовс. и как-то драйверы люди пишут к этому.
А в мире омронов и эмерсонов даже внутри эмерсонов все по-разному.
Филдбасы придумали новый разъем и новый провод. Который у нас вообще некому произвести.
В РФ явно требуется момент объединения под одну крышу всем.
Рынок наш настолько мал и настолько занят иностранцами, что своего мы никогда не сделаем если не объединимся хотя бы при АСУ хотя бы какой-то большой части устройств.
Пока в РФ никто не готов заменить систему управления вентиляцией очистного здания. Ибо там много устройств.
Можно или уходить к китайцам (корейцы тоже вон санкции устроили) или левый импорт делать.
Но нам больше нравится вариант - откусывать от иностранного АСУ куски в пользу наших разработчиков аппаратуры. и датчиков и Серв и контроллеров.
Наша идея - более простое проектирование с широким кругом программистов на стандартных языках. и более дешевые устройства. совместимость обратная с MODBUS.
Что бы выпустить какие-то датчики давления или влажности или еще чего-то надо и сам датчик и его оцифрить.
Мы даем цифру. Дешево и сердито. И любой студент может программировать все это.
Позже подцепимся к SCADA какому-то открытому.
Если государство довело эту сферу до того, что ни одного ЖК экрана в стране сенсорного не производится и прости господи сотни миллионов тратятся на контроллеры типа "БАГЕТ", то кто-то должен начать процесс объединения национальных разработчиков.
И глупо при этом не воспользоваться тем, что за 40 лет цифра стала такая дешевая, что можно ее в сигареты засовывать.
В РФ промышленное оборудование, которому надо АСУТП всегда малые серии. Рынок такой и никто не умеет ничего экспортировать.
idiBus решает задачу удешевления этой автоматики. От лифтов и станков до теплиц и бетономешалок.
Отнюдь. список функций всяко проще списка функций плюс таблица адресов и регистров. плюс надо еще написать некую функцию для установки этих регистров и не ошибиться.
вызвать setСкоростьТорможения(%) и удобнее и контроль ошибок доступен. Модуль idiBus выдаcт специальный тип ошибки - что разработчик задал значение вне диапазона.
а в слейвах нет времени. вот мы тут все сидим сейчас а где-то проектируют датчик давления. Без времени. Работает по факту запроса.
В базовом протоколе именно поэтому нет синхронизации времени.
Одновременность решена возможностью объединения в группы и отправка групповой команды сразу всем членам группы.
Отложенная передача данных откуда и куда? Если потеря связи то мастер стучит и потом докладывает что не достучался. Это не часть протокола. Это ошибка связи. А отложенной передачи из слейва нет. Есть передача больших пакетов данных (состоящих из более чем одного модуля данных) с подтверждением получения очередного пакета.
Есть в качестве устройства на шине например уже готовый модуль логгирования. Там стоит флешка и часы реального времени.
В нем же можно хранить переводы текстовых значений для кодов ошибок для разных языков. Коды и индексация языков тоже стандартизированы.
Кстати кто такой комтрейд? я приезжий не все слова еще знаю
ясный перец что код будет открытый. готовим документацию и вывалим на какой-то гит