На сегодняшний день, в программе FLProg получился более менее законченный функционал как для контроллеров Arduino, так и для контроллеров ESP8266. Конечно, пока хватает и косяков, и недоделок, и хотелок. Но все они так сказать «не глобальные», и вполне могут быть исправлены и реализованы, как у нас на работе говорят «в порядке текущей эксплуатации».
Я понял, что пришло время, определится, а что глобального делать дальше? Почитав форум и сопоставив пожелания пользователей со своими возможностями, знаниями, да и честно говоря, желаниями, я выделил следующие возможные направления.

1. Оптимизация отрисовки схемы в проекте для контроллера. Честно скажу, логика отрисовки не сильно изменилась с первых версий программы. Конечно, регулярно я её “подлатываю”, ставлю новые «костыли», но всё это половинчатые меры. С той поры и у меня появились новые знания, много новых решений было отработанно на Скаде. И теперь по-хорошему надо просто переписать отрисовку с нуля. Скорее всего, это улучшит отзывчивость системы, позволит ввести фишки вроде масштабирования, позиционирования окна на неисправных блоках, поиск блоков, переменных на схеме, переход на переменную. Ориентировочное время реализации 2 – 3 месяца.

2. Расширение возможностей скады. После выхода скады, меня удивило практически полное отсутствие обратной связи по ней. Ни сообщений об ошибках, ни какого-то либо активного обсуждения на форуме. Я решил, что как говорится «не стрельнуло». Но когда я сообщил о приостановке работы над скадой, то получил много пожеланий о развитии скады. Я так понимаю необходимо просто «прокачать» скаду. Сроки реализации оценивать сложно, это скорее плановый процесс, который будет развивать скаду от версии к версии. Но вот насколько он важен?

3. Добавление поддержки контроллеров STM. Ну, тут объяснять не надо, и так понятно. Какое то количество плат на различных контроллерах STM у меня уже есть. Базовые принципы вроде разобрал, но работы всё равно очень много. Ориентировочно интеграция займёт 3 - 5 месяцев.

4. FLProg IOT сервер. Это совершенно новая моя идея, и сейчас я озвучиваю её в первый раз. Родилась она после изучения форума, ну и рассмотрения систем вроде MajorDoMo, Openhab, ioBroker, IoTManager. Сейчас все эти системы очень популярны, и востребованы. Поизучав «матчасть», честно говоря, мне ни одна не понравилась. Ну конечно это моё личное мнение, не хочу развивать холивар. Но с моей точки зрения, всё-таки они в большинстве своём во первых громоздкие, во вторых очень тяжелы в установке, требуют определённых знаний и умений в настройке, да и вообще нужен бубен шамана. Ну и конфигурирование этих систем всё-таки требует знания программирования (пускай и на уровне скриптов). Я считаю, что это не наш путь. Я решил (ещё на этапе создания Скады) немного расширить слоган проекта. Теперь это “Iot для непрограммистов”. При создании скады я пользовался принципом “компьютер – как контроллер”. Почему бы его не применить и для Iot сервера (ну или облака если хотите).
Теперь сама суть идеи. Это будет новый тип проекта (что ни будь вроде «Iot сервер»). Он так же будет иметь своё дерево, в котором можно будет создавать страницы веб интерфейса, будет ветка схемы, и ветка мастеров. Сервер будет являться Modbus TCP слейвом для устройств. Страницы вэб интерфейса будут создаваться по принципу, который сейчас используется для создания вэб интерфейса настройки ESP8266 только более расширенному. Схема будет использовать привычный нам язык FBD ( и LAD – возможно, ещё не решил).
Подключение к устройствам будет происходить по протоколу Modbus TCP. Сервер будет слейвом, устройство мастером. Это во первых позволит устройству кроме общения с сервером общаться с другими устройствами (слейвами) напрямую, во вторых исключит необходимость проброса портов и белого IP, поскольку инициатором соединения будет устройство. Переменные модбас можно будет использовать в логической схеме сервера, и в веб интерфейсе сервера. Кроме того в вэб интерфейсе сервера конечно можно будет использовать любые переменные схемы. Ну, в общем, по аналогии со скадой.
При компиляции проекта будет создаваться набор файлов на PHP и папок с ресурсами (скриптами, стилями, картинками) которые необходимо будет закинуть на сервер. В случае с PHP в качестве сервера может быть что угодно, арендованный хостинг, отдельный компьютер, малинка, апельсинка. Это может быть как сервер в интернете, так и локальный сервер в сети. Со временем, скорее всего, появится возможность создавать свои виджеты и блоки по аналогии с пользовательскими блоками на С, но только на PHP. Естественно с возможностью обмена ими и составления своих библиотек. Время реализации – ну не знаю…. Думаю за пару - тройку месяцев бетку можно выпустить, ну а потом только расширять.


