Мегагерцы НЕ решают? Сравнение Esp32, Stm32 и др.

[Phazz]

Я вообще о чем хотел сказать, что с этими стм32 про есп32 8266 совсем забыли к сожалению. И например баг с торможением при подключении к несуществующей точке доступа так и остался без внимания. Пытался я самостоятельно исправить этот баг в библиотеке, но не хватило мозгов разобраться с библиотекой)

[ecoins]

Я вообще о чем хотел сказать, что с этими стм32 про есп32 8266 совсем забыли к сожалению. И например баг с торможением при подключении к несуществующей точке доступа так и остался без внимания. Пытался я самостоятельно исправить этот баг в библиотеке, но не хватило мозгов разобраться с библиотекой)

С этим согласен.
Сергей подготовил версию 9.3.5 - она сейчас тестируется. Там много улучшений и полезного.
Наверное Ander её может направлять желающим.
К числа 20-го наверное Сергей оформит новый релиз.
Вроде бы по STM32 (и не только) FLProg существенно продвинулся.
После релиза наверное можно просить Сергея подтянуть ESP32.
Я тоже присоединяюсь к этим просьбам.
С уважением, ecoins.

[Rovki]

Да используйте любые камни от attyni до Stm , под конкретную задачу с учётом опыта работы . Я за 15 лет не исчерпал возможностей применения ПР200, заранее не брался за те задачи, которые им не под силу. Правда сейчас нашел альтернативу есп ( прежде всего по цене). За циклами никогда не гнался , введу тех задач которые решал в системах автоматизации. На выходе то все равно были реле. Да и промышленных ПЛК с интерфейсами i2c ,spi не встречал для использования пользователями , разве что модули расширения штатные на них вешают.

[kilemch5]

а если на есп активировать вайфай то она становилась слабее блупилки

а если блупилку заставить обрабатывать вайфай - то она еще хуже есп будет)))

Сарказм тут не работает Вы должны прекрасно понимать что у ESP на wi-fi завязаны отдельное ядро а второе ядро обрабатывает код собственно два ядра там не работают против одного ядра СТМ наверняка видео об этом говорится

у esp8266 2 ядра?))

[kilemch5]

Многие 3D - принтеры делались именно на MEGA2560

При этом могут держать сетевое соединение и обрабатывать вэбинтерфейс?

На коротеньких и линейных программах все быстро, но чуть размер и алгоритм усложняется, резко падает быстродействия.

не совсем согласен с такими выводами. Работа с чпу тому пример. Код очень большой и сложный.

Я не знаю что содержалось в коде и отключили ли вы радиомодуль при этом. Но даже в вашем тесте 2560 не лучше. В общем есть вопросы к методикам. Как собственно и у Гайвера тоже.
А от куда информация про 80МГц?

В любом случае esp32 универсальная и не дорогая плата и она очень нужна для diy. А эти миллионы циклов мало кому нужны и esp32 покрывает очень большую часть задач.

