Ненавязчивая автоматизация ректификационной установки

Кто-нибудь пробовал версию NEW на Raspberry Pi Zero?

Добавлено через 7дн. 22ч. 35мин.:

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

запихать в одну пластиковую трубу?NBVV, 04 Авг. 21, 12:24

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

PS
Дело в том, все переключения силовых элементов в силовых модулях данной автоматики происходит в нуле сетевого напряжения, а для активных нагрузок, естественно, еще и в нуле тока. Например, для регулирования мощности нагрева ТЭНа используется PDM (ака "Брезенхем"). Поэтому уровень высокочастотных наводок гораздо ниже, чем, например, при фазовом регулировании мощности.

Добрый день. Пока идут запчасти на «New», решил опробовать новый аппарат на «Old» схеме управления тэном, так как у нее есть ручной режим. Что-то пошло не так, помогите, пожалуйста, разобраться что именно.
Прошил "Модулек", при первом включении он, вроде, ведет себя как надо, согласно этому: «Если все сделано правильно, то на индикаторе сначала будет тестовый показ всех сегментов индикатора с последующим выводом растущих целых чисел».
Снимаю питание с "Модулька", затем восстанавливаю и он продолжает с того места где закончил, то есть если при выключении на табло было 147, то при последующем включении – 148,149 и дальше по нарастающей. Правильно ли это? Не должен ли он, после снятия питания начинать все сначала?
Спрашиваю потому, что в и блоке управления тэном, он тоже продолжает с последней цифры, которая была перед выключением.
Первое включение. К сожалению не запомнил с какой цифры начал отсчет "Модулек", но лампа (60 Вт )светилась на мощности примерно 10 ватт,. Секунд через пять с платы пошел дым и я все вырубил. Задымили (но не сгорели) R10 и R11 на 360 и 330 Ом в обвязке триака (у меня стоит BTA 80 800, решил, что запас карман не тянет). Резисторы были на 0,125 Вт. Заменил, каждый на 4 таких же соединенных параллельно-последовательно.
Второе включение. "Модулек" продолжает примерно с цифры 158, на кнопки реакции нет. Лампа, вроде, светится с той же мощностью как и во время первого включения. Выключил схему сек. через десять. Связки резисторов на R10 и R11 наощупь – градусов 60.
Прошу совета в каком направлении копать?

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

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

Правильно ли это? Не должен ли он, после снятия питания начинать все сначала?NBVV, 14 Авг. 21, 11:44

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

Спрашиваю потому, что в и блоке управления тэном, он тоже продолжает с последней цифры, которая была перед выключением.NBVV, 14 Авг. 21, 11:44

В блоке управления ТЭН-ом используется другая прошивка. Там должен быть ноль и ожидание нажатия кнопок.

"Модулек" перепрошил. Теперь при подаче питания – все корректно. Но не долго)). Давлю кнопку «+», на индикаторе появляется «1», лампа резко зажигается (как и раньше, примерно ватт на 10 светит) и секунды через три R10 и R11 раскаляются. Похоже, что лампу зажигает MOC3083, а не BTA80. Что тут можно предпринять?

Похоже, что лампу зажигает MOC3083, а не BTA80. Что тут можно предпринять?NBVV, 15 Авг. 21, 01:46

1) См. пункт 4.4. Поиск неисправностей в этом топике и 2) поставьте попроще симистор. Как на исходной схеме - BTA16 или BTA20.

" К сигнальной шине крейта подключен управляющий компьютер Raspberry Pi 3". Уточните, пожалуйста, модель/модели. Или любая подойдет?

Уточните, пожалуйста, модель/модели. Или любая подойдет?NBVV, 16 Авг. 21, 12:07

Полагаю, с версиями Pi 3 B, Pi 3 B+ и Pi 4 B проблем не будет. Сейчас, у меня, конкретно, на управлении стоит платка Raspberry Pi 3 model B V1.2.

В режимах, которые требуют работы тэна на 100%-й мощности, хочу (пока вручную) шунтировать силовые электроды симистора. То есть будет включен либо АВТ1 либо АВТ2. Вопрос такой: если, по какой-либо причине, в произвольный момент времени, оба автомата окажутся включенными, может ли от этого что-нибудь сгореть в схеме управления тэном?

