Не могу сказать на какую аудиторию больше ориентируюсь в данных постах, но скорее всего это будет интересно - разработчикам электронщикам, и предпринимателям в сфере АСУ ТП которые разрабатывают ПЛК и разное программно-аппаратное (они часто пишут). Как показывает практика - меньше всего это понятно АСУ-ТПшникам, что не удивительно так как посты больше о разработке ПЛК как прибора и предпринимательстве, а не о применении ПЛК.

Что у меня за проект такой, пост тут: Своими разработками соревнуюсь с брендами в АСУ ТП. Превзойти Codesys

Если коротко, то это аналог Codesys, в несколько скромном виде.

Среда разработки (LD FBD + текстовые типа ST), свой компилятор, и среда выполнения на CPU.

Потенциальному производителю ПЛК осталось разработать железо и скомпилировать среду выполнения под свой CPU/MCU. Один производитель уже разрабатывает железо под своим лейблом, и через полгода мы увидим что вышло.

Хотя со мной связывались так же из  - станкостроительного предприятия, на предмет можно ли все это внедрять в станки. Можно.

Тестовое железо:

Методика тестирования:

Запускаем  программу на LD из 184 блоков.

Замеряем осциллографом реакцию  вывода , и считаем время отработки одной инструкции/блока.

Почему LD а не ST:

Очень часто спрашивают. LD - хорошо документирован. Производители ПЛК часто прямо в документации пишут время выполнения базовых LD  инструкций, и я могу прямо сравнить “свой” ПЛК с брендом по скорости программ.

Результат тестирования в сравнении с брендами:

Хотя пост не о китайском МК, но интересен для сравнения результат моей машины на CH32V307 RISC V.

Еще несколько лет назад, когда я начал переносить на микроконтроллеры свой рантайм, я замерял тестовую скорость базовых LD  операций, они так и были - 1 микросекунда. Потому у меня было некоторое удивление от STM32F407 (и вообще от всей линейки STM ARM) который был медленнее в два с половиной раза.

В данный момент, могу это объяснить так: у RISC V  в два раза больше регистров ядра (16 в ARM против 32 RISC V), это значит что переходы между функциями  RISC V может делать быстрее, так как меньше приходится использовать память, а промежуточные результаты хранить непосредственно в регистрах ядра CPU.

Хотя тут еще предстоит более тщательно разобраться, напишу отдельный пост о тестировании RISC V так как по одному такому МК я сотрудничаю с предприятием. Но скорее всего в данной задаче (по крайней мере моя виртуальная машина) и вправду на RISC V в два раза быстрее чем на ARM.

В прошлом посте где я тестировал свой комплекс на STM32F103 Своими разработками, соревнуюсь с Mitsubishi в АСУ ТП. STM32F103 как ПЛК lo  , упоминал китайские дешевые ПЛК под среду Mitsubishi .Мне скинули китайскую документацию как сделать ПЛК под среду и компилятор от Mitsubishi. В общих чертах почитал, Оказывается, у меня такая же архитектура что и у Mitsubishi. Но я не делал оптимизацию под ARM и мой ПЛК оказался существенно медленнее. Хотя если брать не китайские и разные любительские ПЛК на Mitsubishi, а оригинальные, то тут Mitsubishi равных нет, они делают свои CPU и  аппаратно реализовывают декодирование инструкций и выполнения программ. Мне такой скорости добиться можно наверное если только перенесу виртуальную машину на FPGA, где базовая операция длится - наносекунды.

Что можно выжать из STM32F407  в качестве CPU  ПЛК:

ОЗУ  больше сотни килобайт, и флэш под мегабайт, соответственно можно писать полноценные большие программы на LD  и ST.

Если брать LD то за цикл 1 миллисекунды такой ПЛК отработает чуть больше 400 базовых LD инструкций. Из опыта знаю, ветка горного конвейера, обходилась примерно в 300 LD.

Пид регулятор такого ПЛК успеет отработать за 150 микросекунд вместе с фильтрацией .

Или за 2 миллисекунды еще + 200 LD математических.

