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

Точность в наших задачах не нужна. Нужна стабильность .
А кто мешает взять шунт например 0.001 Ом? Размер 2512  в продаже доступен.

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

а так вполне себе постоянный и известный сдвиг...bigson, 31 Авг. 17, 22:03

Этот сдвиг зависить будет от модели трансформатора. Что сводит на нет повторяемость схемы

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

По поводу умножителя мощности - а не проще тогда применить что-то типа ADExxx из электросчетчиков, с шиной SPI кажется? Там уже просто регистр прочитать и узнать что с потреблением. Оно там само считает. Тем более гальваническая развязка все равно светит.U-M, 31 Авг. 17, 20:49

сначала надо по граблям погулять )))

В датчике RMS и нуля диодик D2 переверните, а то вдруг кто-то так соберет :-)bigson, 31 Авг. 17, 22:03

Да. Конечно. Забыл повернуть диод. Уже поправил. Спасибо! :)

---

---

Теперь по поводу нуля после трансформатора. Транс используется как измерительный. Конечно трансформаторы не идеальны, поэтому было интересно проверить какой реально будет сдвиг фазы. Сегодня утреца  проверил. На двух трансах ТПГ-0,7-2х6в и пары нагрузок (1кОм и 33кОм). Схема - двухполупериодный выпрямитель (с двух вторичных обмоток), выпрямитель нагружен на резистор. Сигналы сети (на входе транса) и с резистора - на двухлучевой осциллограф. Примеры осциллограмм - в приложении к топику. Времена разверток на них есть. Нули сигналов, естественно, совмещены.

Ну что можно сказать? Для решений, в которых нуль берется после транса, как говорят, есть разные новости :) - плохая и несколько хороших. Плохая - сдвиг не бесконечно малый, а вполне заметный. Хорошие:

1) Сдвиг сравнительно небольшой (если после выпрямителя сигнал просто подавать на компаратор, то фронт импульса нуля будет приходить примерно на 700-730 мкс раньше реального нуля в сети, а срез импульса - примерно на 500 мкс раньше). Для фазового регулятора такая точность, наверное, недостаточна, но здесь речь идет о Брезенхеме. А ему, по большому счету, на такой сдвиг глубоко наплевать.
2) Величина сдвига практически не зависит от нагрузки в пределах 1-33 кОм и не сильно (в пределах 20 мкс по фронту) отличается для двух трансов одной марки, которые использовались в тестировании.
3) Ну и еще одна хорошая новость, заключается в том, что сдвиг происходит в нужную сторону. Т.е. импульс детектора нуля будет приходить раньше, чем наступит реальный нуль сети. В данной системе этот импульс используется для инициирования аппаратного прерывания МК, чтобы он успел обработать информацию, принять решение и подать/не подать импульс на затвор ключа еще до прихода истиного нуля. А МОСька уже проследит чтобы ключ открылся строго в нуле. Поэтому - такой сдвиг на опережение - это даже скорее плюс, чем минус.

Таким образом, не так все страшно. Главное - есть выбор. Использовать импульс после транса, который будет идти с небольшим опережением или поставить на шину отдельный, более точный детектор нуля? Тем более, что шина и обсуждаемая архитектура позволяет последнее сделать безо всяких проблем :)

---

---

А по поводу схемы PDM-стабизатора мощности, где регулировка производится с пропуском полупериодов по Брезенхему, то это была просто иллюстрация серьезного потенциала 85-й тиньки в подтверждение фразы m16 о том, что на этой тиньке можно сделать полноценный стабилизатор напряжения. Просто - ни к чему не обязывающая "схемная зарисовка". Придут детальки, скидаю на макетке, посмотрю, поварьирую, расскажу, если что-нибудь получится заслуживающее внимания.

---

PS
На данный момент меня вполне устраивает как малинка сама стабилизирует мощность нагрева, ориентируясь только на датчик RMS. Безо всех этих хлопот со стабилизаторами "в железе". Просто в концепции иерархической системы вопрос: "На каком уровне должна производиться стабилизация параметров установки: мощность нагрева, или давление в кубе или какие-нибудь другие параметры (это уже в зависимости от задач)? На низком уровне или на уровне малики?" не является таким однозначным, как в одноуровневой системе. Поэтому в голове крутятся разные варианты от... и до... :)