1.Я не против ESP32.
2."При этом могут держать сетевое соединение и обрабатывать вэбинтерфейс?" - наверное могут. И хорошо бы если во время работы Wi-Fi не вмешивался в работу двигателей. Возможно что на каких-то участках движения WiFi блокируют, а при передвижении включают.
Эту тему я не исследовал, ЧПУ на ESP32 не встречал. Непосредственно на FLProg одновременная работа двигателей и Wi-Fi - возможно возникнут проблемы. А может и не возникнут... Но я бы такую конструкцию не решился бы делать.
3."Но даже в вашем тесте 2560 не лучше." - Поверьте на слово. При тесте большого объема (много сенсоров и расширителей важен объем и нелинейность алгоритма) ESP32 был медленнее Mega2560 и даже ESP8266! После получения первых результатов я сам удивился, много раз перепроверял и исследовал эту проблему больше года. Не уверен в абсолютной точности моих выводов, но в целом картину обрисовал и она похоже на реалтстичность.
4."В общем есть вопросы к методикам. Как собственно и у Гайвера тоже" - согласен. Но есть и откровенно провокационные методики. Еще один пример - проверять быстродействие по команде digitalWrite() - именно из команд работы с пинами на ESP32 долгое время были проблемы с DS1820,DHT22. Возможно что в новых версиях кое-что поправили в CORE, но не уверен.
5."Я не знаю что содержалось в коде и отключили ли вы радиомодуль при этом" - в приведенном тесте радиоканал не использовался.
6."А от куда информация про 80МГц?"
80мГц.jpeg
После CPU 240 мГц стоит уточнение (WiFi,BT).
Ниже скорость FLASH 80мгц. Не может процессор работать намного быстрее, чем считываемые из памяти инструкции.
Часть ответственного кода можно разместить в оперативной памяти - будет быстрее.
Но в практике FLProg это редко используется.
7."А эти миллионы циклов мало кому нужны" - наверное кому-то и не нужны. Но часто сталкиваюсь с удивлением, почему-то в каком-то сочетании блоков и алгоритмов что-то "тормозит" или не работает....
8."покрывает очень большую часть задач" - действительно большую.
Но серьезные производители промышленных контроллеров в сторону ESP пока не смотрят.
Фирма ST выпускает чипы с радиоканалом (семейство WB,WL), делают это за счет двух разных процессоров.
В сторону WiFi на ядре пока не смотрят.
А технологические и конструкторские возможности у них существенно выше чем у ESP.
-----
С уважением, ecoins.

все ваши проблемы с есп32 - это из-за того что вы пытаетесь работать с ней из-под arduino ide)))

дело в том, что есп32 работает ТОЛЬКО под rtos, а работа с есп32 из-под arduino ide (и значит изпод flprog) - это работа с виртуализацией.

Аналогично работает винда, эмулируя линукс или линукс, эмулируя винду, или винда эмулируя андроид....


именно отсюда полнейшее непонимание работы есп32 и написание кода для нее: короче переходите на RTOS, для того чтобы раскрыть весь потенциал есп32)))

[ecoins]

все ваши проблемы с есп32 - это из-за того что вы пытаетесь работать с ней из-под arduino ide)))
дело в том, что есп32 работает ТОЛЬКО под rtos, а работа с есп32 из-под arduino ide (и значит изпод flprog) - это работа с виртуализацией.
Аналогично работает винда, эмулируя линукс или линукс, эмулируя винду, или винда эмулируя андроид....
именно отсюда полнейшее непонимание работы есп32 и написание кода для нее: короче переходите на RTOS, для того чтобы раскрыть весь потенциал есп32)))

Полагаю Ваши утверждения носят декларативный характер. Вы сами работаете под RTOS?
Использование RTOS не отменяет обсуждаемые проблемы.
FLProg является много платформенной системой - это одно из её ключевых достоинств.
По использованию RTOS.
Приведите преимущества использование RTOS в проектах FLProg.
Для справки: В FLProg при планировании задач используются
1.аппаратные прерывания от таймеров;
2.аппаратные прерывания от пинов;
3.планирование задач от программного таймера (чтобы не конфликтовать с приоритетными задачами от таймера);
4.диспетчер задач;
5.выполнение плат по условиям пользователя.
В следствии простоты передача управления приоритетными задачам происходит быстрее чем в RTOS.

[ecoins]

Да используйте любые камни от attyni до Stm , под конкретную задачу с учётом опыта работы . Я за 15 лет не исчерпал возможностей применения ПР200, заранее не брался за те задачи, которые им не под силу. Правда сейчас нашел альтернативу есп ( прежде всего по цене). За циклами никогда не гнался , введу тех задач которые решал в системах автоматизации. На выходе то все равно были реле. Да и промышленных ПЛК с интерфейсами i2c ,spi не встречал для использования пользователями , разве что модули расширения штатные на них вешают.

Думаю в ПР200 модули расширения подключаются через SPI.

[Phazz]

все ваши проблемы с есп32 - это из-за того что вы пытаетесь работать с ней из-под arduino ide)))

дело в том, что есп32 работает ТОЛЬКО под rtos, а работа с есп32 из-под arduino ide (и значит изпод flprog) - это работа с виртуализацией.

Аналогично работает винда, эмулируя линукс или линукс, эмулируя винду, или винда эмулируя андроид....