(*/+-) на STM32f407 с моим рантаймом - 4.4 микросекунды, на математику. У Siemens S7 1200(CPU 1214C) этот показатель 2.3 микросекудны, а PID регулятор 150-300 микросекунд ( с временем на сетевой обмен). Таким образом, ПЛК на STM32F407 будет уступать S7 1200 не сильно много (я тестировал без учета сети).

Если брать особенность чисто моей архитектуры, то все МК которые имеют ОЗУ больше 16 Кб могут запускать в себе - множественные исполнители:

Код, с операционкой(моей виртуальной имею ввиду операционкой, которую писал), и все что потенциально может вызвать фатальную ошибку и вылет ПЛК - может запустить отдельно, а критический код (безопасность какая) - тоже отдельно. То от чего обычный ПЛК - вылетит, у нас просто заглохнет один исполнитель, в то время как другие продолжат работать.

Как это достигается. Каждый исполнитель, имеет свое  виртуальное ОЗУ, что с точки зрения СИ есть - простым массивом байт:

Виртуальная машина по очереди выполняет instruction  каждой ОЗУ(в каждом массиве), и если где то произошла критическая ошибка (повреждение данных, или еще что) просто один исполнитель будет выключен. Как видите , хоть полностью удали данные массива который играет роль ОЗУ это не затронет другие исполнители, и тем более не затронет физический ПЛК.

Тут я ничего принципиально - нового не придумал. Точно так как в операционной системе Windows/Linux/Android - если вылетело какое то приложение, ни ПК ни смартфон от этого не перегружаются и не вылетают.

Но моя заслуга в том что я написал полноценный компилятор, поддерживающий вытесняющую многозадачность, сложную адресацию, и другие сложные , и все это может работать уже на МК с ОЗУ в 16 Кб. Система работает в режиме реального времени, с детерминированным исполнением инструкций, по системному таймеру. В отличии от операционных систем типа Linux/Windows где ОС может приостановить вашу программу, для каких то своих дел.

Следующие тесты буду проводить уже на RISC V микроконтроллерах, и больше буду уделять внимание как это выглядит и работает - физически.

Кому интересно - присоединяйтесь, или пишите на почту

zoshytlogic@gmail.com

Я подумал: «А что, если дать риэлторам простой и дешевый способ превращать фотографии их объектов в динамичные видео-тизеры с помощью AI?», ведь у нас всё для этого есть:

1. Мой партнёр легко соберёт стек на развёрнутом у нас N8N и мы будем «клепать» такие видео на конвейере.

2. Сейчас профессиональная видеосъёмка и монтаж для риэлтора стоит около 20 000 рублей, наш стек обеспечит себестоимость ролика около 500 рублей. 20 000 — за видео рушат экономику риэлтеров за объект, потому такие видео заказывают только на очень значимые объекты и очень редко. А ролики по 2000 рублей вполне себе доступный инструмент.

3. Качество низкое — но риэлтерам много и не надо. Их задача не на ТВ крутить ролики, а выложить их в объявление с объектом.

4. Дополнительная ценность: На объект не надо выезжать! Мы создадим видео из уже имеющихся фото.

Первая гипотеза звучала так: Риэлторам нужен быстрый и дешевый инструмент для создания видео, чтобы выделяться на фоне конкурентов.

Казалось, это очевидная потребность. У нас есть опыт создания никому не нужных стартапов и «подзатыльников» от ФРИИ, так что вместо того, чтобы сразу бросаться в разработку, я решил применить методологию Customer Development (CustDev). Ее суть проста: не писать ни строчки кода, пока ты не поговоришь с будущими пользователями и не поймешь их реальные проблемы.

Этап 1: 10+ звонков и первый холодный душ

