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

Подумай что случится если симистор пробьет и тэн будет работать на полную а автоматика не сможет его отключитьwoddy, 15 Авг. 17, 22:00

Не совсем понял, мне вопрос?
Если этот вопрос краеугольным камнем мучает, что мешает поставить симистор по мощней, к примеру BTA41-800?

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

Меня удивляет, что на 34 страничке дискуссии, вдруг задумались о "обоснованности" применения плавного предохранителя.
А не смущает, что предохранители OldBean поставил практически на всех модулях, кроме сервера  температуры и RMS (хотя и на RMS ставить нужно)?  А на модуле цифрового ввода/вывода, так вообще предохранителя два!
Чего так зацепились???

Каждый в воле решить, нужен предохранитель или нет. Жука припаяйте.
Не понятно проблема... К примеру, используем мощность ТЭНа как у автора? Не вопрос, 10А предохранителя и ВТА16 хватит на все форс мажоры.
Ставишь ТЭН на 3 кВт? Смысл чего-то ждать от предохранителя в 10А?
Тут предохранитель не менее 16А, а ВТА с запасом на ток не менее 25А, к примеру BTA26-800BRG.
Мы же взрослые люди, что прописные истины тут мусолить?


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

Смысл в том, что у атмег сопротивление встроенного подтягивающего резистора не нормируется и находится в районе 30-50ком, что много для помехозащищенности. Кроме того, в моей практике пару раз эти резисторы переставали работать, весь чип работает, а подтяжки нет. Стоит внешний резюк повесить и все в норме.sevpro, 15 Авг. 17, 22:27

Хорошо. Опыта с Атмегой маловать. Пересмотрю схему и плату.

перерисовал и перезалил...

Зачем на каждый модуль ставить автомат? На слаботочку предохранители, автомат только на ТЭН (силовой модуль).
У предохранителя и автомата разные концепции аварийного размыкания.sevpro, 15 Авг. 17, 22:27

OldBean, за тобой последнее слово. Мне не трудно "выкусить" плавкие предохранители...

перерисовал и перезалилBogAD, 15 Авг. 17, 22:42

Прошу прощения, в даташите на МОС3083 к 4-й ноге идет резистор на 330 Ом, а 360 Ом к 6-й ноге. Думается что нормально будут работать оба на 360 Ом, но все же может придерживаться даташита, тем более что нагрузка у нас не-сильно-индуктивная?

Я поставил те оба резисторы 2-ваттные. После часа прогона, еле теплые.

Не всё. Я вот до сих пор не могу посмотреть Ваши логи, поскольку в log_viewergol_avto, 15 Авг. 17, 16:14

Лучше вообще закоментируй логирование -- целее будешь. I/O - одни из самых непредсказуемых задач из всех существующих и их категорически нельзя исполнять в управляющем потоке (flow control, а НЕ process theard). Для логов нужно что-то вроде FIFO структуры с отложенными тасками, где сами логи пишет subscriber (publisher-subscriber) или observer (хуже). Во втором питоне емнип (давно с ним не работал) асинхронщина из коробки реализуется twisted. В третьем хороших вариантов больше -- самый интересный asyncio, где есть класс Feature (предоставляет результат еще не выполненной задачи) и Task (потомок Feature) -- они годны для очереди тасков. Это оверхед, но он необходим для безопасного I/O.

Еще есть готовые решения обеспечивающие инфраструктуру\транспорт для логирующих тасков. Причем три разных направления: очередь тасков, очередь сообщений (MQ) и сервис логов.

Самый популярный представитель первого направления -- Celery, но она избыточна и плохо ложится на rpi, зато RQ отлично влазит в аппаратные возможности.

Второе направление - AMQP (RabbitMQ, ActiveMQ, Apache Kafka и т.д.) -- высочайшая ценность для экосистемы в целом, но в ресурсы rpi почти влазят (activemq хочет ~= 120mb на инстанс), однако ZeroMQ влезет почти наверняка.

Третье направление самое дорогое (по сути нужен отдельный хост), но зато он с преферансом и монашками. Zabbix, например. Однако, к его api в любом случае нужно обращаться асинхронно.

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

Если ты ничего не понял, то просто прочти еще раз первое предложение.