Это глобальные направления развития. Все они очень интересны, все они продуманны, и вполне реализуемы. Но я трезво смотрю на свои возможности. Более менее плотно работать я могу только на вахте, дома у меня уже два инвалида (про мать я говорил, а тут ещё и у отца онкология, и вырезали половину желудка), поэтому времени на проект не остаётся. Исходя из этого, всё сразу я просто физически не потяну. Поэтому хочу провести голосовалку. Что более востребовано сейчас, и более интересно в ближайшем будущем. Ну и конечно вы можете в данной теме описывать своё виденье будущего программы, возможно, свои замечания по предложенным направлениям.

Ну и что точно будет сделано в ближайшее время.
1. Естественно IR управление для ESP8266
2. Возможность подключения к облаку Kascada. Пока разбираюсь с этим.
3. Реализация работы ESP с RemoteXY (надеюсь получится)
4. Ну и по мере необходимости устранение найденных ошибок

Так что голосуем, пишем свое мнение, для меня оно очень важно.

dsfbuy,
Маловероятно, так как этот вопрос поднимался чуть ли не с первых версий программы.
Уже тогда Сергей отвечал, что это потребует серьезных изменений основного кода.
Так что, наверняка, мы этого не увидим еще долго долго.

прошло почти 2 года с момента публикации
что нибудь слышно про стм32 ?
там вроде как 3-5 месяцев требовалось на эту затею да и сомной желающих было вагон при голосовании

Со слов Сергея, следующим после нового редактора будет скада.

Пишу с деревни Бодун.
Никаких проблем с пользованием стм32 не вижу.
Всё дело в ядре IDE.
Код, генерируемый прогой, запросто переваривает IDE.
Мелкие правки не в счёт.
Использование плюшек типа DMA в формате FLP не представляю, лично я, возможным, т.к. при пользовани ПБ неизбежно будут конфликты если будут другие инструкции.
Посему учим потиху язык.
Надеюсь, никого не задел, т.к. ИМХО.

Учить то учим. В чем смысл опроса, если автор не собирается добавлять?
Кодинг STM32 из под ArduinoIDE не бодрит, пропадают плюшки STM32.

Пока не надо stm32 в программе, 7 версию сперва нужно довести до стабильной. Пока его мало кто использует, поэтому долго будем доводить. Проблем там полно, вылеты не строго не с чего мучают !
Постоянные тестирования новых версий, особо не доставляют удовольствия.

Понесло вас в дальние дали, пользовался версией 3.0.3 последний раз. Потом пришел к выводу что AVRstudio занимает меньше времени для шансовых задач(единовременных), т.к пока будешь разбираться ПБ для разового использования уходит не меньше времени.

aidar_i писал(а): ↑

13.09.2020{, 10:38}

Пока его мало кто использует

помнится есп тоже нето что наслуху был так о нём мало кто знал
а теперь зауши не оттащишь

Отправлено спустя 3 минуты 30 секунд:

Sancho писал(а): ↑

13.09.2020{, 10:11}

Пишу с деревни Бодун.

это деревня такая или после пьяни имелось в виду ?

Sancho писал(а): ↑

13.09.2020{, 10:11}

Всё дело в ядре IDE.

я не знаю как там это всё заливается но если используется стороний софт то можно его добавить напару к флпрогу для загрузки

Sancho писал(а): ↑

13.09.2020{, 10:11}

