Универсальный контроллер CLRC-02

Контроллер CLRC-02 (рабочее название) - это то, к чему я пришел в своих экспериментах по созданию системы автоматизации. До этого было несколько вариантов, но они были "похоронены", т.к. обладали существенным недостатком - отсутствием гибкости изменения алгоритма работы.

Все решения, которые я встречал на просторах интернета, имели вшитые алгоритмы отработки определенных процессов. В этом скрыто несколько существенных минусов. Во-первых, пользователь не всегда понимает что именно делает контроллер. Во-вторых, при необходимости добавления изменений в работу алгоритма нужно "допиливать" прошивку, т.е. заниматься программированием. Конечно, можно внести множество коэффициентов, влияющих на ход процесса, но это только усложняет понимание алгоритма и совсем не ведет к упрощению эксплуатации контроллера. Я неоднократно слышал негативные отзывы пользователей, связанные с данной проблемой. В-третьих, любые программные модификации подразумевают некие технические шаги, как разборка контроллера, его прошивка и обратная сборка. Всё это , даже при наличии необходимого опыта, отнимает время. К тому же, внесение правок в алгоритм приводит к появлению новых багов.

Наэкспериментировавшись с подобного рода решениями я пришел к выводу, что гораздо проще перейти на более высокий уровень абстракции. Что делает любой контроллер? Он принимает данные с термодатчиков, управляет мощностью нагревателя и имеющимися на борту реле. Не так много сущностей. Значит нужно написать небольшой скриптовый язык, который будет оперировать в понятной форме именно этими сущностями. Этот подход реализован в CLRC-02. Контроллер не содержим вообще никакой вшитой логики процессов. Вместо этого он отрабатывает скрипты. Если необходимо внести изменения в процесс, то это делается изменением скрипта.

Думаю, что для людей, занимающихся экспериментами в области дистилляции и ректификации такой контроллер будет хорошим подспорьем. Хотя, он универсален и подойдет для решения большинства задач.

Небольшое видео с экрана контроллера. В комментариях к видео записан скрипт.

при необходимости добавления изменений в работу алгоритма нужно "допиливать" прошивку, т.е. заниматься программированием.colibrilab, 13 Апр. 17, 11:42

Значит нужно написать небольшой скриптовый язык, который будет оперировать в понятной форме именно этими сущностями. Этот подход реализован в CLRC-02. Контроллер не содержит вообще никакой вшитой логики процессов. Вместо этого он отрабатывает скрипты.colibrilab, 13 Апр. 17, 11:42

Пришли к тому от чего хотели уйти. "Допиливание" прошивки ничем принципиально не отличается от "допиливания" скрипта... Тоже программирование...

Пришли к тому от чего хотели уйти. "Допиливание" прошивки ничем принципиально не отличается от "допиливания" скрипта... Тоже программирование...Mnz, 13 Апр. 17, 17:11

Это не так. Во-первых, количество кода в десятки раз меньше. Во-вторых, количество сущностей тоже в десятки раз меньше. Например, на на ESP8266 многие давно перешли на скриптовый язык LUA и чудесно там поживают. Ну, наверное, не надо объяснять разницу между нажатием на WEB-странице кнопки выбора файла и заливкой скетча через USB ? Поверьте, не у всех контроллеры состоят из кучи кишок. У меня в закрытой коробке. Мне разбирать его?

Давайте проведем эксперимент. Я сейчас напишу простейший скрипт дистилляции:

 t1s = 1
 p = 100
 t1 > 98

Всё. А вы попробуйте написать это же на C++. Заметьте, что еще вам нужно сделать вывод на экран значений термодатчика, мощности, значения таймера процесса, отработать нажатия клавиш, отработать команды через WiFi. И чтобы ручная коррекция мощности была. Как напишете, сравните размер своей программы с размером моего скрипта. И еще посчитайте сколько раз вы вносили исправления, компилировали и проверяли код. Вообще, засеките время. Это будет ответом на ваш вопрос.

Я сейчас напишу простейший скрипт дистилляции:colibrilab, 13 Апр. 17, 17:42

Где в скрипте обработка аварийных ситуаций? Скажем датчик вышел из строя из-за чего все может перегреться и взорваться...
У всех установки разные. Как будет выглядеть скрипт ректификации с ШИМ управлением клапанами отбора голов, спирта и хвостов? При этом нужно контролировать температуру нескольких датчиков в т. ч. аварийных чтобы ничего не перегрелось, в т. ч. холодильник чтобы в место жидкости не повалил пар.

Где в скрипте обработка аварийных ситуаций?Mnz, 13 Апр. 17, 19:28

Они уже встроены в логику. Кстати, вам на C++ нужно позаботиться еще и про это . Здесь же, в случае некорректных данных от сенсора, контроллер сам переходит в аварийный режим - мощность на 0 и звуковой сигнал. В скрипте ничего для этого писать не нужно.