Если этот вопрос краеугольным камнем мучает, что мешает поставить симистор по мощней, к примеру BTA41-800?BogAD, 15 Авг. 17, 22:20

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

А что, разве никто не заметил косяк в схеме клапана отбора? Решил его (клапан) откалибровать и выяснилось, что схема не работает. MOC3083 нагрузку включает, а выключить не может. Дело не в индуктивной нагрузке, со слабенькой лампочкой тоже самое.
Почитал ДШ, а в ней

This device should not be used to drive a load directly. It is intended to be a trigger device only.

Так что надо ставить внешний симистор, как в регуляторе ТЭНа.

Лучше вообще закоментируй логирование -- целее будешь.lesbeg, 16 Авг. 17, 00:55

Этот Изопов язык действительно не понял, но предположил, что и в логировании есть недоработка. Так?

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

с лампочкой эксперементировать не советую. у неё пусковой ток в три раза больше рабочего

Разумеется последовательно с лампочкой (100 Ом холодная) было сопротивление 330 Ом. Так что ток через MOC3083 не превышал 0,5 А

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

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

но предположил, что и в логировании есть недоработка. Так?gol_avto, 16 Авг. 17, 09:30

Сама идея неверна.

Представь проходную предприятия.

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

На проходной есть охранник, который пропускает людей по предъявлению ими пропуска. В один момент времени охранник занимается только одним человеком.

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

В нашей метафоре запись лога -- лицо с непонятными бумажками.

Задачи IO (ввода\вывода) слабо предсказуемы и есть масса причин по которым их исполнение может занять больше времени чем мы рассчитывали (или они вообще не будут исполнены). 

Теперь посмотрим на псевдокод, который полностью покрывает описанную выше метафору.


Намного лучше делать так:


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

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

В первом сценарии лог будет создан через N миллисекунд, где N == время создания лога.
Во втором через N + M, где М == время нахождения задачи в очереди + небольшой оверхед на саму очередь (её брокера) и воркера, но M это хорошая плата за изъятие N из потока, который решает реально важные задачи.

Сама идея неверна.lesbeg, 16 Авг. 17, 13:09

Ну этот вопрос надо задать автору темы, OldBean
Хотя я и не говорил, что собираюсь смотреть логи при самом процессе ректификации, это и не нужно. Я хотел (осваивая линукс) просмотреть готовый лог, сделанный автором и сделать это на самой малинке, которая лежит на столе и ничем не занята, кроме этой задачи. Разве она с этим не сможет справиться?
Получилось, что это невозможно, поскольку автор предусмотрел просмотр логов на ноуте, подключенного по SSH к малинке.

[/#!/usr/bin/python
#coding:utf-8
import paramiko # Модуль для работы с SSH
import pylab as pl # Библиотека для построения графиков (matplotlib)

ssh = paramiko.SSHClient() # Содаем оклиента
""""Упрощаем" политику работы с ключами """
ssh.set_missing_host_key_policy(paramiko.AutoAddPolicy())
ssh.connect("192.168.0.22", 22, "pi", "raspberry") # Сединяемся с малинкой
stdin, stdout, stderr = ssh.exec_command("cat nna/log") # Выполняем команду (уже на малинке)
quote]

Получилось, что это невозможно, поскольку автор предусмотрел просмотр логов на ноуте, подключенного по SSH к малинке.gol_avto, 16 Авг. 17, 13:49

Да в общем-то задачи "универсального просмотрщика логов" там как бы и не ставилось. Это были просто примеры работы с малинкой по SSH. Но, тем не менее, Вы легко можете адаптировать этот скрипт (который log_viewer.py), чтобы он работал на локальной машине: ремуем все, что связано с SSH и просто открываем log-файл непосредственно на малинке. Дальнейший фрагмент скрипта (разбор файла и построение графиков) - без изменений. Пример в приложении к топику. Я не стал усложнять и "универсализировать" скрипт. Так что если будете читать лог с другим именем - измените имя в команде открытия файла.

Если же с программированием чувствуете себя не очень уверенно, то, посмотреть эти логи, можно просто в Excel-е, или в LibreOffice Calc, или в любой программой построения графиков, способной импортировать данные из текстовых файлов. При импорте данный нужно указать разделитель - пробел и поставить флажок типа "Объединять разделители".