Мелкие правки не в счёт.

правками не каждый может заниматься и понимать их суть

benic писал(а): ↑

13.09.2020{, 10:27}

Учить то учим. В чем смысл опроса, если автор не собирается добавлять?
Кодинг STM32 из под ArduinoIDE не бодрит, пропадают плюшки STM32.

aidar_i писал(а): ↑

13.09.2020{, 10:38}

Пока не надо stm32 в программе, 7 версию сперва нужно довести до стабильной. Пока его мало кто использует, поэтому долго будем доводить. Проблем там полно, вылеты не строго не с чего мучают !
Постоянные тестирования новых версий, особо не доставляют удовольствия.

Serg_Grn писал(а): ↑

13.09.2020{, 08:44}

Добрый день.
Есть плата (NodeMCU, Wemos, ESP32 - пробовал все варианты, итог везде один), которая является ModBus TCP Master, по wifi через роутер опрашивает ПЛК-slave. Сам ПЛК включён в роутер кабелем Ethernet. Опрашиваются данные Input registers, которые затем выводятся на дисплей.
Суть проблемы: данные в мастер прилетают без ошибок, но значения переменных хаотично меняются местами, т.е. отправленное значение в первом адресе вдруг начинает отображаться во втором, второй - в третьем и т.д., а последний - оказывается в первом... Затем через несколько секунд всё становится на свои места, потом проходит еще несколько секунд и опять чехарда со значениями переменных...
Я пробовал вместо ПЛК использовать OPC - итог один - отправляешь с компа значения переменных в одних адресах, они прилетают хаотично, то в правильных, то в неправильных... Соответственно, проблема точно не в ПЛК, проблема где-то в плате или коде, но где не представляю...
Прошу, у кого есть возможность и желание, взять любую из используемых мной плат (NodeMCU, Wemos, ESP32) и попробовать ею как мастером опросить слэйв устройство - либо такую же плату, либо OPC, или любой ПЛК.
Проект прилагаю, там кроме ModBus TCP Master ничего другого нет.
Спасибо!

Согласен с тем, что в начале лучше:
1. доработать версию 7;
2.доработать блоки (возможно на новых библиотеках) по устройствам которые "тормозят" (обычно из-за использовании delay());
3.внедрить минимальную культуру планирования работы плат (устройств, блоков и т.д.) по времени. Для этого было бы достаточно стандартного блока "мини-диспетчер задач".
4.сделать блоки обращения к пинам с номером пина на входе. Тоже самое и с устройствами работающими через пины (DHT21, HC-SR04, DS1820 и др.). Это сделало бы упростило отладку проектов на разных платформах(AVR,ESP,STM).
5.Отшлифовать реализацию MobBus. Есть вопросы и к Slave, и к Master, и к оболочке FLProg для доступа к каналу связи.
-----------------------------------
А STM32 использовать через пользовательские блоки и наращивать, наращивать, наращивать эти возможности. Попутно определиться с ядром под Arduino - сейчас их два и они не вполне совместимы
А потом уже можно и встраивать наработки в FLProg.
Сейчас блоки ecoins уже позволяют работать с STM32F103x (ядро от Кларка). Новые версии на стенде работают и на STM32F401.

ecoins писал(а): ↑

13.09.2020{, 12:02}

1. доработать версию 7;

Это уже длиться с 4, 5, 6 версий.

ecoins писал(а): ↑

13.09.2020{, 12:02}

2.доработать блоки (возможно на новых библиотеках) по устройствам которые "тормозят" (обычно из-за использовании delay());

Уже давно и многие не пользуются delay, тик на таймере решает это дело.

ecoins писал(а): ↑

13.09.2020{, 12:02}

3.внедрить минимальную культуру планирования работы плат (устройств, блоков и т.д.) по времени. Для этого было бы достаточно стандартного блока "мини-диспетчер задач".

Об этом надо задумываться перед проектированием.

ecoins писал(а): ↑

13.09.2020{, 12:02}

