Совсем не понял автовора, где в статье IIoT? "В этой статье мы расскажем, как промышленный интернет вещей и искусственный интеллект (Industrial IoT + AI) позволяют автоматизировать традиционный бизнес" - а зачем вы тяните промышленный IoT в традиционный бизнес? После прочтения статьи ощущение, что IoT равно IIoT. Так же это прослеживается тут "Судя по последнему отчету немецкой исследовательской компании IoT Analytics, количество проектов по автоматизации бизнеса ... на базе IIoT продолжает расти". Пояснить ваш концепт в рамках традиционного бизнеса для промки: АСУ ТП - MES системы - ERP системы - BI системы? Почему 10-15 лет назад при решении такой же задачи ни кто не называл это IIoT? На производствах множество решений КиП, который позволяет проверять профиль древесины и не только его. Такие задачи решали и 20 и 30 лет назад. Было тогда и есть сейчас, когда это стало IIoT и почему традиционные подходы в промышленности не подходят? Почему по вашему мнению производство без приставки tech? Если это самое настоящее тех, автоматизация технологического процессов и производств началась уже давно. Индустрия 3 существовала до индустрии 4.0! Первые паровые машины и вся автоматизации процессов и началась с производства. А после прочтения вашей статьи кажется, что промышленность ниша которая достаточно неразвитая. Если,что Индустрия 3.0 - это ПЛК, современный КиП, ЧПУ, робототехника, все пром сети (profinet, ethercat и др.), которые используются на производстве и вы их называете не tech :)
А вы думали использовать плис + мк. На плис гораздо легче откатать алгоритмы foc , управление ключами и т.п. а на мк вынести только ui управления кнопки и др. ? Плюс когда вы развяжите критично важный узел через плис, программирование мк будет сказка очень легко. На мк легче навернуть пром сети и др. А foc для acim уже будет сам все на плис.
Посмотрел исходники вашего проекта, вы используете либу Inverter_firmware/MotorControlLib, и как я правильно понял из либы у вас PMSM, все важные алгоритмы для вашего проекта закрыты, есть только ашники. Плюс в статье у вас ACIM привод, а pmsm не равно ACIM в управлении, если вы хотите реализовать foc для amic, придется писать самостоятельно алгоритмы (и там действительно все не просто, почитайте реализацию наблюдателей хотя бы для pmsm). Да и векторное для АС приводов у вас не заработает с этой либой никогда. Для скалярного управление это библа тоже не подойдет (как я правильно понял поэтому в сами и реализовывали скаляр. управление). Идея хорошая), но без алгоритмов все будет провально. Если вы использовали эту либо значит не совсем понимаете как векторное управление реализовывается на практике (могу ошибаться), почитайте Анучина А.С. (https://habr.com/ru/company/npf_vektor/blog/389793/ в статье Векторная датчиковая структура управления асинхронным двигателем) . посмотрите проекты: VESC-controller, ODrive) Удачи с проектом! Хорошая статья!
Не совсем понятно "Особенно в решении компании ABB (слева) клавиатуру можно было бы реализовать гораздо лучше.", поясните, пожалуйста, почему вы так считаете? И почему вы отнесли решение ABB к old, а универсальный терминал Сириус-2Л-02 к new?
Вы использовали в работе все перечич. оборудование релейной защиты и автоматики? Вы проводили опрос среди людей, компаний которые их монтажат, эксплицируют, настраивают, или это просто сухой взгляд дизайнера, который оценил только визуальную часть панели, без оценки настройки устройства, удобство монтажа, клеммных соединителей и т.п.?
Хорошо написано). Но раздел промышленные контроллеры, проработан недостаточно. Первый вариант картинки это old-old скул корпуса. Второй вариант это old корпуса (такие корпуса были 15-20 лет назад). Если смотреть тренд лучше посмотреть в сторону phoenixcontact. Промышленный контроллер (на картинке new) совсем немодульный, это говорит о том что контроллер начального уровня и контроллер совсем не мультифункциональный. Тренд - это когда ПЛК имеет возможно быстрой замены клем например ME-PLC multifunctional housings (phoenixcontact). Когда, действительно есть возможно обмена по локальной шине (а не перекидыванием шлейфа с модуля на модуль). Например, как ME-IO multifunctional housings, у них специальные клемы по которым идет передача питания, и например + rs485 (modbus rtu)/can/fdcan (openCAN) в качестве шины обмена данными. И сами клемы ME-IO multifunctional housings быстрозажимные. Даже если взять тот Siemens S7-1500 которому почти 10 лет, он намного лучше продуман, чем корпус на картинке 'new', а Siemens S7-1500 это уже не тренд, а больше old. Тренд для ПЛК -это возможность удобного и быстро монтажа, функциональность, удобство обслуживания, эстетика корпуса и т.п.
Насчет Контроллеры компаний LS Electric (слева) и Bosch (справа) ссылка на LS Electric верная, картинка которую вы добавили это вообще не контроллер :)))) ...
В компаниях Hager и ABB Group запустили линейку контроллеров с фирменными яркими полосками и цветными крышечками. Мелочь, но уже веселее, чем китайские модели выше
"GitHub на моё удивление не знает про существование ST" - знает. Есть опенсорный отличный проект matiec. Разные ПЛК используют разные ОС, не на всех ПЛК есть ОС, некоторые вообще работают на ПЛИС, а компилятор имеет структуру IEC 61131-3 -> LLVM IR -> RTL (Verilog или VHDL), некоторые работают на мк на baremetal, без ОС. "Использовать систему контроля версий в большинстве случаев бессмысленно так как ваш проект будет представлять один бинарный файл" - многие IDE хранят файлы проекты и сам "код" в формате XML. Использовать систему контроля версий - нужно использовать всегда, 21 век. Неужели, кто до сих пор хранит файлы в архивах и т.п, и формируя бессмысленные названия для файлов.
8 лет уже немолодой язык. Да и SDNet уже слабо развивается, если вообще сказать не сдулся. Была похожая статья: https://habr.com/ru/company/fgts/blog/460439/. В рамках FPGA NetFPGA было бы интереснее почитать.
советую брать openocd от сюда (openocd.zylin.com)
git clone openocd.zylin.com/openocd
и после собрать
./bootstrap
./configure --enable-ft2232_ftd2xx
make
sudo make install
можно так:
openocd -f interface/stlink.cfg -f target/stm8l.cfg -c «init» -c «reset init»
либо так
openocd -f interface/stlink.cfg -f target/stm8l152.cfg -c «init» -c «reset init»
1. stm32mp1 — это не микроконтроллер, а микропроцессор (https://www.st.com/en/microcontrollers-microprocessors/stm32mp1-series.html, STM32MP1 microprocessor series with dual Arm® Cortex®-A7 and Cortex®-M4 Cores)
2. «Поскольку ядро М4 работает под управлением А7, значит под управлением OpenSTLinux.» Не догма, Developers should note that OpenSTLinux Distribituion is not a specific, custom Linux distribution. Вы может использовать buildroot для сборки тоже, плюс можно там и там запускать и bare-metal и rtos.
3. Raspberry в разы мощнее чем mp1
4. «В этом кристалле у ядра М4 есть только оперативная память и код выполняется из нее (из даташита):» скорее правильно написать:
All devices feature:
• SYSRAM in MPU domain: 256 Kbytes
• SRAM1 in MCU domain: 128 Kbytes
• SRAM2 in MCU domain: 128 Kbytes
• SRAM3 in MCU domain: 64 Kbytes
• SRAM4 in MCU domain: 64 Kbytes
• RETRAM (retention RAM): 64 Kbytes
The content of this area can be retained in Standby or VBAT mode.
• BKPSRAM (backup SRAM): 4 Kbytes
The content of this area is protected against possible unwanted write accesses, and
can be retained in Standby or VBAT mode.
BKPSRAM can be defined (in ETZPC) as accessible by secure software only
там память шарится между ядрами.
Спасибо за статью, но статья содержит некоторое на мой взгляд количество неточностей:
Общая схема автоматизации промышленного объекта не имеет отображение исполнительных механизмов, странно так же изображать модуль 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 и т. п.?
Совсем не понял автовора, где в статье IIoT? "В этой статье мы расскажем, как промышленный интернет вещей и искусственный интеллект (Industrial IoT + AI) позволяют автоматизировать традиционный бизнес" - а зачем вы тяните промышленный IoT в традиционный бизнес? После прочтения статьи ощущение, что IoT равно IIoT. Так же это прослеживается тут "Судя по последнему отчету немецкой исследовательской компании IoT Analytics, количество проектов по автоматизации бизнеса ... на базе IIoT продолжает расти". Пояснить ваш концепт в рамках традиционного бизнеса для промки: АСУ ТП - MES системы - ERP системы - BI системы? Почему 10-15 лет назад при решении такой же задачи ни кто не называл это IIoT? На производствах множество решений КиП, который позволяет проверять профиль древесины и не только его. Такие задачи решали и 20 и 30 лет назад. Было тогда и есть сейчас, когда это стало IIoT и почему традиционные подходы в промышленности не подходят? Почему по вашему мнению производство без приставки tech? Если это самое настоящее тех, автоматизация технологического процессов и производств началась уже давно. Индустрия 3 существовала до индустрии 4.0! Первые паровые машины и вся автоматизации процессов и началась с производства. А после прочтения вашей статьи кажется, что промышленность ниша которая достаточно неразвитая. Если,что Индустрия 3.0 - это ПЛК, современный КиП, ЧПУ, робототехника, все пром сети (profinet, ethercat и др.), которые используются на производстве и вы их называете не tech :)
А вы думали использовать плис + мк. На плис гораздо легче откатать алгоритмы foc , управление ключами и т.п. а на мк вынести только ui управления кнопки и др. ? Плюс когда вы развяжите критично важный узел через плис, программирование мк будет сказка очень легко. На мк легче навернуть пром сети и др. А foc для acim уже будет сам все на плис.
Посмотрел исходники вашего проекта, вы используете либу Inverter_firmware/MotorControlLib, и как я правильно понял из либы у вас PMSM, все важные алгоритмы для вашего проекта закрыты, есть только ашники. Плюс в статье у вас ACIM привод, а pmsm не равно ACIM в управлении, если вы хотите реализовать foc для amic, придется писать самостоятельно алгоритмы (и там действительно все не просто, почитайте реализацию наблюдателей хотя бы для pmsm). Да и векторное для АС приводов у вас не заработает с этой либой никогда. Для скалярного управление это библа тоже не подойдет (как я правильно понял поэтому в сами и реализовывали скаляр. управление). Идея хорошая), но без алгоритмов все будет провально. Если вы использовали эту либо значит не совсем понимаете как векторное управление реализовывается на практике (могу ошибаться), почитайте Анучина А.С. (https://habr.com/ru/company/npf_vektor/blog/389793/ в статье Векторная датчиковая структура управления асинхронным двигателем) . посмотрите проекты: VESC-controller, ODrive) Удачи с проектом! Хорошая статья!
Не совсем понятно "Особенно в решении компании ABB (слева) клавиатуру можно было бы реализовать гораздо лучше.", поясните, пожалуйста, почему вы так считаете? И почему вы отнесли решение ABB к old, а универсальный терминал Сириус-2Л-02 к new?
Вы использовали в работе все перечич. оборудование релейной защиты и автоматики? Вы проводили опрос среди людей, компаний которые их монтажат, эксплицируют, настраивают, или это просто сухой взгляд дизайнера, который оценил только визуальную часть панели, без оценки настройки устройства, удобство монтажа, клеммных соединителей и т.п.?
Хорошо написано). Но раздел промышленные контроллеры, проработан недостаточно. Первый вариант картинки это old-old скул корпуса. Второй вариант это old корпуса (такие корпуса были 15-20 лет назад). Если смотреть тренд лучше посмотреть в сторону phoenixcontact. Промышленный контроллер (на картинке new) совсем немодульный, это говорит о том что контроллер начального уровня и контроллер совсем не мультифункциональный. Тренд - это когда ПЛК имеет возможно быстрой замены клем например ME-PLC multifunctional housings (phoenixcontact). Когда, действительно есть возможно обмена по локальной шине (а не перекидыванием шлейфа с модуля на модуль). Например, как ME-IO multifunctional housings, у них специальные клемы по которым идет передача питания, и например + rs485 (modbus rtu)/can/fdcan (openCAN) в качестве шины обмена данными. И сами клемы ME-IO multifunctional housings быстрозажимные. Даже если взять тот Siemens S7-1500 которому почти 10 лет, он намного лучше продуман, чем корпус на картинке 'new', а Siemens S7-1500 это уже не тренд, а больше old. Тренд для ПЛК -это возможность удобного и быстро монтажа, функциональность, удобство обслуживания, эстетика корпуса и т.п.
Насчет Контроллеры компаний LS Electric (слева) и Bosch (справа) ссылка на LS Electric верная, картинка которую вы добавили это вообще не контроллер :)))) ...
В компаниях Hager и ABB Group запустили линейку контроллеров с фирменными яркими полосками и цветными крышечками. Мелочь, но уже веселее, чем китайские модели выше
Тоже не контроллер :)))) ....
Интересно
"GitHub на моё удивление не знает про существование ST" - знает. Есть опенсорный отличный проект matiec. Разные ПЛК используют разные ОС, не на всех ПЛК есть ОС, некоторые вообще работают на ПЛИС, а компилятор имеет структуру IEC 61131-3 -> LLVM IR -> RTL (Verilog или VHDL), некоторые работают на мк на baremetal, без ОС. "Использовать систему контроля версий в большинстве случаев бессмысленно так как ваш проект будет представлять один бинарный файл" - многие IDE хранят файлы проекты и сам "код" в формате XML. Использовать систему контроля версий - нужно использовать всегда, 21 век. Неужели, кто до сих пор хранит файлы в архивах и т.п, и формируя бессмысленные названия для файлов.
8 лет уже немолодой язык. Да и SDNet уже слабо развивается, если вообще сказать не сдулся. Была похожая статья: https://habr.com/ru/company/fgts/blog/460439/. В рамках FPGA NetFPGA было бы интереснее почитать.
git clone openocd.zylin.com/openocd
и после собрать
./bootstrap
./configure --enable-ft2232_ftd2xx
make
sudo make install
можно так:
openocd -f interface/stlink.cfg -f target/stm8l.cfg -c «init» -c «reset init»
либо так
openocd -f interface/stlink.cfg -f target/stm8l152.cfg -c «init» -c «reset init»
2. «Поскольку ядро М4 работает под управлением А7, значит под управлением OpenSTLinux.» Не догма, Developers should note that OpenSTLinux Distribituion is not a specific, custom Linux distribution. Вы может использовать buildroot для сборки тоже, плюс можно там и там запускать и bare-metal и rtos.
3. Raspberry в разы мощнее чем mp1
4. «В этом кристалле у ядра М4 есть только оперативная память и код выполняется из нее (из даташита):» скорее правильно написать:
All devices feature:
• SYSRAM in MPU domain: 256 Kbytes
• SRAM1 in MCU domain: 128 Kbytes
• SRAM2 in MCU domain: 128 Kbytes
• SRAM3 in MCU domain: 64 Kbytes
• SRAM4 in MCU domain: 64 Kbytes
• RETRAM (retention RAM): 64 Kbytes
The content of this area can be retained in Standby or VBAT mode.
• BKPSRAM (backup SRAM): 4 Kbytes
The content of this area is protected against possible unwanted write accesses, and
can be retained in Standby or VBAT mode.
BKPSRAM can be defined (in ETZPC) as accessible by secure software only
там память шарится между ядрами.
Круто, как всегда! Респект.
Молодцы ребята, респект Вам
Общая схема автоматизации промышленного объекта не имеет отображение исполнительных механизмов, странно так же изображать модуль 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 и т. п.?