именно отсюда полнейшее непонимание работы есп32 и написание кода для нее: короче переходите на RTOS, для того чтобы раскрыть весь потенциал есп32)))

Что-то странное вы говорите. В Ардуино также можно использовать RTOS правда не все функции. И ни о какой виртуализации речи там нет. Но по сути rtos это тоже диспетчер задач, только он еще за временем выполнения следит. Контроль времени и усыпление задачи это самые крутые функции rtos на мой взгляд.
Проблема в другом диспетчер это универсальный инструмент для всех мк. А RTOS это ESP, 2040 и STM32. И я честно сказать с трудом себе представляю его использование в FLPROG, слишком тонкие настройки нужны для каждой задачи. Платы в флпрог для этого не очень подходят.

[Rovki]

Да используйте любые камни от attyni до Stm , под конкретную задачу с учётом опыта работы . Я за 15 лет не исчерпал возможностей применения ПР200, заранее не брался за те задачи, которые им не под силу. Правда сейчас нашел альтернативу есп ( прежде всего по цене). За циклами никогда не гнался , введу тех задач которые решал в системах автоматизации. На выходе то все равно были реле. Да и промышленных ПЛК с интерфейсами i2c ,spi не встречал для использования пользователями , разве что модули расширения штатные на них вешают.

Думаю в ПР200 модули расширения подключаются через SPI.

да по адаптированному SPI, но разработчиком ,а не пользователем .

[ecoins]

Да используйте любые камни от attyni до Stm , под конкретную задачу с учётом опыта работы . Я за 15 лет не исчерпал возможностей применения ПР200, заранее не брался за те задачи, которые им не под силу. Правда сейчас нашел альтернативу есп ( прежде всего по цене). За циклами никогда не гнался , введу тех задач которые решал в системах автоматизации. На выходе то все равно были реле. Да и промышленных ПЛК с интерфейсами i2c ,spi не встречал для использования пользователями , разве что модули расширения штатные на них вешают.

Думаю в ПР200 модули расширения подключаются через SPI.

да по адаптированному SPI, но разработчиком ,а не пользователем .

А чем адаптированный модуль отличается от не адаптированного?
Тем что модули расширения ПР200 привязаны к конкретным пинам и доступ к ним из OwenLogic затруднен.
Это маркетинговая стратегия ОВЕН - схем и понимания макросов и прочего в открытом доступе от разработчика нет.
У других производителей программируемых реле схожий подход.
Это позволяет снижать возможности сторонних разработчиков с вхождением в их среду и держать высокую цену на электронные изделия.
------
У FLProg напротив максимальная открытость программного кода и соответственно доступ к новым интерфейсам, которые немыслимы в традиционных ПЛК.
И FLProg открывает возможности для альтернативных разработчиков электроники, в том числе для отдельных конструкторов ориентированных на конкретные задачи.
------
В своем "Народном контроллере" Вы в качестве межплатного интерфейса применили i2c.
Этот же симпатичный подход 20-лет назад применила фирма "Фрактал" (Зеленоград) в своей модульной системе автоматизации.
Система имеет разные модули в том числе i2c-RS485, i2c-UART, i2c-PCF8575-DS1820 , i2c-удаленный i2c и другие.
Модули делались в том числе для оборонки и космической отрасли.
------
На ПР200 шаговыми двигателями Вы особо не поуправляете, в FLProg со встроенном блоке управления двигателями Вы это сможете сделать и на ESP32.
Еще лучше у Вас это получится если воспользуетесь новыми контроллерами FLProg связав Каскаду через мост Wi-Fi - RS-232
------
FLPrpog слава!
Вам с большим уважением, ecoins!

[kilemch5]

Думаю в ПР200 модули расширения подключаются через SPI.

да по адаптированному SPI, но разработчиком ,а не пользователем .

