Если либа этого не поддерживает, пользуйтесь нормальной или напишите сами.sevpro, 16 Янв. 17, 12:06
Увы, я не настолько силён в программировании, чтобы самому писать библиотеки. А из нормальных нашёл только owfs, только этот пакет сам использует w1_therm при подключении 1-wire через GPIO4. Может подскажешь ещё какие нормальные?
OldBean
Доцент
Красноярск
1K 1.4K
Отв.81 16 Янв. 17, 16:15
Самому стало интересно...
Вот очень простое решение этой проблемы - параллельный запуск датчиков в фоне. Ниже пример: два bash-скрипта. В первом скрипте датчики запускаются как обычно (последовательно), во втором - параллельно в фоне. В первом случае обработка четырех датчиков идет 3.381 сек, а во втором - секунда! Т.е. во втором случае циклы преобразования в датчиках происходят практически параллельно. Таким образом модуль w1_therm вполне можно обмануть.
У меня датчики температуры читаются паралельно. Обработку писал самостоятельно.Пока только два датчика стоит, но при желании их можно увеличить.Это все на АVRke.
OldBean
Доцент
Красноярск
1K 1.4K
Отв.83 17 Янв. 17, 03:04
Это все на АVRke.terminal, 17 Янв. 17, 01:00
На AVRke такой проблемы нет. А в малике обслуживание 1-Wire берет на себя операционная система (модули ядра w1_gpio и w1_therm). Это очень удобно - работа с шиной становится очень простой и единообразной из любого приложения, но разработчики немного не "дотянули" модули: пока нет возможности регулировать точность (время) преобразования и параллельный запуск датчиков. Вот поэтому и приходится иногда чуток "поплясать", если такие опции нужны. Это - плата за удобство. :)))
Да. Слишком интенсивно долбить DS-ки, конечно, не стОит. К счастью у нас датчики не на воздухе и тепловой контакт со средой должен быть "крепкий". Не перегреются. Нужно будет как-нибудь на досуге поглядеть в datasheet - посмотреть сколько они кушают во время преобразования. Тогда можно будет оценить погрешность, которую могут внести датчики за счет собственного нагрева. Но, скорее всего, мелочь какая-нибудь будет. На практике (у себя, частота опроса меньше-порядка 3 сек) какого-то заметного дрейфа температуры при неизменных внешних условиях я ни разу не замечал.
terminal
Бакалавр
Челябинск
88 7
Отв.86 17 Янв. 17, 05:55, через 13 мин
К счастью у нас датчики не на воздухеOldBean, 17 Янв. 17, 05:42
пока не забыл, а почему нет датчика воздуха? По идее колонна отдает тепло при разных температурах воздуха по разному. Кто что думает по этому?
OldBean
Доцент
Красноярск
1K 1.4K
Отв.87 17 Янв. 17, 05:59, через 5 мин
пока не забыл, а почему нет датчика воздуха?terminal, 17 Янв. 17, 05:55
Почему нет? Есть. Датчик BMP180 кроме атмосферного давления выдает еще и температуру там где он стоит.
terminal
Бакалавр
Челябинск
88 7
Отв.88 17 Янв. 17, 06:02, через 3 мин
На ведомых (slave) устройствах никаких подтягивающих резисторов ставить не нужно (!).OldBean, 16 Янв. 17, 02:59
обязательно предупреждайте что 5 Вольтовыми напряхжениями можно сжечь 'малинку'. А то я по началу бросился писать прогу под Ваш модуль а потом понял что в случае какой либо ошибки могу пожечь чужую малинку. Почитал форумы,там пишут что жгут порты малинки 5 Вольтовыми блоками.
OldBean
Доцент
Красноярск
1K 1.4K
Отв.89 17 Янв. 17, 06:19, через 17 мин
Да всего, что можно "утворить" с малинкой и 5-вольтовой периферией и не предусмотришь. С ведомым 5-вольтовым устройством на I2C никаких проблем нет. Вряд-ли кто-нибудь "по запарке" поставит дополнительные подтягивающие (да еще и маленькие) резисторы к 5 вольтам. Главное - на обычные выводы малинки не плюхнуть что-нибудь активное 5-вольтовое! Но про это вроде везде и много написано.
OldBean
Доцент
Красноярск
1K 1.4K
Отв.90 19 Янв. 17, 05:50
10.2. Классы-обертки для контроллеров (исполнительных устройств) - модуль contr
В модуле contr (файл contr.py)находятся два класса для контроллеров ТЭНа (класс TEH) и клапана отбора (класс SD). Классы-обертки пока реализованы в самых простейших вариантах (нет контроля и обработки исключений), но они уже существенно упрощают написание скриптов автоматизации и работают достаточно корректно. Поэтому пока остановимся на этих вариантах чтобы двигаться дальше. Наклеивать на них "жирок" буду в "рабочем порядке" :)))
Модуль contr вместе с модулем sens должны находиться в той же директории, в которой мы работаем. Или в любой директории из тех в которых python ищет модули (см.соответствующие системные переменные). Модуль достаточно подробно прокомментирован. В конце модуля приложен тест, в котором можно видеть примеры использования классов и изменения свойств объектов (ТЭН, клапан отбора). Скриншот сессии с тестированием классов (с комментариями) показан на рисунке ниже. Ненавязчивая автоматизация ректификационной установки. Автоматика.
Дополнительно, в приложении к топику, есть архив test.zip в котором находится более сложный тестовый пример для оценки динамических характеристик контроллера ТЭНа и датчика RMS. Модуль kbh (файл kbh.py) нужен для реализации функции kbhit() при работе с консолью. Этот файл тоже должен находится в той же папке, где находится запускаемый скрипт test.py и модули contr и sens.
Запустив скрипт test.py, мы сможем управлять мощностью ТЭНа при помощи цифровых клавиш (завершение работы - q). При нажатии на клавиши 0, 1, 2 ... 8, ТЭН будет греть с мощностью, соответственно, 0, 100, 200 ... 800 Вт. А при нажатии но 9 - с максимально возможной мощностью (100% на контроллере). На рисунке ниже показан график зависимости мощности нагрева куба от времени, который построен по результатам, выводимым скриптом на консоль. Ненавязчивая автоматизация ректификационной установки. Автоматика. Мы видим, что выбросы при переключении мощности (даже в самом жестком режиме - мгновенное переключение мощности от нуля до максимальной (100%)) не превышают 5% по амплитуде и 1 сек по длительности. Так что, работать можно.
Все. Подготовительный этап мы закончили. Все что нам нужно для автоматической ректификации мы построили, спаяли и наладили. Классы-обертки тоже готовы. Можно переходить к написанию скриптов автоматизации уже вполне реальных процессов ректификации.
Скрипты автоматизации, которые я использовал раньше (для этой установки), достаточно аскетичны, написаны без классов-оберток, "разношерстно", по мере строительства установки. Для пользователей, привыкших к GUI, они могут показаться очень непривычными. Поэтому я их не буду публиковать. Все равно собирался переписать все "начисто". В связи с этим, все дальнейшее будет своеобразным "программированием on-line" :))). Сначала обсудим варианты UI. Затем напишем скрипт простейшего процесса ректификации: 1) разгон, 2) головы по времени или объему, 3) подголовники - по объему, 4) тело - до начала активного "старт-стопа" по температуре в нижней части колонны (или по дельте), 5) хвосты - до начала заметного роста температуры перед дефлегматором, 6) выжимание всей оставшейся дряни и 7) завершение - "пропарка" колонны. Пара ведер сахарного сырца с того года еще осталась - на нем и поработаем. Ну а потом, после окончательной отладки софта на этом варианте, наконец-то перейдем к "творческой части" этого проекта :)))
Обновление некоторых модулей и скетчей
В приложении к данному топику находится новая версия модуля sens (файл sens.py) с небольшими косметическими правками и скетч для датчика RMS (файл rms_17.01.18.ino) в котором исправлен маленький (но не критичный) "косячок": при отсутствии напряжения в сети (или меньше 100 В) контроллер отправлял по шине I2C неправильное (отрицательное, обрезанное до uint8_t) значение напряжения.
Добавлено 23.01.2017: А обновление модуля contr от 23.01.2017 в приложении к этому топику.
Добавлено 26.01.2017: Новое обновление модуля sens от 26.01.2017 здесь.
Добавлено 27.01.2017: Новое обновление модуля contr от 27.01.2017 здесь ==========================================
В сеттеры вставлена обработка исключений (IOError). Теперь функционал классов-оберток для контроллеров исполнительных устройств (контроллер ТЭНа и контроллер клапана отбора) полностью готов.
======================================== Добавление от 27.01.2017
Это просто немного развернутое пояснение почему выбрано именно такое, а не другое решение, связанное с пользовательским интерфейсом.
Взаимодействие с компьютером при помощи командной строки (консоли) - это общение на человеческом языке. Хотя и - предельно упрощенном и формализованном. Но это, все-таки - речь. Пока, как правило, письменная. При помощи одного и того же (единого!) интерфейса (консоль и командная строка) можно попросить компьютер сделать абсолютно все, что он в принципе умеет делать. А вот графический интерфейс (в том числе и web) - это, по сути, "язык жестов". Он примитивен и поэтому, как правило, очень прост для конечного пользователя. Кнопка "Дай" и выбор из выпадающего списка "Пожрать" :))) Из всего многообразия, что может делать компьютер, в графическом интерфейсе доступно лишь относительно небольшое подмножество функционала, определяемое разрабатываемым приложением. Поэтому разработка хорошего графического интерфейса требует хорошего знания всего функционала приложения и всех нюансов работы с ним. Причем сразу. Но главная проблема здесь даже не в этом. Она в психологии, привычках и традициях конечного пользователя. Которые очень разные.
Здесь (на этом форуме) довольно много людей старшего возраста. И наверняка многие из них, включив какой-нибудь новый гаджет, сталкивались с удивительной проблемой - "Ну ни хрена непонятно!!! Что, куда и к чему?". А вот юный сын или внучок быстрыми шаловливыми ручками моментально настроит "тупому деду" его гаджет. А ведь на самом деле - все наоборот. Это я насчет "тупизны". Повсеместное засилье GUI, в последнюю пару десятилетий (не только в ПК, но и абсолютно во всех других сферах жизни!), резко сужает многовариантность принятия решений и формулирования заданий. Особенно у младших поколений (я тут уже и не буду даже вспоминать про дебилизм ЕГЭ, основанный на простейших тестах на выбор из нескольких вариантов). По сути воспитывается упрощенный, потребительский подход к окружающему миру и совершенно "перпендикулярная" ему логика.
Ладно, предыдущий абзац - это просто грустная иллюстрация и отступление :((( Вернемся к интерфейсам. Итак, GUI существенно ограничивает вариантность принятия решения. Поэтому работа с хорошим GUI легка и приятна. Но как быть если вариантов работы много. Или очень много. Или разработчику (заранее) известны не все? В этом случае GUI может превратить приложение в натурального монстра, изучение и освоение которого может занять месяцы и даже годы. Возьмите любую более-менее развитую CAD-систему. Например, какую-нибудь хорошую "чертилку" для инженеров-конструкторов. Это же тихий ужас! Многоуровневые, вложенные меню и инструментальные панели, огромное количество диалоговых окон. В результате появляются двойные-тройные сочетания горячих клавиш (да еще и вместе с клавишами мыши!). А ведь по сути это - завуалированная форма команд, которые проще было бы набрать в той же консоли, причем, гораздо более "дружественными" словами :)))) Может кто-нибудь еще помнит первые версии AutoCAD с командным интерфейсом?
Я совсем не хочу сказать, что программа управления ректификационной установкой сравнима по сложности с CAD-системой. Конечно, она несравненно проще. Но, поскольку я еще не знаю какие алгоритмы автоматизации захочется реализовать на этой установке в будущем, разработка хорошего GUI может вылиться в серьезную проблему. Понадобится достаточно универсальный интерфейс, который автоматически и неуклонно начнет дрейфовать в сторону CAD-систем химико-технологического профиля :))) К сожалению, у меня нет столько времени. Да и области интересов лежат далеко в стороне от разработок UI. А плохой GUI - это гораздо хуже, чем вообще его отсутствие. Потому что делает пользователя беспомощным и "привязанным" к прихотям разработчика GUI. Здесь я, естественно, предполагаю, что само приложение (без UI) сделано нормально, универсально и включает в себя весь функционал, необходимый для решения заданного круга прикладных задач. И, естественно, у приложения есть развитый программный интерфейс, который дает возможность воспользоваться всем этим функционалом.
Именно поэтому в этой работе я склоняюсь в сторону универсальности командной строки. Чтобы все усилия можно было бы сосредоточить на функциональности самого приложения и его программном интерфейсе. А для конкретных и отработанных алгоритмов ректификации "рюшечки" (т.е. GUI) легко будет сделать потом (особенно - на уровне каких-нибудь мнемосхем).
плохой GUI - это гораздо хуже, чем вообще его отсутствиеOldBean, 23 Янв. 17, 09:02
В этом случае будет вполне оправданным дать API методы к своей системе, а GUI уже можно будет прикрутить исходя из личных предпочтений
OldBean
Доцент
Красноярск
1K 1.4K
Отв.94 24 Янв. 17, 02:47
В этом случае будет вполне оправданным дать API методыmax506, 23 Янв. 17, 23:44
Об этом и речь. API - это и есть программный интерфейс.
OldBean
Доцент
Красноярск
1K 1.4K
Отв.95 26 Янв. 17, 05:22
Обновление модуля sens
Модуль sens существенно переработан и добавлен новый функционал. Дошли руки, наконец... Интерфейс со старой версий по возможности сохранен. В модуль внесены следующие изменения:
1. Сделана документация классов 2. Во все классы вставлена предварительная (еще до создания объекта) проверка наличия и работоспособности соответствующего датчика. При положительном результате проверки создается объект-датчик, а при отрицательном - None. 3. Внесены небольшие косметические правки по тексту модуля 4. Наиболее существенные изменения сделаны в классе-обертке датчика DS18B20. Расширен функционал для коллективной работы с датчиками, "висящими" на шине 1-Wire. В частности, добавлен статический метод класса DS18B20.Ts(). Этот метод возвращает словарь, содержащий идентификаторы всех подключенных датчиков и соответствующие им температуры {id_датчика : температура}. При вызове метода Ts() циклы преобразования всех датчиков запускаются в параллельных потоках, поэтому полное (суммарное) время получения температур всех датчиков существенно сокращается. Например, для 4-х датчиков DS18B20 время преобразования составляет порядка 1 секунды. Пример использования статического метода Ts() (фрагмент из блока тестирования модуля sens):
print "\nПараллельный запуск %d датчиков" % (nts) st = time.time() d = DS18B20.Ts() # Метод Ts() возвращает словарь с id датчиков (ключи) и # температурой (значения) for id in d.keys(): print "0x%012x :% 7.3f°C" % (id, d[id]) print "%5.3f сек" % (time.time() - st)
Новое обновление модуля sens здесь. Исправлена реализация многопоточного преобразования температурных датчиков DS18B20. "Глюк" проявился на новых малинках (Raspberry Pi 3 model B).
Ну вот, вчера заодно и "причесал" модуль contr с классами-обертками для контроллеров исполнительных устройств (ТЭНа и клапана отбора) и немного расширил их функционал. В модуль внесены следующие изменения:
1. Сделана документация классов 2. Во все классы вставлена предварительная (еще до создания объекта) проверка наличия и работоспособности соответствующего датчика. При положительно результате проверки создается объект-датчик, при отрицательном переменная объекта равна None. 3. В деструкторы классов добавлено выключение ТЭНа и клапана отбора, соответственно. 4. В класс-обертку контроллера клапана отбора (класс SD) добавлен счетчик общего расхода (свойство F) и метод FZ() для сброса этого счетчика. По-хорошему, счетчик расхода нужно было бы реализовывать на самом контроллере клапана отбора. Тогда счетчиком можно было бы пользоваться и в ручном режиме. Сделаем это в будущих версиях. Пока же счетчик расхода реализован в упрощенном варианте - на управляющем микрокомпьютере (малинке). При реализации режимов контроля отбора по объему фракций - опция очень удобная.
Примечание. К сожалению, пришлось немного изменить интерфейс конструктора класса-обертки контроллера ТЭНа: вместо адреса датчика RMS на шине I2C сейчас необходимо передавать сам объект-датчик RMS. Но так гораздо удобнее, да и логика "выпрямилась" и стала единообразной (по всем классам, в модуле sens - тоже). Значение параметра по умолчанию - None.
Итак, все подготовительные операции выполнены. Пора переходить к испытаниям нового софта в реальных, "боевых" условиях. У меня с прошлого года в кубе ректификационной установки остался недоректифицированный сырец. Это хвосты, в которых было еще литра полтора АС. Надо бы их вытащить - пойдут в "переплавку". Это как раз был хороший повод протестировать новый софт.
Задача упрощается - не нужно отбирать головы и тело (это было сделано еще в том году). Поэтому скрипт управления установкой получился несложным. Немаловажную роль в упрощении и компактности кода сыграла и инкапсуляция многих деталей в классах-обертках датчиков и контроллеров. Правда и сама задача "подчистки хвостов" несложная. Автоматическое переключение режима сделано только для перехода из режима разгона колонны в режим работы "на себя" (чтобы не караулить). А остальные переходы (в режим отбора хвостов и в режим "пропарки колонны") делаются вручную путем нажатия клавиши, соответствующей номеру нужного режима. Это совсем и не хлопотно - все равно приемные емкости менять приходится пока вручную.
Скрипт написан, естественно, на питоне. Архив со скриптом находится в приложении к топику (файл nna_02.py). Кратко - логика скрипта. В начале скрипта производится создание объектов системы (датчиков и контроллеров). Параллельно производится проверка наличия реальных устройств на шинах и их работоспособности. Далее формируется "карта режимов", используемых в данном процессе и настраиваются необходимые рабочие переменные. Далее идет возня с открытием файла журнала для протоколирования всего процесса ("черный ящик" показаний всех датчиков), система переводится в режим 0 (чистый мониторинг параметров) и начинается глобальный общий цикл приложения. В цикле производится опрос клавиатуры (вдруг оператор захочет что-нибудь сказать системе), опрос всех датчиков, вывод информации на консоль, в файл журнала и, собственно, само управление - поддержание текущих режимов и переключение на другие режимы работы.
Поскольку данный скрипт является своеобразным прототипом всех дальнейших скриптов, которые будут использоваться в ненавязчивой автоматизации, то каждый фрагмент его мы рассмотрим достаточно подробно, но чуть позже. А пока - о результатах испытаний.
Испытания были проведены вчера (в пятницу) и, можно сказать, что они прошли вполне успешно. Волею судьбы они были разбиты на два этапа. После первого этапа (разгон, выход колонны на стационарный режим и останов) были исправлены небольшие "косячки" в скрипте. Во втором этапе испытаний был, естественно, повторен первый этап (колонна к тому времени уже поостыла) и затем последовали: отбор исправимых хвостов, отбор неисправимых хвостов и пропарка колонны. Каких-то сбоев и дополнительных "косяков" не было - все отработало красиво, спокойно и достойно, как часы. Карта режимов была составлена так, чтобы в колонне устанавливался пленочный режим работы. Перепад давления на колонне - от 40 до 60 мм водяного столба. Никаких захлебов и прочих чудес в колонне не создавалось.
13.1. Первый этап испытаний - запуск колонны.
На рисунке ниже приведен лог первого этапа испытаний. Тем, кто занимаются ректификацией много лет это, все это, конечно, знакомо и совсем неинтересно. Остаток поста можно пропустить. Но для новичков, разобрать поподробнее этот график, возможно, будет интересно (мне, например, поначалу смотреть на логи моих первых "компьютеризированных" ректификаций было очень интересно :))). Ненавязчивая автоматизация ректификационной установки. Автоматика. Итак, из-за "косячка" в карте режимов (написал 400 Вт вместо 600) выход колонны на стационарный режим оказался "растянутым" во времени. В результате на графиках мы можем отчетливо видеть все основные этапы запуска колонны. Они пронумерованы цифрами над графиками. На графике представлены зависимости температур в трех точках установки от времени. Синяя диаграмма соответствует температуре в кубе, красная - в нижней части колонны (приблизительно на 1/3 высоты), а зеленая - на входе в дефлегматор. Рассмотрим теперь перечисленные на диаграмме этапы запуска колонны по порядку.
1-й этап. Ничего особенного - просто нагрев на максимальной мощности. Температура жидкости в кубе линейно нарастает. Температура в колонне не меняется, а температура в дефлегматоре чуть-чуть понижается из-за остывания дефлегматора после включения воды охлаждения и постепенного понижения температуры самой воды в водопроводе.
2-й этап. В начале второго этапа произошло закипание содержимого в кубе. Об этом говорит излом на синем графике. Если бы объемом ("емкостью") колонны можно было бы пренебречь (по сравнению с объемом куба), то дальше синяя кривая должна была бы превратиться в горизонтальную прямую (напомню, что никакого отбора на этих этапах еще нет). Но, колонна имеет конечный объем. Поэтому на синей диаграмме после точки излома наблюдается небольшой рост, обусловленный тем, что часть легко летучей фракции (спирт в нашем случае) удерживается в колонне в виде пара и флегмы. Кстати, по разности между температурой в стационарном режиме (5) и температурой в точке излома (на границе 1 и 2) можно оценить "емкость" (удерживающую способность насадки) колонны. Т.е. - сколько жидкости (флегмы) и пара в ней может удержаться. Для этого нужно знать еще и объем жидкости в кубе. К сожалению, я его уже не помню (а косвенно, не вскрывая куба, его оценивать тоже хлопотно), поэтому эту оценку пропускаем.
В начале второго этапа на красном графике наблюдается небольшая "полочка" (в это время пар просто "свистит" вверх) с последующим постепенным ростом температуры. Рост вызван двумя основными факторами. Во-первых, начинает прогреваться насадка и стенка колонны. Во-вторых, часть пара начинает конденсироваться на насадке и начинает слегка "запирать" пар, идущий снизу. Скорость пара снижается и он начинает прогревать насадку интенсивнее. Этот процесс заканчивается, когда температура нижней части колонны почти сравнивается с температурой куба. В данном случае этот момент практически совпал с моментом, когда пар достиг дефлегматора (на границе этапов 2 и 3), но в общем случае это может произойти в разное время.
3-й этап. Начало 3-го этапа характеризуется тем, что пар наконец-то достигает дефлегматора. Это видно по резкому росту зеленой кривой (температура на входе в дефлегматор). Начинается интенсивное образование флегмы, которая, в свою очередь, начинает стекать по насадке вниз. И вот, к конце 3-го этапа эта флегма наконец-то достигает нижней части колонны, где установлен датчик. Температура этого участка колонны начинает падать.
4-й этап. Фронт флегмы проходит дальше вниз по направлению к кубу, колонна постепенно остывает и, к концу 4-го этапа, колонна выходит на стационарное состояние.
5-й этап. В стационарном состоянии градиент температуры в колонне становится мал, потоки пара вверх уравниваются с потоками флегмы вниз, значения температур стабилизируются. В колонне устанавливается ЛТР (локальное термодинамическое равновесие), когда на каждом срезе колонны флегма находится в термодинамическом равновесии с паром и насадкой. Для пленочного режима - это хорошее приближение. Все. На этом этапе уже можно начинать отбор.
К сожалению, на этот момент я уже заметил несколько "косячков" в свеженаписанном скрипте и остановил процесс, чтобы их исправить.
13.2. Второй этап испытаний - отбор хвостов и пропарка колонны
Ну что же, продолжим "чукотскую песню" :)))
После исправления косячков, начался второй этап испытаний (тестируется работа клапана отбора, подсчет расхода, переключение режимов и т.п.). А в качестве бонуса - еще литр спирта с "исправимыми" хвостами и система, очищенная от прошлогодней дряни. На рисунке ниже приведен лог второго этапа испытаний. Смысл трех кривых (синей, краной и зеленой) тот же, что и раньше. Это температуры. Добавлена еще одна кривая (коричневая). Это расход клапана отбора. Т.е. полное количество отобранного клапаном спирта (свойство F объекта-контроллера клапана отбора, считается автоматически). Шкала отбора в мл. - на диаграмме справа. Ненавязчивая автоматизация ректификационной установки. Автоматика. 1-5 этапы. Эти этапы мы уже подробно рассмотрели в предыдущем топике. В карте режимов рабочая мощность была исправлена на 600 Вт, поэтому вейвлет (всплеск :) на кривой температуры внизу колонны сократился до 6-7 минут.
6-й этап. После выхода колонны на стационар, нажатием на клавишу "5" система была переведена в режим отбора хвостов, который продолжался около 2.5 часов. Спирта в кубе становится все меньше и меньше, температура кипения, по мере отбора спирта, растет (синяя кривая). Но колонна в целом еще исправно выполняет свою "укрепляющую миссию" - температура на входе в дефлегматор стоит мертво (зеленая кривая).
Наконец, где-то на 110-й минуте заметно ускоряется рост температуры датчика в нижней части колонны (красная кривая). Это говорит о том, что при данной спиртуозности раствора в кубе, разделяющей способности нижней части колонны (до датчика) уже недостаточно для полного отделения азеотропа. Другими словами - количество теоретических тарелок нижней части колонны уже недостаточно для их разделения. Или, еще другими словами, - верхняя граница укрепляющей части колонны ушла выше точки, где расположен датчик.
На 165-ой минуте температура датчика в нижней части колонны сравнивается с температурой куба, но температура на входе в дефлегматор еще держится на уровне температуры кипения спирта (точнее - азеотропа). Это говорит о том, что нижняя граница укрепляющей части колонны "оторвалась" от куба и все эти "укрепляющие теоретические тарелки" :))) дружно и неуклонно ползут вверх по колонне и скоро достигнут дефлегматора. На моей колонне этот "марш укрепляющих тарелок" обычно продолжается порядка 15-20 минут. Вот, наконец, приблизительно на 180-й минуте начинается рост температуры на входе в дефлегматор. Все. "Укрепляющие тарелки домаршеровали" до дефлегматора. Этап исправимых голов закончился - больше азеотропа "капать" не будет - пора менять приемную емкость с хвостами на ведро, которое потом будет вылито в канализацию.
7-й этап. Здесь в штатном режиме нагрева и отбора отбираются неисправимые головы, которые уже не имеет смысла возвращать в переработку. По характеру зеленой кривой между 190 и 210 минутами мы видим, что состав тяжелых фракций (помимо воды) неоднороден. В данной ректификации хорошо выделились (на фоне воды) две тяжелые фракции с температурами кипения около 85°C и около 92-93°C.
Наконец, температуры всех трех датчиков сравниваются. Процесс кубовой ректификации доведен до конца.
8-й этап. После 130 минуты ключаем режим "пропарки" колонны. Мощность - 100%, отбор - 100% и выгоняем всю оставшуюся дрянь из системы. Температура всех трех датчиков - 100°C, атмосферное давление 757 мм.рт.ст. Так что по колонне "шурует" уже чистый водяной пар. "Отжимаем" с пол-литра воды и выключаем режим пропарки.
9-й этап. Это просто тестирование софта. Переходим в режим работы "на себя" (mode = 2). Отбор выключился. Затем переходим в режим мониторинга (mode = 0) и выключаем ТЭН. Смотрим немножко как система охлаждается. И... "завязываем" с этим делом.
Все. Тестирование нового софта в "боевых" условиях успешно закончено.
Неровности перехода температурных графиков колонны между 140 и 160 минутой и дефлегматора между 190 и 210 минутой ты связываешь со сменой фракций? Можешь изложить подробнее, как ты думаешь, что происходит на этих переходах?
У меня такой же неровный переход получается, я грешил на захлёб.
Отв.82 17 Янв. 17, 01:00