4.сделать блоки обращения к пинам с номером пина на входе. Тоже самое и с устройствами работающими через пины (DHT21, HC-SR04, DS1820 и др.). Это сделало бы упростило отладку проектов на разных платформах(AVR,ESP,STM).
5.Отшлифовать реализацию MobBus. Есть вопросы и к Slave, и к Master, и к оболочке FLProg для доступа к каналу связи.
-----------------------------------
А STM32 использовать через пользовательские блоки и наращивать, наращивать, наращивать эти возможности. Попутно определиться с ядром под Arduino - сейчас их два и они не вполне совместимы
А потом уже можно и встраивать наработки в FLProg.
Сейчас блоки ecoins уже позволяют работать с STM32F103x (ядро от Кларка). Новые версии на стенде работают и на STM32F401.

Смысл в чем связки: STM32F103x + (ядро от Кларка) + ArduinoIDE + FLprog ?
CUBE, SPL и HALL дураки придумали?
Элементарно не хватает типов переменных, куда наращивать?

benic писал(а): ↑

13.09.2020{, 14:13}

Уже давно и многие не пользуются delay, тик на таймере решает это дело.

Многие стандартные блоки FLProg включают библиотеки Arduino которые содержат delaу(), и о которых пользователи блоков не подозревают.
Обнаружить это просто с помощью логического анализатора, но не все его имеют.
Преодолеть - обычно только другой библиотекой, которые обычно приходиться разрабатывать.
Еще задержки возникают при простом использовании Serialx на передачу.

benic писал(а): ↑

13.09.2020{, 14:13}

Об этом надо задумываться перед проектированием.

FLProg успешен во многом потому, что им успешно пользуются многие инженера без опыта и представлении работы контроллеров и создаваемых кодов.
Во многом поэтому мы делаем проекты, которые работают на разных платформах - для себя бы сосредоточились пожалуй только для STM32 и ESP32.
Планировать выполнения плат во времени и с некоторым приоритетом можно стандартными логическими блоками, но всегда будет получаться очень громоздко, плохо читаемо и т.п.
Для планирования задач полезны блоки планирования во времени. Стандартных нет, свои мы предложили. У Вас есть свои предложения?

benic писал(а): ↑

13.09.2020{, 14:13}

Смысл в чем связки: STM32F103x + (ядро от Кларка) + ArduinoIDE + FLprog ?
CUBE, SPL и HALL дураки придумали?
Элементарно не хватает типов переменных, куда наращивать?

Если есть предположения относительно дураков, то должны быть и умные. Дураки абсолютные не бывают, только в сравнении с другими, умными.
Хотелось бы воспользоваться результатами тех у кого получилось (умными) - проект с базовыми операциями (ADC, PWM, HR-SR04, DHT22, DS1820,BME280, MCP23017,PCA9685,Serial,SPI, Modbus Slave на 50 тегов int, Modbus Master на 20 тэгов), соединить все с внешним пультом а планшете (например с KaScada). И это все вместе или по раздельности STM32F401 на ядре STM32duino.
То есть посмотреть на реальные проекты на FLProg с указанием дополнительных библиотек, если они используются.

benic писал(а): ↑

13.09.2020{, 14:13}

Элементарно не хватает типов переменных, куда наращивать?

-----
Типов данных хотелось бы наверное побольше, но при определенной гибкости хватает того, что есть. С какими-то конкретно проблеми столкнулись? Может что-то сможем подсказать.
P.S. По моему мнению дураков вообще нет. Но есть другие, которые в силу определенной самооценки считают других людей таковыми.

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

Вот если бы отвязать FLProg от Ардуино, ИМХО, могло бы получиться новое направление развития проекта. Если научить редактор выгружать список блоков и связей, и предоставить интерфейс передачи значений переменных из внешнего приложения в FLProg, то можно было бы делегировать реализацию среды выполнения на МК сторонним разработчикам. Открывать исходники среды программирования при таком подходе вообще не нужно. Тогда FLProg стала бы фронт-эндом для программирования разных контроллеров на графических языках. Заманчивым (для меня, например) выглядит предоставление каркаса приложения, получающего и передающего данные в FLProg, но отдающего на откуп разработчика процесс обмена этими данными с МК. Такой вариант использования/развития FLProg рассматривался? Возможен?