Друзья, у меня предложение:
Если желтолицые братья уже выпускают блоки с нужным нам функционалам, может будем базироваться на этих блоках?
К примеру датчик напряжения для блока RMS https://ru.aliexpress.com/...0302.4.8.tbEXfy
Дешево и сердито, хорошая точность, на борту даже ОУ стоит. Добавить только Мегу и все.

Если желтолицые братья уже выпускают блоки с нужным нам функционалам, может будем базироваться на этих блоках?BogAD, 01 Сент. 17, 09:59

Блок блоку рознь. СтОит ли ради трансформатора, пары диодов и резисторов приспосабливать отдельную платку?

И всеж тиньки может на питании 3.3В ?U-M, 31 Авг. 17, 20:49

Ну ведь никто же никого не неволит. Если есть желание питать тиньку от 3.3V - никто же не запрещает. На шине для питания предусмотрены и 5V и 3.3V. В разводке только один полосок нужно будет откорректировать. Но, при понижении питания, нужно будет снизить тактовую частоту. Если верить datasheet, то как минимум, до 10МГц. А на частоте 16МГц тинька будет работать только при питании от 4.5V до 5.5V.

---

---

Статическая характеристика стабилизатора мощности "Малинка"

В существующем варианте системы, стабилизацией мощности нагрева куба непосредственно занимается малинка. Способ прямой как шлагбаум: раз в 4 сек (точнее - 4.8 сек) малинка получает от датчика RMS среднеквадратичное значение напряжения питающей сети. По очень простой формуле вычисляет уровень PDM-модуляции (по Брезенхему), который должен быть у контроллера ТЭНа так, чтобы мощность нагрева была нужной (при текущем напряжении сети) и корректирует это значение в контроллере ТЭНа посредством I2C. Опыт почти годовой эксплуатации показывает, что метод работает вполне стабильно. Но у меня - вполне приличные сети и проблема стабилизации мощности нагрева для меня неактуальна. Однако, бывают сети похуже. Чтобы понять как в таких сетях поведет себя описанный чуть выше регулятор (назовем его для простоты - "регулятор Малинка"), я снял его статическую характеристику в достаточно широком диапазоне изменения напряжения питающей сети.

Для этого я запитал силовую часть установки через ЛАТР и в цепь включил бытовой цифровой измеритель мощности. В скрипт добавил еще один тестовый режим (№ 8), в котором малинка просто стабилизирует мощность нагрева на заданном уровне (в данном случае - 600Вт), не обращая внимание на остальные параметры установки (кроме, конечно датчика RMS). Далее запустил установку в этом режиме и изменял напряжение "питающей сети" (посредством ЛАТРа) в диапазоне от 140В до 260В. Ниже 140В не ходил - срабатывает блокировка по напряжению (не стал убирать), да и ТЭН в кубе уже не выдает требуемых 600Вт даже при 100% модуляции.

Несмотря на то, что измеритель мощности True RMS, значения мощности при некоторых значениях PDM "гуляли". Хотя устанавливаемые малинкой уровни PDM на индикаторе контроллера ТЭНа стояли мертво. Это, скорее всего, связано с тем, что период усреднения используемого ваттметра меньше, чем период Брезенхема в регуляторе мощности (для точности регулирования 1% - это 100 полупериодов сети). Тем не менее, даже самая сильная болтанка не превышала 1.8% и статистику вполне можно было набрать.

График - на рисунке в приложении к топику. Красненькое - это мощность, потребляемая кубом, которая измерена ваттметром (шкала слева). Синенькая - это уровень PDM модуляции (доля пропущенных к ТЭНу полупериодов в %, шкала справа).

Как видим, малинка совершенно спокойно справляется с регулировкой мощности в диапазоне изменения сетевого напряжения от 140 до 260В. Мощность нагрева держится на уровне 600 Вт. Максимальная ошибка стабилизации мощности не превышает 1.8%. Поэтому, ИМХО, для данной системы автоматизации, какие-то "железные" (аппаратные) регуляторы мощности изобретать, скорее всего, не нужно. Думаю, на этом вопрос о стабилизации мощности можно и закрыть.

PS
Да, необходимо отметить еще один момент. В данном тесте построена статическая характеристика регулятора мощности. Сейчас малинка корректирует мощность раз в 4.8 секунды. Если же требуется стабилизация мощности для демпфирования более быстрых изменений сети, то тогда, конечно...