А чем адаптированный модуль отличается от не адаптированного?
Тем что модули расширения ПР200 привязаны к конкретным пинам и доступ к ним из OwenLogic затруднен.
Это маркетинговая стратегия ОВЕН - схем и понимания макросов и прочего в открытом доступе от разработчика нет.
У других производителей программируемых реле схожий подход.
Это позволяет снижать возможности сторонних разработчиков с вхождением в их среду и держать высокую цену на электронные изделия.
------
У FLProg напротив максимальная открытость программного кода и соответственно доступ к новым интерфейсам, которые немыслимы в традиционных ПЛК.
И FLProg открывает возможности для альтернативных разработчиков электроники, в том числе для отдельных конструкторов ориентированных на конкретные задачи.
------
В своем "Народном контроллере" Вы в качестве межплатного интерфейса применили i2c.
Этот же симпатичный подход 20-лет назад применила фирма "Фрактал" (Зеленоград) в своей модульной системе автоматизации.
Система имеет разные модули в том числе i2c-RS485, i2c-UART, i2c-PCF8575-DS1820 , i2c-удаленный i2c и другие.
Модули делались в том числе для оборонки и космической отрасли.
------
На ПР200 шаговыми двигателями Вы особо не поуправляете, в FLProg со встроенном блоке управления двигателями Вы это сможете сделать и на ESP32.
Еще лучше у Вас это получится если воспользуетесь новыми контроллерами FLProg связав Каскаду через мост Wi-Fi - RS-232
------
FLPrpog слава!
Вам с большим уважением, ecoins!

вот тут согласен полностью!

[Rovki]

Думаю в ПР200 модули расширения подключаются через SPI.

да по адаптированному SPI, но разработчиком ,а не пользователем .

А чем адаптированный модуль отличается от не адаптированного?
Тем что модули расширения ПР200 привязаны к конкретным пинам и доступ к ним из OwenLogic затруднен.
Это маркетинговая стратегия ОВЕН - схем и понимания макросов и прочего в открытом доступе от разработчика нет.
У других производителей программируемых реле схожий подход.
Это позволяет снижать возможности сторонних разработчиков с вхождением в их среду и держать высокую цену на электронные изделия.
------
У FLProg напротив максимальная открытость программного кода и соответственно доступ к новым интерфейсам, которые немыслимы в традиционных ПЛК.
И FLProg открывает возможности для альтернативных разработчиков электроники, в том числе для отдельных конструкторов ориентированных на конкретные задачи.
------
В своем "Народном контроллере" Вы в качестве межплатного интерфейса применили i2c.
Этот же симпатичный подход 20-лет назад применила фирма "Фрактал" (Зеленоград) в своей модульной системе автоматизации.
Система имеет разные модули в том числе i2c-RS485, i2c-UART, i2c-PCF8575-DS1820 , i2c-удаленный i2c и другие.
Модули делались в том числе для оборонки и космической отрасли.
------
На ПР200 шаговыми двигателями Вы особо не поуправляете, в FLProg со встроенном блоке управления двигателями Вы это сможете сделать и на ESP32.
Еще лучше у Вас это получится если воспользуетесь новыми контроллерами FLProg связав Каскаду через мост Wi-Fi - RS-232 1
------
FLPrpog слава!
Вам с большим уважением, ecoins!

1. Не только маркетинг , но и гарантийное обслуживание .если внутренние интерфейсы вытащить наружу и дать пользователю с ними работать как на аппаратном ,так и программном уровне, то потом крайних не найти
2.фл прог не знает о том куда разработчик вытащит и как кишки наружу. Это задача разработчика ПЛК , а не пользователя.Но то что так не делают остальные это наталкивает ответственного разработчика на определенные мысли.
3.это все делалось в рамках одного устройства, конструктивна для конкретного применения этими же разработчиками , а не для широкого применения другими пользователями.
4. Задач автоматизации производств на сотни порядков больше ,чем управления приводами, для них ПЛК и специальные драйверы
Каскаде все равно с какими ПЛК работать лишь бы был модбас или mqtt.

[ecoins]

1. Не только маркетинг , но и гарантийное обслуживание .если внутренние интерфейсы вытащить наружу и дать пользователю с ними работать как на аппаратном ,так и программном уровне, то потом крайних не найти
2.фл прог не знает о том куда разработчик вытащит и как кишки наружу. Это задача разработчика ПЛК , а не пользователя.Но то что так не делают остальные это наталкивает ответственного разработчика на определенные мысли.
3.это все делалось в рамках одного устройства, конструктивна для конкретного применения этими же разработчиками , а не для широкого применения другими пользователями.
4. Задач автоматизации производств на сотни порядков больше ,чем управления приводами, для них ПЛК и специальные драйверы
Каскаде все равно с какими ПЛК работать лишь бы был модбас или mqtt.