Возможно, я что-то упустил, читая про идеологию проекта, поэтому не ругайте меня, если я что-то не то сказал.

Добрый день всем..
А может все же хотя бы базовые функции по блокам до конца решить?
Например аппаратный ШИМ, это просто смешно что имеем в программе.. назначение пина и регулировку скважности..

Блоки от опытных пользователей либо не работают, либо перегружены зачастую непонятными (начинающим) функциями и настройками..
Столкнулся перерыл все и вся... либо учи язык либо уходи на другую платформу..
Как вижу нужен простой блок или несколько блоков по количеству таймеров именно простые !!!

Например
Таймер 8бит.
Вход Период (Время)
Вход Заполнение (Время)
Настройка на доступный для текущего таймера пин или пины..

Аналогично
Таймер 10бит..

итд..

Далее из хотелок..
Первый проект (имея опыт построения схожего программирования) лежит готовый на столе, сделал на уровне именно понимания как работает ..но уперся в ШИМ

Это я к чему..
Не плохо было бы реализовать Эмулятор хотя бы примитивный, таже блочная схема но при запуске видно что на входе блока а что на выходе
можно просто цифрами .. Вошла 1ца в блок, условие блока не выполнено, на выходе 0ик
Ну и по аналогии с другими данными..
Ком порты, Протеус итд это несомненно здорово..
Только на изучение попутных программ теряется уйма времени..(молчу о размерах этих программ)
А новичкам да и просто для реализации простых устройств, Протеус избыточен..

Спасибо за понимание..(возможно чего то еще не знаю)

Здавствуйте.

VNL64T писал(а): ↑

24.01.2024{, 04:36}

Например аппаратный ШИМ, это просто смешно что имеем в программе.. назначение пина и регулировку скважности..

Не думаю, что это смешно. Не очень понятно - наверное.
Реализация ШИМ в контроллерах только внешне кажется аппаратной - в действительности это программная реализация ядра Arduino IDE для конкретного контроллера.
И могут начинаться проблемы при прямолинейном использовании этой возможности (ШИМ-PWM).
В AVR,ESP,STM32 - аппаратная и соответственно программная реализация совсем разная. И обычно основана на использовании таймеров, которые в разных контроллерах разные и по разрядности, и по количеству.
И потому по мере роста сложности проекта без оглядки на это обстоятельство начинают возникать сложности...

VNL64T писал(а): ↑

24.01.2024{, 04:36}

Столкнулся перерыл все и вся... либо учи язык либо уходи на другую платформу..

Если Вы имеете контроллер, то Вы не указали какой используете.
Сразу выскажу суждение, что на AVR(особенно на Nano,UNO) вероятность проблем наиболее высокая.
Очень интересное решение Raspberry Pi Pico (RP2040) - там 2 ядра. На втором ядре можно много чего реализовать.
Буквально недавно для одной задачи тестировал возможности генерации на пин сигнала - период 650us, т.е. 1.5мГц.
ШИМ посложнее, но предположу, что 500-1000кГц достижимо...

VNL64T писал(а): ↑

24.01.2024{, 04:36}

Как вижу нужен простой блок или несколько блоков по количеству таймеров именно простые !!!

Задача хорошая и полагаю со временем универсальное решение для разных контроллеров в FLProg появится.

VNL64T писал(а): ↑

24.01.2024{, 04:36}

Спасибо за понимание..(возможно чего то еще не знаю)

Успехов. Ваши вопросы содействуют развитию FLProg.