Я составил скрипт и провел более 10 интервью с нашими клиентами-риэлторами. Изначально я тестировал идею AI-генерации «видео-проходок» по квартире.
Мой скрипт вопросов был прост (10+ вопросов): «Как вы показываете объекты клиентам?», «Что для вас важно в презентации?», и затем: «Как вам идея, чтобы AI из фото делал видео-тур по квартире?». И именно на последнем вопросе я получил тот самый критический фидбек. Реальность быстро внесла свои коррективы. Ключевой инсайт от опытных агентов был прост и убийственен: «Из набора фото нельзя создать реалистичную проходку, вы не можете "придумать" коридор, если его фото не было в подборке. Это будет вводить покупателя в заблуждение».

Вывод №1: Первая же итерация CustDev показала, что продукт нежизнеспособен по техническим и этическим причинам. Десяток звонков сэкономили мне ресурсы для разработки и уберегли от создания сервиса, который бы обманывал ожидания.

Этап 2: Поворот в сторону соцсетей и 15+ новых интервью

Окей, «проходки» отменяются. Но идея с короткими видео еще жива! Я сформулировал новую гипотезу: «У риэлторов, которые активно ведут соцсети, есть "контентный голод", и наш сервис поможет им легко и быстро заполнять пустоты в контент-плане».

Я провел еще около 15 более глубоких интервью, целенаправленно ища риэлторов-блогеров. И снова рынок преподнес сюрпризы:

• Статистика: Более 80% опрошенных риэлторов не ведут соцсети. Из тех, кто ведет, лишь один назвал их основным каналом привлечения «холодных» клиентов. Большинство использует соцсети для «напоминания о себе» уже существующей базе.

• Инсайт №1 (Юридический риск): Каждый второй опытный агент упоминал Закон о маркировке рекламы как огромную головную боль, из-за которой многие вообще перестали постить объекты.

• Инсайт №2 (Психологический риск): Один из самых успешных риэлторов поделился ключевой мыслью: «Слишком красивые, "вылизанные" фото и видео могут отпугивать клиентов, так как выглядят как фейк. Простое "живое" видео с телефона вызывает больше доверия».

Вывод №2: Рынок оказался гораздо меньше и сложнее, чем я думал. Прямые интервью вскрыли неочевидные, но потенциально смертельные риски для продукта, о которых я даже не подозревал.

Этап 3: Финальный тест. Ответ от 100 клиентов

После проделанной работы очевидно, что сервис из этого не создать. Но в нашем случае есть важное отличие от типового стартапа - мы хотим усилить существующий сервис, а не создать новый.

Это значит что даже небольшой профит от услуги даст нам конкурентное преимущество, которое большинство частников просто не будут делать. Потому у меня осталась последняя, самая скромная гипотеза: «Возможно, существует "молчаливое большинство", которое не попало в мою выборку. Давайте дадим возможность ВСЕМ нашим клиентам проголосовать рублем». Я применил классический для IT-индустрии "Тест 'фальшивой двери'" (Fake Door Test). В личном кабинете наших клиентов, на странице с готовыми фотографиями, мы добавили кнопку «видео из фото». Кнопка вела на страницу с примерами и финальной кнопкой «Заказать». Нам оставалось лишь считать клики.

За неделю мы получили самый честный ответ от рынка.

Результаты в цифрах:

• Более 100 клиентов увидели предложение.

• 3 человека нажали на кнопку, чтобы узнать подробности.

• 0 человек нажали на финальную кнопку «Заказать».

Конверсия из показа в интерес составила 3%.
Конверсия в реальный заказ — 0%.

Итоги: Почему «0» — это отличный результат

Цифры не врут. Спрос на эту услугу в том виде, в котором я был готов ее предоставить, практически нулевой. Поэтому мы с командой приняли единственно верное решение — не тратить время и ресурсы на разработку и закрыть проект.

Для меня это не история провала, а история успеха процесса. Успех в бизнесе — это не только про запуск продуктов, которые «взлетели». Это еще и про умение вовремя и с минимальными затратами похоронить те идеи, которые рынку не нужны.

Весь этот путь — от идеи до финального теста — занял около месяца. Благодаря методологии Customer Development и готовности слушать рынок, а не свои фантазии, я сэкономил команде время и деньги. И это, на мой взгляд, и есть настоящий успех.