Сейчас малинка корректирует мощность раз в 4.8 секунды. Если же требуется стабилизация мощности для демпфирования более быстрых изменений сети, то тогдаOldBean, 01 Сент. 17, 13:03

Насколько понимаю, основная задержка связана с опросом DSок. В варианте отдельного температурного модуля температуры уже будут подготовлены, что позволит по любому уменьшить время цикла 4.8 сек?

Насколько понимаю, основная задержка связана с опросом DSок. В варианте отдельного температурного модуля температуры уже будут подготовлены, что позволит по любому уменьшить время цикла 4.8 сек?U-M, 02 Сент. 17, 10:48

Нет. DS-ки здесь ни при чем. Они запускаются одновременно, в разных потоках и данные готовы чуть меньше, чем через секунду. С ними (в принципе) можно работать асинхронно и без температурного сревера.

Длительность главного цикла скрипта управления 4.8 сек выбирался совсем из других соображений. Ректификация - довольно неспешный и длительный процесс. Оптимальный вариант - опрос датчиков, анализ ситуации и принятие решений - один раз в несколько секунд. Раз в секунду - слишком часто. Лог раздутый, много избыточных (повторяющихся) данных. Раз в 10 сек - уже слишком редко. Динамика сглаживается. Например, при запуске колонны. Или отладке алгоритмов регуляторов скорости отбора.

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

Ну а почему конкретно такая странная цифра 4.8 сек? Это - чисто из соображений удобства. У меня основная единица измерения времени - минута (и, естественно, - десятые и сотые доли минут). Для логов, графиков, выдач на экран и т.д. Кванты в 4 сек или 5 сек для этого неудобны (это - 0.0666666...мин и 0.0833333...мин соответственно :)) Поэтому и за "квант" процесса взято 4.8 сек (это 0.08 мин). Считать и визуально воспринимать удобно :)

Ну а если вернуться к регулятору мощности, то, для таких инерционных процессов, как ректификация, отслеживать и тем более пытаться стабилизировать "высокочастотные" нестабильности сети (на уровне Гц и выше), ИМХО, не имеет особого смысла. Установка просто не будет успевать реагировать на такие высокочастотные колебания. Только на более медленные тренды.

Коллеги-знатоки. Стесняюсь спросить, а какой № вывода у малинки Int?
============================
Почти догадался - любой назначенный программно. General Inputs/Outputs. Так?

какой № вывода у малинки Intgol_avto, 05 Сент. 17, 08:48

А по идее любой, не питание, не земля и на перспективу не GPIO с пометкой в скобках.

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

U-M, дык в малинку можно нормальные колонки втыкнуть, и научить ее кричать человеческим голосом .)

Вот что проиcходит при запуске программы contr.py  Все модули на месте и диагностируются Ок. Датчик RMS показывает 230 В и малинка правильно его его читает. Скорость шины I2C 9600
Малинка свежая, 3-я, модель В
================
И ещё вопрос. Что это за коэффициенты в файле contr.py    self._coef = 4840000.0/self._W_220  ?
wrk = self._vs.V*0.00454545454545  ?