Вроде бы создано для конечных "...."? Это преувеличение.
И в ПР200 могут быть логические ошибки, и ошибки настройки Modbus, Ethernet.
В CodeSys чтобы что-то настроить, нужно потрудиться...
-----
А может согласиться со следующей точки зрения:
1.Традиционные производители ПЛК придерживаются стратегии "снятия сливок". И сильно отстают от развитии микрочипов и интерфейсов.
2.FLProg придерживается долгосрочной стратегии развития, поддерживает новые чипы и интерфейсы за счет многоплатформенности, тщательной оптимизации и тестирования программного кода, создания дополнительной возможностей и гибкости для пользователей(не самых древних чипов).
-----
Если проще: FLProg на порядок лучше многих традиционных систем программирования.
Или в это поверить сложно?
В таком случае что мешает - привычки, опыт прежних работ, безверие в возможности ярких личностей?
-----
По поводу гарантийного обслуживания ОВЕН - Вы высокого мнения о нем? Я не высокого.
А по другим производителям Вам что-то известно?
Из одного нашего с Вами источника известно, что сопровождение на высоком уровне у Simens - ежегодные профилактические осмотры специалистами Simens, горячее и холодное резервирования... Все за твердую валюту. И то не всегда...
Вы правы - задач и рынков много.
FLProg не претендует на рынки Simens, точно так же как и Simens не готов работать на рынках, которые активно осваивает FLProg.
-----
С уважением, ecoins.

[ecoins]

Что-то странное вы говорите. В Ардуино также можно использовать RTOS правда не все функции. И ни о какой виртуализации речи там нет. Но по сути rtos это тоже диспетчер задач, только он еще за временем выполнения следит. Контроль времени и усыпление задачи это самые крутые функции rtos на мой взгляд.
Проблема в другом диспетчер это универсальный инструмент для всех мк. А RTOS это ESP, 2040 и STM32. И я честно сказать с трудом себе представляю его использование в FLPROG, слишком тонкие настройки нужны для каждой задачи. Платы в флпрог для этого не очень подходят.

Вы затронули важную и не простую тему.
Для RTOS нужен аппаратный таймер.
В концепции Arduino IDE к сожалению не введено понятие "системный таймер операционной системы".
При этом таймеры широко используются например при работе с пинами (PWM).
При этом возникнут ограничения для некоторых функций работы с пинами и некоторыми библиотеками.
У AVR,DUE,ESP8266,ESP32,STM32(много зависит от семейства),RP2040,RP2350 - очень по разному...
Поэтому решили пока не развивать эту тему, чтобы иметь возможность подтянуть другие(ESP32 новые чипы, новые CORE, коммуникации и пр.).

Пока обошлись добавлением класса RT_HW_ShedTask, который позволяет добавлять, выполнять, удалять задачи, вызов которых выполняется по программному таймеру.
Для приложений c с временем реакции от 1-10ms(в зависимости от процесса и аккуратности написания проекта средствами FLProg) - оказался удобным инструментом. Он был использован при создании библиотеки/блока для сенсора температуры NST1001.
С уважением, ecoins.

[Rovki]

1. Не только маркетинг , но и гарантийное обслуживание .если внутренние интерфейсы вытащить наружу и дать пользователю с ними работать как на аппаратном ,так и программном уровне, то потом крайних не найти
2.фл прог не знает о том куда разработчик вытащит и как кишки наружу. Это задача разработчика ПЛК , а не пользователя.Но то что так не делают остальные это наталкивает ответственного разработчика на определенные мысли.
3.это все делалось в рамках одного устройства, конструктивна для конкретного применения этими же разработчиками , а не для широкого применения другими пользователями.
4. Задач автоматизации производств на сотни порядков больше ,чем управления приводами, для них ПЛК и специальные драйверы
Каскаде все равно с какими ПЛК работать лишь бы был модбас или mqtt.