Сама идея неверна.lesbeg, 16 Авг. 17, 13:09

В принципе, любую задачу можно усложнить до бесконечности и заставить весь мир крутиться вокруг нее. :) Но, слава Богу, в данной задаче такие сложности излишни. Процессы не быстрые: один такт (включающий в себя, помимо всего остального, вывод строки лога) длится строго 4.8 сек (0.08 мин). Все последовательно, в одном потоке. Естественно, после формирования и вывода каждой строки лога производится принудительный сброс (вывод) буфера (flush). Никаких проблем (типа задержек, пропаданий и т.п.) с отслеживанием лога в реальном времени ни разу не наблюдалось. Кстати, реальное время тоже пишется в лог. Так что проверить несложно.

А что, разве никто не заметил косяк в схеме клапана отбора? Решил его (клапан) откалибровать и выяснилось, что схема не работает. MOC3083 нагрузку включает, а выключить не может. Дело не в индуктивной нагрузке, со слабенькой лампочкой тоже самое.gol_avto, 16 Авг. 17, 09:30

Это не косяк. МОСька без дополнительного симистора довольно часто используется для коммутации небольших нагрузок. Не видно физических причин, по которым она не может это делать. Возможно, разработчик этого чипа не может гарантировать его надежную работу на любые типы нагрузок. Поэтому и вводит такие ограничения. Но, например, клапан AR-HX-3 MSQ с катушкой на 220В у меня стабильно щелкает уже почти год. Еще одно устройство (контроллер) тоже в начале лета погонял две полных ректификации. Тоже очень стабильно работал. Так что ищите причину в чем-то другом. Скорее всего - перегруз. Тогда, конечно, Вам поможет только внешний симистор. :)

Начну с контроллера ТЭНа с функцией контроля нуля.BogAD, 15 Авг. 17, 17:40

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

1. Есть ли смысл подключать детектор нуля (там на входе - цепи с сопротивлением 200кОм и 660 кОм) после предохранителя на 10А? Только для защиты диодного моста? В остальных случаях предохранитель не сработает.
2. Имеет ли смысл ставить защиту (диод VD4), если подключение к цепи питания будет произведено всего лишь раз. На весь срок эксплуатации устройства.
3. Про кнопки. Тут уже дело вкуса. Как показывает опыт, кнопки без дополнительных конденсаторов и собственными МК-шными подтягивающими резисторами в лабораторных/домашних условиях работают достаточно надежно. Конечно же вреда от емкостей и внешних подтягивающих резисторов никакого нет. Хотя, ИМХО, это избыточные элементы. Но, если планируется использовать установку в условиях сильных помех, то, конечно, они повысят надежность системы.

Теперь по поводу предохранителя на 10А. ТЭН в данной установке подавляющую часть времени работает на 30-40% от полного "накала". Поэтому вероятность выхода его из строя (в варианте КЗ) довольно мала. Тем не менее, она, увы, отлична от нуля. Именно на этот случай там и поставлен предохранитель. Он должен спасти в первую очередь проводку и, возможно, симистор. Ставить там автомат смысла нет - подавляющая часть трудозатрат на ремонт будет связана с заменой ТЭНа, а не предохранителя.

Может стоит "замутить" схему контроля целостности цепи нагрева ТЭНа в целом?BogAD, 15 Авг. 17, 21:04

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

---

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

В принципе, любую задачу можно усложнить до бесконечности и заставить весь мир крутиться вокруг нее. Но, слава Богу, в данной задаче такие сложности излишниOldBean, 16 Авг. 17, 19:15

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

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

Есть смысл отталкиваться от того, что твой процесс может быть убит в любое время и беда придет извне (близкое знакомство OOM killer или итог гонки условий (raise condition) на ресурс проверка доступности которого не атомарна или присвоение тебе pid, ранее принадлежавший аварийно упавшему демону не удалившему .pid-файл который никогда оным не лочился ... доостроить сценарий сможешь сам).

Сергей, ты путаешь сложность и overhead.lesbeg, 16 Авг. 17, 22:07

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

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

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

---

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