Вопрос такой: если, по какой-либо причине, в произвольный момент времени, оба автомата окажутся включенными, может ли от этого что-нибудь сгореть в схеме управления тэном?NBVV, 22 Авг. 21, 16:05

Дыма не будет ;)

PS
У модуля вообще-то есть возможность быстрого приращения/уменьшения уровня модуляции. Чтобы быстро добраться, например, до тех же 100% или до 0%. Для этого нужно удерживать соответствующую кнопку (+ или -).

Про удерживание, я знаю. Тут вопрос скорее "экономии")). Полагаю, что так схема (точнее триак) дольше проживет. Зачем его гонять, да еще и на 100% мощности, к примеру, во время перегонки браги? А так - Щелкнул автоматом, и пусть трудится только тэн, а схема регулировки - "отдыхает")).

А так - Щелкнул автоматом, и пусть трудится только тэн, а схема регулировки - "отдыхает")).NBVV, 24 Авг. 21, 12:33

Одумайся, не стоит это делать!!!
Предложенный способ шунтирования триака ТЭНа ОПАСЕН!
Рано или поздно, забудется, что нужно вовремя отключить "шунт", и случится беда... с вытекающими последствиями...
Триак железный, нечего ему отдыхать. Лучше с запасом поставить триак по мощности и радиатор по мощнее поставить.
Мы с Сергеем в этой ветке обсуждали как можно реализовать определения пробоя на КЗ перехода триака и защиту от этого. Но чтоб триак закорачивать самому - нонсенс...

"и случится беда". Можно поподробнее? Что именно может произойти?

"и случится беда". Можно поподробнее? Что именно может произойти?NBVV, 25 Авг. 21, 01:19

Автоматика должна отрабатывать аварийные режимы и выключать нагрев. А вы нагрев решили закоротить навсегда, независимо от состояния установки!
Никогда не видели расплавленного ТЭНа и 220 на стенках куба? И это еще цветочки по сравнению с объемным взрывом паров спирта при отключении (обрыве шланга) охлаждающей воды.

Можно поподробнее? Что именно может произойти?NBVV, 25 Авг. 21, 01:19

Уж извини, это не по теме.
Подробней тут:
[Наше хобби, безопасность, нарушения и последствия]

Sig и BogAD, я понял о чем вы. У меня немного другая ситуация. Стоят три двух-киловатных тэна. Если два подключены через автоматы, то какой смысл третий пускать через схему управления? Включаю все три, при перегонке браги или при начальном разогреве СС во время второй перегонки. Далее один тэн отключу, второй будет оставаться включенным, а третий будет управляться схемой регулировки (мне нужна суммарная мощность 3-3.5 кВт).
Если ставить одну схему управления на 6кВт (ну или три, чтоб на каждый тэн), то, как я почерпнул, в том числе и в этой ветке, начнутся проблемы с миганием света и тп. Поэтому мне видится контактор на входе 220-ти вольтовый, кВт на 10. Он и будет отрубать все по сигналу от малинки. Или я глубоко заблуждаюсь?

2. О визуальном программировании в ненавязчивой автоматике

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

Преамбула такова. Пользователей автоматик условно можно разделить на две неравные группы.

Первая, многочисленная, группа пользователей, назовем их "пользователями-производственниками", просто делают спирт и другие продукты по отработанным алгоритмам. Это их главная и/или единственная цель и какие-то "глубинные" особенности железа и автоматик, которые они используют, их совершенно не интересуют. Главное, чтобы это был надежный и эффективный инструмент. Ну, скажем, как автомат Калашникова для бойца.

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

Ее тоже можно разделить на две подгруппы, которые можно назвать так: "программисты" и "не программисты". Это деление взято в кавычки потому что условно. Речь идет не о владении какими-то конкретными языками программирования, а об умении или не умении мыслить алгоритмически. Т.е. способен человек выстраивать логическую последовательность шагов и циклов для достижения цели или нет. Последние, обычно люди творческие, видят путь в целом и на полуинтуитивном уровне способны достичь цели. Но разложить этот путь на последовательность формализуемых шагов не могут.

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