На основе информации предоставленной OldBean, сделал контроллер шагового двигателя для регулирования расхода воды через дефлегматор, холодильник и т.п.
Шаговый двигатель Nema 17, 12V 1.3A с драйвером A4988. В режиме полного шага двигатель делает 200 шагов за один оборот или 1.8 градуса за один шаг. Это взято за основу, так как этой точности думаю будет вполне достаточно для плавной регулировки расхода воды. Но чтобы двигатель не дергался рывками, можно применить деление шага, для чего предусмотрены джемперы. Я для себя выбрал деление шага 1/4, поэтому джемпер установлен на драйвере А4988 в положение MS2, а в скетче переменная step_division = 4.
При этом по i2c будут передаваться значения от 0 до 200, на индикаторе будут отображаться теже значения, а фактически двигатель будет делать 800 шагов за оборот, а при коротком нажатии кнопок перемещение составит 4 шага, при длительном нажатии соответственно – 20.
Так как бОльшую часть времени мотор не работает, предусмотрен спящий режим. После 30 секунд ожидания на пин ENABLE драйвера подается 5 вольт, загарается светодиод и активируется спящий режим (pWidth = 30000). Для выхода из спящего режима предусмотрена задержка в 1 секунду (T = 1000).
Файл contrSTPR.py содержит классы-обертки для шагового двигателя. Если не будет замечаний или дополнений, то его содержимое нужно будет добавить в contr.py
И вопрос: - Если будет несколько шаговых двигателей, то как лучьше организовать классы-обертки?
Для правильной работы драйвера, его нужно настроить:
Плюсы-минусы данного решения на мой взгляд.
Из минусов: Если подать на драйвер напряжение (12 вольт) одновременно с подачей напряжения на ардуинку, то двигатель делает довольно-таки большое количество шагов по часовой стрелке, то есть в сторону закрытия крана, что может быть не очень хорошо. Но думаю все ограничется простым пропуском шагов. Так что лучьше подавать 12 вольт после того как загорится светодиод.
Из плюсов: Так как двигатель без редуктора, то перед включением или когда спящий режим, можно вращать вал двигателя вручную. То есть перед началом работы, чуть приоткрыв кран, можно снять его с мертвой точки. Это и будет нулевой позицией. Если при этом возникнет капель – ничего страшного.

И ещё вопрос. Что это за коэффициенты в файле contr.py    self._coef = 4840000.0/self._W_220  ?
wrk = self._vs.V*0.00454545454545  ?gol_avto, 15 Сент. 17, 16:51

Первый - это 100(%)*220(В)*220(В)/(ном.мощность ТЭНа). Раньше использовался в вычислениях устанавливаемой мощности нагрева. Рудимет. При очередной модификации модуля - уберу чтобы не смущал.
Второй - это отношение текущего ср.кв.напряжения к 220В (V/220). Старая привычка заменять деление (для констант) умножением :)

Как uzer, могу сказать что в таком виде программой пользоваться неудобно. Желательно после её запуска должен "высветиться" в виде таблицы список режимов со считанными данными и вопросом - "будем редактировать?" Если да, то жмем соответствующую цифру необходимого режима и c подробной расшифровкой каждого пункта вводим соответствующие значения. Это, чтобы не писать GUI. А мощность ТЭНа разве не участвует в программе, если к примеру у меня 3 кВт, то тогда как быть?

Как uzer, могу сказать что в таком виде программой пользоваться неудобно. Желательно после её запуска должен "высветиться" в виде таблицы список режимов со считанными данными и вопросом - "будем редактировать?" Если да, то жмем соответствующую цифру необходимого режима и c подробной расшифровкой каждого пункта вводим соответствующие значения. Это, чтобы не писать GUI. А мощность ТЭНа разве не участвует в программе, если к примеру у меня 3 кВт, то тогда как быть?gol_avto, 18 Сент. 17, 08:41

Да. Конечно. Она (программа) в данном виде и не рассчитана на диалоговый режим работы. Для этого нужно писать еще один "программный слой" - слой UI. Sorry, за небольшое отступление от темы, но в природе существуют два основных способа взаимодействия человека с компьютером. Диалоговый и пакетный. По сути, ничего другого до сих пор так и не придумано. Вы говорите о диалоговой программе. К сожалению, большинство современных пользователей сызмальства крепко "подсажено" на диалоговый режим. Поэтому пакетный режим часто кажется им неудобным. На самом деле это не так - у каждого способа есть свои плюсы-минусы. Про все эти +/- можно почитать в Сети, поэтому перейдем сразу к сути.

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

Что из себя представляет управляющая программа? Это - объектная модель реальной установки, которой она управляет. Установка и ее модель "живут" одновременно. Одна в реальном, а другая в виртуальном мире. Они непрерывно обмениваются информацией (синхронизируются) друг с другом. Особенности данной реализации:
1. Эта модель написана на скриптовом (интерпретируемом) высокоуровневом языке python, который не требует предварительной компиляции. Поэтому вместо диаловых окон, связанных с "настройкой" программы используется непосредственное редактирование текста скрипта. Поверьте, это действительно гораздо проще, гораздо удобнее и гораздо гибче.
2. За счет создания классов-оберток всех основных элементов реальной системы, уровень абстрагирования получился достаточно достаточно высоким. Поэтому писать/редактировать скрипты просто и удобно. До неприличия. Нужно просто предварительно потратить немного времени, чтобы научиться разговаривать с малинкой на языке python и, главное, более-менее отчетливо представлять как нужно управлять процессом ректификации, который нужно запрограммировать в модели.