Прежде чем развивать программу, надо все косяки поубирать из неё. До сих пор ведь и в блоках и в алгоритме трансляции в текст присутствуют разные странности. Попробую словестно пример описать. Есть логический блок, например AND, у него на входах пара(несколько) переменных, одна из них условно Flag. Результат с выхода этого блока подается на несколько других блоков и в том числе на установку переменной Flag=0. Несмотря на то, что все блоки соединены связями, часть, или все, не выполняются никогда. Начинаю разбираться, выясняется, что программа генерирует код, который выполняет функцию AND для каждого последующего блока индивидуально. А поскольку задать порядок выполнения блоков в программе нельзя, только посмотреть, то и получается что сначала выполняется AND с выходом на Flag=0, а для остальных последующих блоков эта же функция уже дает на выходе ЛОЖЬ (т.к. используется НОВОЕ значение Flag) и они не выполняются.
Уже несколько раз я сталкивался с подобным. Решением вопроса является введение промежуточной логической переменной и использование её в дальнейшем. Но тогда теряется смысл в связях и ухудшается наглядность программы. Очевидно, что значение функции AND должно в данном случае вычисляться только один, первый, раз. А дальше по связи использоваться её результат. Но так бывает не всегда. Причем неизвестно когда будет сделано так, а когда иначе и каков будет порядок выполнения блоков - при изменениях программы он может тоже меняться. И в итоге один раз странслировал программу = все работает, а в другой раз = нет, хотя правил вообще в другом месте кода. А решение, как уже сказано, уменьшает наглядность и уничтожает основное преимущество FLProg. Вот с подобной вещью бы разобраться = было бы правильно. И порядок выполнения тоже неплохо бы задавать, пусть не явно, но хоть "слева направо и сверху вниз". Как это принято в других подобных программах. Конечно, прообраз FBD - логические схемы - работают параллельно и там порядок выполнения в общем случайный и неизвестно какой из двух параллельных логических модулей выполнится быстрее. Но FBD и не прямой аналог, а подобие, и отличие именно в том, что отработка программы строго последовательна.

Добрый вечер..
Кстати да, дополню.. покороче...
Почему блоки логики не сделать так чтобы все что больше 0я принималось за единицу? Это сильно бы упростило а главное ускорило работу с программой..

VNL64T писал(а): ↑

25.01.2024{, 23:54}

Почему блоки логики не сделать так чтобы все что больше 0я принималось за единицу? Это сильно бы упростило а главное ускорило работу с программой..

Насчет ускорило работы программы - да, немного на 8-битных контроллерах. На STM32 наверное нет.
Входы битовые, потому они не воспринимают другие типы данных.
----------
Вопросы которые Вы задаете хорошие и полезные. Особенно в части быстродействия блоков.
Есть другие способы достичь высокой производительности - по мере углубления в FLProg и материалы форума Вы с ними сможете познакомиться.
Блоками логики сейчас разработчик трогать не будет - он сейчас занимается более основательными задачами по FLProg - готовит новую версию с основательными изменениями.
Потом возможно, если это действительно будет важно.
С уважением, ecoins.

Ну одно замечание можно учесть? Доброй ночи всем..
Уберите окно выбора входов выходов, например в вкладку с блоками, хотя логичнее в лево в дерево проекта, или выпадающим меню где-то над рабочим столом (да я понимаю что сворачивается итп.)
Обращаемся к нему не часто (а забываем свернуть регулярно да еще все что создали там раскрыто) и вот висит почти постоянно, да еще и реализовано на всю ширину рабочего пространства, хотя сами параметры выбора в лучшем случае на четверть ширины и список созданного движется в низ следовательно либо это окно растягивать либо ползунком проматывать ну крайне не удобно и сильно сжирает рабочее пространство..

Есть другие способы достичь высокой производительности - по мере углубления в FLProg и материалы форума Вы с ними сможете познакомиться.

Согласен это называется более простым словом "Привыкните"..
Но свежий взгляд тем и полезен что не замылен...

Спасибо, приятная тут у вас компания...

П.С. Полоса с названием файла с обводкой текущего, явно избыточна...плюс под ним полоса с названием модуля...

ecoins писал(а): ↑

26.01.2024{, 01:11}

хотя логичнее в лево

Так она там тоже есть. Хотя я пользуюсь контекстным меню вызываемым правой кнопкой мыши

VNL64T писал(а): ↑

26.01.2024{, 03:29}

П.С. Полоса с названием файла с обводкой текущего, явно избыточна...плюс под ним полоса с названием модуля...

Как вы предлагаете переключаться между несколькими открытыми файлами?
А вот полоса с названием модуля явно лишняя. Используемый модуль можно посмотреть внизу.