Итак, рассмотрим теперь только подгруппу "программистов" (в указанном выше смысле). Ее тоже можно разбить на две подгруппы. Первая - реальные программисты, владеющие языками программирования и опытом разработки программ. Вторые не имеют такого опыта. Они являются "программистами" только по стилю мышления. Для первых, написать пользовательский скрипт прямо в малинке на какой-нибудь простенькой IDE типа Geany, не представляет каких-нибудь серьезных проблем. Для вторых, такой способ может оказаться слишком тяжелым, мучительным и даже неприемлемым. Как же быть?

Один из приемлемых вариантов - адаптировать какой-нибудь свободный проект по визуальному (графическому) программированию, умеющий сохранять результирующий алгоритм в виде питоновского скрипта. Такие проекты, причем некоторые с открытыми исходниками и приемлемыми лицензиями есть. Еще глубоко не копался в теме. Вот небольшой список для "затравки":

1. Ryven
2. PyFlow
3. Marionette и еще про нее же.
4. Blockly.

Немножко критической информации с хабра:

5. Визуальное программирование — почему это плохая идея
Сама статья так себе... Но! Очень интересные и информативные комментарии к статье! Весьма достойное обсуждение!

На мой взгляд, применять "визуальное программирование" оправдано там, где мы хотим на выходе получить "визуальный" объект (окошки, кнопки, графики и пр.). Для это есть Delphi, С++, С# и даже для Pyton есть такая возможность в виде, скажем, Qt5. На моей "малинке" нет графики, поэтому мне и этого там не нужно.
Самое сложное в нашем проекте - это модуль lite.py, и он уже написан без всякого "визуального программирования". А дописать к нему скрипт управления колонной, который использует готовые объекты из lite.py можно и "на коленке" без "визуального программирования".

PS
Могу ошибаться, конечно, но , думаю, код сгенерированный с помощью "визуального программирования" будет "ого-го", и как его потом отлаживать (тем более на pyton)?

Могу ошибаться, конечно, но , думаю, код сгенерированный с помощью "визуального программирования" будет "ого-го", и как его потом отлаживатьruslan_ka, 30 Авг. 21, 14:51

Смотрите. Есть автомобиль Мерседес и его управление системами с помощью джойсика. В принципе это и есть визуальное программирование. Смотришь на экран и крутишь колёсико, толкаешь его туда-сюда. И никакого армагедона от сбоя настроек не происходит. Просто настройки автомобиля не позволяют с помощью этого интерфейса создать критическую ошибку. Температура не опустится ниже 16 и не поднимется выше 32. Потому что это жёстко задано и с помощью джойсика эти параметр нельзя изменить в большем диапазоне. А если крутить колесо до конца некоторых диапазонов, то колесо упирается и больше не крутится. Это тоже программная фишка.
Что мешает сделать такой интерфейс в самогонной автоматике? Просто если пользователь будет излишне шевелить мышью, до конфликта оборудования, то выскочит предупреждение с объяснениями и ползунок настройки не пойдёт дальше разрешённого.
Но даже если в софте будет дырка, и где то ползун уползёт дальше, то система не запустится, а сброс к базовым шаблонам исправит ситуацию.
Сам софт сделать условно бесплатным, оплата по желанию или оплата каких либо особо наверченных функций.
Неужели так нельзя сделать?

управление системами с помощью джойсика. В принципе это и есть визуальное программирование. Смотришь на экран и крутишь колёсико, толкаешь его туда-сюда.Shobby, 30 Авг. 21, 17:03

Тут никакого программирования нет - ты описываешь классический АРМ с графическим интерфейсом. Если тебе ближе тема автомобилей - то мы обсуждаем автопилот Теслы и как определить препятствие впереди и его объехать.
На автоматике вообще может не быть графического интерфейса - загрузил файл с алгоритмом и все. Ничего крутить ненадо - все автоматизированно! И обсуждаем мы методы создания таких файлов-алгоритмов.