Если отключиться от технических деталей, то моделирование установки и нового процесса ректификации в целом выглядит так.
1. Сначала "строится" виртуальная модель "железа". Т.е. в виртуальном мире (в скрипте) создаются объекты, соответствующие реальным объектам установки. Классы этих объектов описаны и реализованы в соответствующих модулях (см. файлы contr.py, sens.py). При создании объектов (т.е. при вызове конструкторов) можно указать все необходимые параметры. Они все именованы. Значения по умолчанию, естественно, соответствуют моему "железу". Но можно поставить другие. Кстати, создавая объект ТЭН, вот так можно указать его номинальную мощность в конструкторе:
Здесь contr - имя импортированного модуля, в котором я описал класс TEH и его реализацию, vs - ранее созданный объект "датчик RMS", который необходим для правильной регулировки мощности нагрева, а W_220 - как раз номинальная мощность Вашего ТЭНа в ваттах (при 220 В). Явное указание W_220 = 3000.0 как и скажет малинке создать "виртуальный" ТЭН с номинальной мощностью 3 кВт.

Точно так же создаются и другие объекты (датчики, клапан отбора и пр.). Кстати, при создании объекта класса SD (устройство отбора), тоже нужно указать ваш коэффициент пересчета % ШИМа в мл/час, полученный в результате калибровка клапана отбора. Например вот так:
У моего клапана с моим жиклером получилось 9.5 мл/час на 1% ШИМа. У Вас, естественно, будет свое значение.

2. После создания объектов описываются алгоритмы их взаимодействия. Это - режимы работы установки. Они пронумерованы (от 0 до 9) и описываются в так называемой "карте режимов". В карте режимов указываются все необходимые параметры режимов: мощность нагрева ТЭНа, необходимость стабилизации этой мощности, скорость отбора, необходимость регулирования скорости отбора и по какому алгоритму, условия окончания режима (по нескольким критериям) и номер режима, в который перейдет установка по окончанию данного. Все это очень подробно прокомментировано в скрипте управления (файлы nna_XX.py, где XX - номер версии). Если какие-то фрагменты непонятны - дайте знать - расширю комментарии. Параметры режимов тоже, естественно, указываются непосредственно в тексте скрипта. Какие-то дополнительные диалоги (типа "чего изволите?"), ИМХО, здесь просто неуместны.

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

Понятно, что для отлаженных/серийных процессов ректификации, все написанное выше нужно сделать только один раз. А потом, когда нужно, просто тупо запускать нужный скрипт командой python nna_XX.py :)

Весь процесс пройдет автоматически. Правда приемные емкости пока менять нужно вручнуюOldBean, 18 Сент. 17, 12:28

Хотелось бы, чтобы автоматика была полностью автоматикой. Залил СС "Х"л, "Y"% крепости, сказал к примеру отобрать "Z"% голов, поставил 3 (или "N" )ёмкости, включил и пошел спать. Утром всё готово и выключено. Вот это полная автоматика. Мне кажется к этому надо стремиться, тем более здесь на форуме уже так реализовано.

Вот это полная автоматика. Мне кажется к этому надо стремиться, тем более здесь на форуме уже так реализовано.gol_avto, 18 Сент. 17, 13:16

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

OldBean, я иногда захожу в вашу тему, но, поскольку не имею квалификации программиста, мало что понимаю в написанном....поэтому и не лезу, так сказать, с ненужными вопросами, и комментариями.

Однако у меня есть вопрос.
О каком экспериментировании в области кубовой ректификации вы говорите?
Хотел бы понять именно этот вопрос, для себя, по крайней мере.

И второй вопрос.
Вы пишете, что работу автоматики в полностью автоматическом организовать несложно.
Ок, а почему бы тогда этого не сделать, чтобы из академической плоскости вывести свое детище в практичесскую, когда она будет востребована среди форумчан?

О каком экспериментировании в области кубовой ректификации вы говорите?игорь223, 18 Сент. 17, 16:12

Я бы тут сделал одно маленькое уточнение (лишнее в предыдущем контексте) - кубовая ректификация с насадочными колоннами.