Вроде бы создано для конечных "...."? Это преувеличение.
И в ПР200 могут быть логические ошибки, и ошибки настройки Modbus, Ethernet.
В CodeSys чтобы что-то настроить, нужно потрудиться...
-----
А может согласиться со следующей точки зрения:
1.Традиционные производители ПЛК придерживаются стратегии "снятия сливок". И сильно отстают от развитии микрочипов и интерфейсов.
2.FLProg придерживается долгосрочной стратегии развития, поддерживает новые чипы и интерфейсы за счет многоплатформенности, тщательной оптимизации и тестирования программного кода, создания дополнительной возможностей и гибкости для пользователей(не самых древних чипов).
-----
Если проще: FLProg на порядок лучше многих традиционных систем программирования.
Или в это поверить сложно?
В таком случае что мешает - привычки, опыт прежних работ, безверие в возможности ярких личностей?
-----
По поводу гарантийного обслуживания ОВЕН - Вы высокого мнения о нем? Я не высокого.
А по другим производителям Вам что-то известно?
Из одного нашего с Вами источника известно, что сопровождение на высоком уровне у Simens - ежегодные профилактические осмотры специалистами Simens, горячее и холодное резервирования... Все за твердую валюту. И то не всегда...
Вы правы - задач и рынков много.
FLProg не претендует на рынки Simens, точно так же как и Simens не готов работать на рынках, которые активно осваивает FLProg.
-----
С уважением, ecoins.

1. Не согласен. Бизнес есть бизнес- получение прибыли , иначе это хобби или для себя любимого. Да почти все используют СТМ в универсальных задачах для ПЛК. И про SPI и I2C в курсе они. НО у них опыт десятилетий производства и обслуживания (ремонта). Чипы каждый год обновляются , за ними не угнаться (тупиковый подход) , есть надежные, проверенные разработки , а новые чипы для новых разработок.
2.Пока действительность иная - Односторонняя гонка за новыми STM , а АВР и ЕСП перестают работать в новых версиях...то что ранее работало. Много платформенность и замена (подстановка) PIN на лету это не одно и тоже. Да, для отладки библиотек это хороший инструмент, а конечный пользователь этим заниматься не будет . Он заранее выбирает МК и делает для него проект. Само ардуино ИДЕ можно так же назвать многоплатформенной. Так что это не заслуга ФЛпрог. Для меня ФЛ лучше других , потому что FBD и потому ,что есть выбор МК. И лично для меня ваша огромная заслуга в переработки библиотек , а вот смена стратегии развития ФЛ пока под сомнением.
3. У овен сотни гарантийных сервисных центров. У сименса обслуживание их систем управления , а не ремонт оперативный железа(ПЛК).

[kilemch5]

Я вообще о чем хотел сказать, что с этими стм32 про есп32 8266 совсем забыли к сожалению. И например баг с торможением при подключении к несуществующей точке доступа так и остался без внимания. Пытался я самостоятельно исправить этот баг в библиотеке, но не хватило мозгов разобраться с библиотекой)

вроде как был же блок для решения этой проблемы?

[kilemch5]

Что-то странное вы говорите. В Ардуино также можно использовать RTOS правда не все функции. И ни о какой виртуализации речи там нет. Но по сути rtos это тоже диспетчер задач, только он еще за временем выполнения следит. Контроль времени и усыпление задачи это самые крутые функции rtos на мой взгляд.
Проблема в другом диспетчер это универсальный инструмент для всех мк. А RTOS это ESP, 2040 и STM32. И я честно сказать с трудом себе представляю его использование в FLPROG, слишком тонкие настройки нужны для каждой задачи. Платы в флпрог для этого не очень подходят.

Вы затронули важную и не простую тему.
Для RTOS нужен аппаратный таймер.
В концепции Arduino IDE к сожалению не введено понятие "системный таймер операционной системы".
При этом таймеры широко используются например при работе с пинами (PWM).
При этом возникнут ограничения для некоторых функций работы с пинами и некоторыми библиотеками.
У AVR,DUE,ESP8266,ESP32,STM32(много зависит от семейства),RP2040,RP2350 - очень по разному...
Поэтому решили пока не развивать эту тему, чтобы иметь возможность подтянуть другие(ESP32 новые чипы, новые CORE, коммуникации и пр.).