У всех установки разные. Как будет выглядеть скрипт ректификации с ШИМ управлением клапанами отбора голов, спирта и хвостов?Mnz, 13 Апр. 17, 19:28

Вы совершенно правы. Разные. Поэтому люди, использующие контроллеры с вшитой логикой, отлавливают много интересных эффектов. Я сомневаюсь, что все вообще понимают ЧТО делает в данный момент их МК. А здесь всё более чем наглядно и упрощено до предела.

ШИМ-управления в базовой версии нет. Оно есть в полной версии. Как и PID-управление. Кстати, там есть и полное управление через WEB, и логи, и красивые графики и много чего другого, что категорически (поверьте моему опыту) облегчает жизнь. Но это базовая версия - это основа, отличный инструмент, который может сэкономить уйму времени и может прекрасно справляться с большинством задач.

При этом нужно контролировать температуру нескольких датчиков в т. ч. аварийных чтобы ничего не перегрелосьMnz, 13 Апр. 17, 19:28

Мне более чем хватает трех датчиков. Фактически, если следить только за дельтой, то хватит и двух. Это реализовано во многих компараторах. Кстати, я категорический противник устройства аварийной реакции на том же контроллере. Будет смешно, если "нагнётся" по каким-то причинам МК (бывает с электроникой...), а программа отработки аварии работает на том же МК. Это, дорогой мой коллега, чистейшее колхозанство. Такие системы нельзя совмещать с основным управлением. Они должны быть просты, как лом, и совершенно независимы от контроллера. Например, у меня на баке стоит термореле от утюга. Там хоть весь МК в пепел сгорит, эта штука стаботает. Такими должны быть аварийные системы.

Они уже встроены в логику.colibrilab, 13 Апр. 17, 20:16

Можно об этом подробнее. Какие ситуации считаются аварийными?

Кстати, вам на C++colibrilab, 13 Апр. 17, 20:16

С++ это не единственный язык. Программы можно успешно разрабатывать и на других.

Я сомневаюсь, что все вообще понимают ЧТО делает в данный момент их МК.colibrilab, 13 Апр. 17, 20:16

Зависит от уровня знаний. Если есть какие-то непонятки в работе МК, то берется отладчик (необходим МК с отладочным интерфейсом JTAG, SWD и др.) и можно следить за работой МК в разные моменты времени, включая пошаговое (построчное) выполнение кода при необходимости наблюдая (и изменяя) за содержимым переменных, регистров и т. д.

ШИМ-управления в базовой версии нет. Оно есть в полной версии.colibrilab, 13 Апр. 17, 20:16

Она будет доступна позже или она платная?

Кстати, я категорический противник устройства аварийной реакции на том же контроллере.colibrilab, 13 Апр. 17, 20:16

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

Можно об этом подробнее. Какие ситуации считаются аварийными?Mnz, 13 Апр. 17, 22:23

Потеря сенсора, t<10, t>100:

С++ это не единственный язык. Программы можно успешно разрабатывать и на других.Mnz, 13 Апр. 17, 22:23

Коллега, давайте вы спуститесь на землю. Посмотрите на чем во всех ветках скетчи под Arduino. Конечно, на C++. Не выдумывайте.