Мне такая установка интересна как пример динамической системы, которая, с одной стороны, достаточно проста для более-менее детального компьютерного моделирования (одномерное приближение для колонны и квазистационарность на сравнительно малых временах), а с другой стороны, - достаточно богата (даже просто в пленочном режиме), чтобы иметь нетривиальный фазовый портрет и динамику в фазовом пространстве. Ну для начала - хотя бы в двумерном фазовом пространстве W-Q (время, естественно, третья координата). Здесь W - мощность нагрева куба, Q - средняя скорость отбора этанола.

Если хватит здоровья и времени, то "для души" хотелось бы сделать следующее:
1. Сначала реализовать адекватную одномерную квазистационарную модель насадочной колонны (куб и дефлегматор определяют квазистационарные граничные условия) и исследовать при помощи этой модели фазовое пространство системы. Научные работы в этой области есть. В том числе - довольно свежие. Но полное фазовое пространство такой системы вроде бы (!) еще никто не построил. Ну я пока не встречал таких работ.
2. Если же обнаружатся какие-то интересные области и/или траектории в этом фазовом пространстве, то хотелось бы реализовать их на практике и посмотреть что получится. Именно это я имел в виду во фразе "экспериментирование в области кубовой ректификации" :) А пока (на данный момент) экспериментально "растоптаны" и используются на практике лишь сравнительно небольшие области фазового пространства. Да и то (как правило) одномерные срезы. Например, процессы при постоянной мощности нагрева, постоянной скорости потока пара на входе колонны (т.е. постоянном давлении в кубе), постоянной скорости отбора и т.п.

Вы пишете, что работу автоматики в полностью автоматическом организовать несложно. Ок, а почему бы тогда этого не сделать, чтобы из академической плоскости вывести свое детище в практичесскую, когда она будет востребована среди форумчан?игорь223, 18 Сент. 17, 16:12

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

Немного заключительной рефлексии на тему "Пользовательский интерфейс (UI) для универсальной автоматизации кубовой ректификации с насадочной колонной".

Итак, мы можем сформулировать задачу более формально: нам нужен интерфейс, который позволял бы реализовать любую траекторию в пространстве W-Q-t, где W - мощность нагрева, Q - скорость отбора (из дефлегматора) и t - время. Естественно, - с учетом данных, поступающих с различных датчиков (температуры и давления в различных точках системы). Т.е. по сути нам нужен какой-то человеческий интерфейс для задания произвольной функции F вида где (W,Q) - текущая точка в фазовом пространстве (т.е. - текущие значения мощности нагрева и скорости отбора), T1,...,Tn, P1,..Pm - значения температуры и давления в разных точках системы. Для реализации автоматики "с памятью" в число аргументов (кроме текущих значений) нужно добавить еще и предыдущие значения измеряемых параметров (T и P) и предыдущие состояния системы. Но сути задачи это принципиально не меняет.

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

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

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

---

Увы, мы опять и неизбежно приходим к выводу, что единственным, действительно универсальным, интерфейсом для исследовательской, экспериментальной установки является обычный текстовый редактор. Для написания и выполнения скриптов. Питон, как и Александр Сергеевич - "наше все" :))))

Я повторю свой вопрос. Собрал железо, малинка Raspberry Pi 3 мод.B, запускаю на столе, а работать не хочет. При тесте sens.py датчик RMS виден и напряжение с него читается правильно. Сразу же следующая команда contr.py - датчик RMS не виден, напряжение с него не считывается и соответственно отказ в работе. Тоже самое и при запуске программы nna_36.py. Похоже проблемы в скрипте contr.py и совместимостью с 3-ей малинкой. Да, скорость по I2C - 9600 разумеется.
И следующий вопрос. Хочу реализовать систему с тремя клапанами, для раздельного отбора фракций. 2 модуля уже реализовано, жду детальки на 3-й, но похоже мечты несбыточные. Скрипт сам никогда не напишу, хотя автор и говорит, что там всего пару строчек добавить. К сожалению вероятно придется весь этот "проект" похоронить, жаль конечно, а так заманчиво всё начиналось.
============================
Если рессетнуть малинку и сменить последовательность команд, то... nna_36 работает нормально (фиг.1), а contr.py по прежнему нет. Видимо самостоятельно программа contr.py работать не умеет.