Пока обошлись добавлением класса RT_HW_ShedTask, который позволяет добавлять, выполнять, удалять задачи, вызов которых выполняется по программному таймеру.
Для приложений c с временем реакции от 1-10ms(в зависимости от процесса и аккуратности написания проекта средствами FLProg) - оказался удобным инструментом. Он был использован при создании библиотеки/блока для сенсора температуры NST1001.
С уважением, ecoins.

много лет ecoins избегает wifi)))

нет ни одного стенда с вайфай.
почему?
ну серьезно - отчего так?

[kilemch5]

1. Не только маркетинг , но и гарантийное обслуживание .если внутренние интерфейсы вытащить наружу и дать пользователю с ними работать как на аппаратном ,так и программном уровне, то потом крайних не найти
2.фл прог не знает о том куда разработчик вытащит и как кишки наружу. Это задача разработчика ПЛК , а не пользователя.Но то что так не делают остальные это наталкивает ответственного разработчика на определенные мысли.
3.это все делалось в рамках одного устройства, конструктивна для конкретного применения этими же разработчиками , а не для широкого применения другими пользователями.
4. Задач автоматизации производств на сотни порядков больше ,чем управления приводами, для них ПЛК и специальные драйверы
Каскаде все равно с какими ПЛК работать лишь бы был модбас или mqtt.

Вроде бы создано для конечных "...."? Это преувеличение.
И в ПР200 могут быть логические ошибки, и ошибки настройки Modbus, Ethernet.
В CodeSys чтобы что-то настроить, нужно потрудиться...
-----
А может согласиться со следующей точки зрения:
1.Традиционные производители ПЛК придерживаются стратегии "снятия сливок". И сильно отстают от развитии микрочипов и интерфейсов.
2.FLProg придерживается долгосрочной стратегии развития, поддерживает новые чипы и интерфейсы за счет многоплатформенности, тщательной оптимизации и тестирования программного кода, создания дополнительной возможностей и гибкости для пользователей(не самых древних чипов).
-----
Если проще: FLProg на порядок лучше многих традиционных систем программирования.
Или в это поверить сложно?
В таком случае что мешает - привычки, опыт прежних работ, безверие в возможности ярких личностей?
-----
По поводу гарантийного обслуживания ОВЕН - Вы высокого мнения о нем? Я не высокого.
А по другим производителям Вам что-то известно?
Из одного нашего с Вами источника известно, что сопровождение на высоком уровне у Simens - ежегодные профилактические осмотры специалистами Simens, горячее и холодное резервирования... Все за твердую валюту. И то не всегда...
Вы правы - задач и рынков много.
FLProg не претендует на рынки Simens, точно так же как и Simens не готов работать на рынках, которые активно осваивает FLProg.
-----
С уважением, ecoins.

1. Не согласен. Бизнес есть бизнес- получение прибыли , иначе это хобби или для себя любимого. Да почти все используют СТМ в универсальных задачах для ПЛК. И про SPI и I2C в курсе они. НО у них опыт десятилетий производства и обслуживания (ремонта). Чипы каждый год обновляются , за ними не угнаться (тупиковый подход) , есть надежные, проверенные разработки , а новые чипы для новых разработок.
2.Пока действительность иная - Односторонняя гонка за новыми STM , а АВР и ЕСП перестают работать в новых версиях...то что ранее работало. Много платформенность и замена (подстановка) PIN на лету это не одно и тоже. Да, для отладки библиотек это хороший инструмент, а конечный пользователь этим заниматься не будет . Он заранее выбирает МК и делает для него проект. Само ардуино ИДЕ можно так же назвать многоплатформенной. Так что это не заслуга ФЛпрог. Для меня ФЛ лучше других , потому что FBD и потому ,что есть выбор МК. И лично для меня ваша огромная заслуга в переработки библиотек , а вот смена стратегии развития ФЛ пока под сомнением.
3. У овен сотни гарантийных сервисных центров. У сименса обслуживание их систем управления , а не ремонт оперативный железа(ПЛК).

разве чипы обновляются каждый год?)