Для всего этого "добра" предусмотрен (пока мысленно) третий уровень иерархии. Максимум, что будет позволено малинке в этом случае - сбрасывать лог в облако и читать что-нибудь (команды) оттуда.OldBean, 17 Авг. 17, 04:50

Я уже представил красивый GUI на ноуте . Придется покупать планшет, роутер и интернет на дачу. Да.., автоматика не "кислая" вырисовывается...

Придется покупать планшет, роутер и интернет на дачу.gol_avto, 17 Авг. 17, 08:17

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

Для всего этого "добра" предусмотрен (пока мысленно) третий уровень иерархии.OldBean, 17 Авг. 17, 04:50

Угу, нормальная такая СКАДА вырисовывается. 

Не дает мне покоя плавкий предохранитель на 10А, что на плате контроллера ТЭНа...
Сколь не искал, держатели на плату под предохранитель 5х20 на ток номинально не более 6,3А. Вот не доверяю я таким держателям, не держат они большой ток. До 4 А еще туды-сюды, а вот больше...
Самое главное, подведут в самый неподходящий момент.
Предлагаю заменить плавкий 10А на Автомат защиты YA-0702Х, 10 А, 250 В. Даже в самом не демократичном Чип и Дипе по 110р.
Размер почти как стандартный держатель предохранителя.

Не дает мне покоя плавкий предохранитель на 10А, что на плате контроллера ТЭНа...BogAD, 20 Авг. 17, 17:28

Типовые режимы работы установки такие:

1. Разгон (порядка 1500Вт) - ток 6-7А - 20-40 мин в зависимости от навалки
2. Рабочий режим (порядка 600Вт) - ток 2.5-3А - часы, десятки часов

СтОит ли мучиться и переживать из-за такой мелочи, как предохранитель? В ректификации полно других, куда более серьезных, проблем... :)

---

PS
Если смущает держатель, кто мешает просто впаять предохранитель в плату?

Ни одна проблема ректификации, дистилляции и т.п. по своей важности не может сравниться с проблемой безопасности. Пренебрежение "мелочами" может стоить потери имущества, здоровья, а то и жизни.sevpro, 21 Авг. 17, 09:12

Ну кто же с этим спорит!? Но слово "мелочь" я употребил совсем не потому, что этот элемент (плавкий предохранитель) не важен. А потому, что время, которое нужно потратить на размышления о предохранителе, ИМХО, должно быть пренебрежимо мало по сравнению с суммарным временем, потраченным на весь проект. :)

---

Хорошо. Давайте потратим на эту мелочь чуть больше времени. Рассмотрим вариант выхода из строя силовой части (ТЭН и симистор). Имеют право сдохнуть... Одновременный выход из строя автоматики здесь не рассматриваем. Т.е. сдыхает только силовая часть. Варианты:

1. ТЭН перегорел (т.е. разрыв). Нагрев тихо выключится сам :). Автоматика может отследить этот факт по температурам. Да и оператор услышит, что характерный шум кипения исчез.
2. ТЭН уменьшил сопротивление (ну а в предельном случае - КЗ).
Я в жизни видел много взорвавшихся MOSFETов и IGBTэшек(с вывороченными "потрошками" :)) Но с симисторами мне почему-то всегда везло - даже не знаю как они выходят из строя, на практике. Поэтому рассмотрим (теоретически) четыре варианта. Итак, заметно уменьшилось сопротивление ТЭНа или совсем КЗ. Варианты:
  2.1. Симистор еще "тянет" нагрузку и rms тока не превышает порог срабатывания плавкого предохранителя (10А). Колонна выйдет из режима, температуры в колонне и дефлегматоре превысят все мыслимые пороги - автоматика выключит установку. У меня, конкретно, этот вариант окончания работы в скрипте не предусмотрен, но его очень легко добавить.
  2.2. Если симистор еще "тянет" нагрузку, но rms тока превысил 10А - сработает предохранитель. Цепь размыкается - переходим к варианту 1.
  2.3. Симистор сгорает (т.е. цепь размыкается). Увы, симистор выполнил роль предохранителя, но это не смертельно - опять переходим к варианту 1.
  2.4. Симистор не закрывается - "сдох на замыкание". В этом случае срабатывает плавкий предохранитель (или автомат сети, если он слабее). Сеть спасена!

Еще есть варианты?

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