Зависит от уровня знаний. Если есть какие-то непонятки в работе МК, то берется отладчик (необходим МК с отладочным интерфейсом JTAG, SWD и др...Mnz, 13 Апр. 17, 22:23

Ооооо... Какие дали далёкие Простите, во-первых, много "если", во-вторых, эти названия скучны для большинства пользователей. Вот в этом и заключается отличие скриптов от нативного кода.

Она будет доступна позже или она платная?Mnz, 13 Апр. 17, 22:23

Пока ничего не скажу - сам не знаю

Интересное решение. Похоже Барнаул превращается в центр автоматизации нашего дела. По крайней мере по соотношению размера деревни к количеству разработок. Больше всего интересовало, как решено зависание ESP при детектировании нуля. Оказывается гениально просто - эта возможность не используется! А вообще решение хорошее.

я бы не был столь уверен в китайском процике чтобы экономить на собаке на 555 таймере или таком как у msg31

я бы не был столь уверен в китайском процике чтобы экономить на собаке на 555 таймере или таком как у msg31sevpro, 14 Апр. 17, 09:33

За два года я не сталкивался с какими-либо неполадками в работе ESP8266. Также, не встречал в сообществах по данному МК тем о выходе из строя. А на чем основано ваше "я бы не был столь уверен в китайском процике"?

За два года я не сталкивался с какими-либо неполадками в работе ESP8266.colibrilab, 14 Апр. 17, 10:04

Вообще изделие достаточно надежное. Я тоже особых глюков не встречал.

Потеря сенсора, t<10, t>100:colibrilab, 14 Апр. 17, 02:22

Какова реакция автоматики на температуру 85.0 °C?

Коллега, давайте вы спуститесь на землю. Посмотрите на чем во всех ветках скетчи под Arduino.colibrilab, 14 Апр. 17, 02:22

Этот форум еще не весь инет... В обиходе распространены гораздо больше языков программирования и более того профессиональные программисты сильно ругают Arduino за подход к программированию.
Но и на этом форуме есть решения не на C++ и Arduino [сообщение #12806507]
[BASCOM-AVR - альтернативная среда разработки для Arduino]

Ооооо... Какие дали далёкиеcolibrilab, 14 Апр. 17, 02:22

Это не дали далекие, а программирование, уважаемый коллега. Отладка и тестирование - неотъемлемый атрибут при разработке стабильно работающих устройств. Вы должны это знать, раз разработали эту автоматику.

Вот в этом и заключается отличие скриптов от нативного кода.colibrilab, 14 Апр. 17, 02:22

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

Какова реакция автоматики на температуру 85.0 °C?Mnz, 14 Апр. 17, 10:51

Положительная, я бы даже сказал - очень хорошая А вы про что? В каком месте этот датчик?

Этот форум еще не весь инет... В обиходе распространены гораздо больше языков программирования...Mnz, 14 Апр. 17, 10:51

Я в курсе, что есть много языков программирования. В связи с тем, что я программист, мне не надо это рассказывать

Это не дали далекие, а программирование, уважаемый коллега. Отладка и тестирование - неотъемлемый атрибут при разработке стабильно работающих устройств. Вы должны это знать, раз разработали эту автоматику.Mnz, 14 Апр. 17, 10:51

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

Т. е. считаете отсутствие отладки преимуществом? Наверное никогда ней не пользовались...Mnz, 14 Апр. 17, 10:51

Ммммм... Mnz, вы втираете мне какую-то дичь. Я занимаюсь программированием 25 лет, имею за плечами несколько крупных проектов на разных языках и платформах. Да - если можно написать программу в несколько строк, то это лучше, чем написать программу в несколько сотен строк. Если программа настолько проста, что её нет нужды отлаживать, то это хорошо. Вы можете писать хоть на Ассемблере и отлаживать сколько душе угодно. Я напишу в скрипте пару строк вместо этого.

Положительная, я бы даже сказал - очень хорошая  А вы про что?colibrilab, 14 Апр. 17, 12:10

Я про то что если датчик DS18B20 не смог измерить температуру, он возвращает 85.0 °C.

Я про то что если датчик DS18B20 не смог измерить температуру, он возвращает 85.0 °C.Mnz, 14 Апр. 17, 12:22

В разных библиотеках по разному. Здесь нет такого бага.

И как решена проблема того что датчик может сообщить о температуре 85.0 °C хотя в реальности она будет совсем другая?

За два года я не сталкивался с какими-либо неполадками в работе ESP8266. colibrilab, 14 Апр. 17, 10:04

Это не значит, что возникнуть они не могут, а мы все-таки не лампочкой моргаем. Работать с регистрами напрямую производитель не дает (что они там наворотили в SDK хз), watchdogа нормального нет...
Подвисоны кстати как-то описывались на esp8266.ru. Вот народ внешнюю собаку городит http://samopal.pro/wdt-ne555/



Добавлено через 4мин.:

Здесь нет такого бага.colibrilab, 14 Апр. 17, 12:32

Как этого удалось добиться? DSки какие-то особенные?

И как решена проблема того что датчик может сообщить о температуре 85.0 °C хотя в реальности она будет совсем другая?Mnz, 14 Апр. 17, 12:40

Подключайте датчики нормальными проводами, чтобы не было проседания по питанию, и всё будет нормально. В CLRC-02 работает фильтрация данных от сенсоров - если датчик выдаст "левое" значение, то оно будет отброшено. К тому же, библиотека DallasTemperature для ESP8266 ведет себя иначе, нежели библиотека для Arduino - она не возвращает 85.0 при потере датчика.

Это не значит, что возникнуть они не могут, а мы все-таки не лампочкой моргаем.sevpro, 14 Апр. 17, 13:04

Вот когда возникнут, тогда и продолжим разговор. Пока не возникали. Всякого рода "подвисания" могут запросто возникать по вине программиста, а не по вине МК.

Подключайте датчики нормальными проводами, чтобы не было проседания по питанию, и всё будет нормально.colibrilab, 14 Апр. 17, 13:18

Это не поможет с некоторыми датчиками которые при нагреве до 100 и выше градусов начинают вести себя неадекватно. Были случаи неадекватности и при меньших температурах.

Посмотрел "схему", плату. Навскидку: разделение высоковольтной и низковольтной частей никакое, зазоры между дорожками местами слишком малы (к разъему "valve" сетевое вообще подключать нельзя), ни одного конденсатора по питанию после стабилизатора не увидел, конденсатор в снаббере явно неподходящий по напряжению.
Кстати, выводы по поводу регулирования мощности очень спорные.