что можно обновить в чипах? количество пинов? их назначение?))))

[kilemch5]

1. Не только маркетинг , но и гарантийное обслуживание .если внутренние интерфейсы вытащить наружу и дать пользователю с ними работать как на аппаратном ,так и программном уровне, то потом крайних не найти
2.фл прог не знает о том куда разработчик вытащит и как кишки наружу. Это задача разработчика ПЛК , а не пользователя.Но то что так не делают остальные это наталкивает ответственного разработчика на определенные мысли.
3.это все делалось в рамках одного устройства, конструктивна для конкретного применения этими же разработчиками , а не для широкого применения другими пользователями.
4. Задач автоматизации производств на сотни порядков больше ,чем управления приводами, для них ПЛК и специальные драйверы
Каскаде все равно с какими ПЛК работать лишь бы был модбас или mqtt.

Вроде бы создано для конечных "...."? Это преувеличение.
И в ПР200 могут быть логические ошибки, и ошибки настройки Modbus, Ethernet.
В CodeSys чтобы что-то настроить, нужно потрудиться...
-----
А может согласиться со следующей точки зрения:
1.Традиционные производители ПЛК придерживаются стратегии "снятия сливок". И сильно отстают от развитии микрочипов и интерфейсов.
2.FLProg придерживается долгосрочной стратегии развития, поддерживает новые чипы и интерфейсы за счет многоплатформенности, тщательной оптимизации и тестирования программного кода, создания дополнительной возможностей и гибкости для пользователей(не самых древних чипов).
-----
Если проще: FLProg на порядок лучше многих традиционных систем программирования.
Или в это поверить сложно?
В таком случае что мешает - привычки, опыт прежних работ, безверие в возможности ярких личностей?
-----
По поводу гарантийного обслуживания ОВЕН - Вы высокого мнения о нем? Я не высокого.
А по другим производителям Вам что-то известно?
Из одного нашего с Вами источника известно, что сопровождение на высоком уровне у Simens - ежегодные профилактические осмотры специалистами Simens, горячее и холодное резервирования... Все за твердую валюту. И то не всегда...
Вы правы - задач и рынков много.
FLProg не претендует на рынки Simens, точно так же как и Simens не готов работать на рынках, которые активно осваивает FLProg.
-----
С уважением, ecoins.

1. Не согласен. Бизнес есть бизнес- получение прибыли , иначе это хобби или для себя любимого. Да почти все используют СТМ в универсальных задачах для ПЛК. И про SPI и I2C в курсе они. НО у них опыт десятилетий производства и обслуживания (ремонта). Чипы каждый год обновляются , за ними не угнаться (тупиковый подход) , есть надежные, проверенные разработки , а новые чипы для новых разработок.
2.Пока действительность иная - Односторонняя гонка за новыми STM , а АВР и ЕСП перестают работать в новых версиях...то что ранее работало. Много платформенность и замена (подстановка) PIN на лету это не одно и тоже. Да, для отладки библиотек это хороший инструмент, а конечный пользователь этим заниматься не будет . Он заранее выбирает МК и делает для него проект. Само ардуино ИДЕ можно так же назвать многоплатформенной. Так что это не заслуга ФЛпрог. Для меня ФЛ лучше других , потому что FBD и потому ,что есть выбор МК. И лично для меня ваша огромная заслуга в переработки библиотек , а вот смена стратегии развития ФЛ пока под сомнением.
3. У овен сотни гарантийных сервисных центров. У сименса обслуживание их систем управления , а не ремонт оперативный железа(ПЛК).

по пункту 3 все верно: если ремонт заключается в замене чипа с последующей прошивкой, то в странах третьего мира возможна утечка этой прошивки. Поэтому сименс и не ремонтирует ничего. Ведь самое ценное - это прошивка, а не железо)))

[Phazz]

Я вообще о чем хотел сказать, что с этими стм32 про есп32 8266 совсем забыли к сожалению. И например баг с торможением при подключении к несуществующей точке доступа так и остался без внимания. Пытался я самостоятельно исправить этот баг в библиотеке, но не хватило мозгов разобраться с библиотекой)

вроде как был же блок для решения этой проблемы?

В 9 версии он не работает