Форум самогонщиков Сайт Барахолка Магазин Помощь солдатам

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

Форум самогонщиков Автоматика
1 ... 95 96 97 98 99 100 101 ... 132 98
sig Кандидат наук Ростов-на-Дону 304 138
Отв.1940  06 Апр. 20, 17:07
Все это видно в сгенерированных c помощью conv.py файлах uscr.py. Сравните сформированый старым конвертером и новым.ekochnev, 06 Апр. 20, 16:28

Посмотрел код нового conv.py - стало яснее! Вы меня и Сергея слегка ввели в заблуждение - это не использование api.vget() & api.vset()! (за что вас стал ругать Сергей, как за нарушение концепта). Это вполне разумная оптимизация - свертка повторяющихся фрагментов в функцию - просто имя немного неудачное (vget-vset)
ekochnev Магистр Екатеринбург 207 54
Отв.1941  06 Апр. 20, 17:12, через 6 мин
Имена как раз специально сделал такие же как в api. Потому что суть выполняемых действий именно та же что в api. И даже формат обращения точно такой же. Просто из скрипта нет доступа чтобы напрямую использовать api.vget и api.vset (если конечно не использовать импорт, который Сергей также не рекомендует). Поэтому и появились функции-дублеры с таким же именем как в api. Ну а получившаяся оптимизация многократного копипаста внутреннего кода - это побочный эффект... :-)

У меня вообще сложилось впечатление, что Сергей отвечая мне многобуквенной статьей при этом даже не смотрел те изменения что я внес. Он утверждает, что это некий новый функционал, а я лишь причесал его же код и слегка оптимизировал. Сергей, извините что сейчас в третьем лице о Вас говорю, просто по другому не знаю как объяснить
sig Кандидат наук Ростов-на-Дону 304 138
Отв.1942  06 Апр. 20, 17:22, через 10 мин
Не открывается ссылка не с телефона не с компаMikrocod, 06 Апр. 20, 16:41
У меня тоже через Билайн не открывается! А что там вы хотите найти? Утилита screen загружается apt-get install screen. Документацию можно почитать тут - https://help.ubuntu.ru/wiki/screen
ekochnev Магистр Екатеринбург 207 54
Отв.1943  06 Апр. 20, 17:30, через 9 мин
Не знаю, зачем нужна была именно эта ссылка. Человек спросил, я ответил :-)
А так действительно, это почти стандартная юниксовая утилита, которая встречается в штатных пакетах почти любого дистрибутива. Но tmux мне все равно нравится больше (он тоже в пакетах есть и документацию на русском в сети найти не проблема)...
sig Кандидат наук Ростов-на-Дону 304 138
Отв.1944  06 Апр. 20, 18:09, через 39 мин
У меня вообще сложилось впечатление, что Сергей отвечая мне многобуквенной статьей при этом даже не смотрел те изменения что я внес.ekochnev, 06 Апр. 20, 17:12
Мне тоже почудилось (на основе предыдущей беседы) что vget('q0') - это в скрипте пользователя используется api.vget(), вот и стал спрашивать полный пример скрипта.
Может быть пора выложить исходники в нормальную систему ведения версий (например, github). Тогда Сергей ведет основную ветку, от нее в любой момент можно ответвиться, изменения можно будет смотреть через браузер и решать, добавлять ли их в основную ветку.
ekochnev Магистр Екатеринбург 207 54
Отв.1945  06 Апр. 20, 18:20, через 12 мин
Вы не первый кто это предлагает...
OldBean Доцент Красноярск 1K 1.4K
Отв.1946  06 Апр. 20, 19:03, через 43 мин
даже не смотрел те изменения что я внес.ekochnev, 06 Апр. 20, 17:12
Да смотрел я. В том-то и дело, что посмотрел. Поэтому-то в конце концов и предложил все эти "редиско-синхронизационно-клиентские дела" пустить в "свободное плавание". Иначе есть риск вместо решения концептуальных вопросов погрязнуть в мелочах типа "свойства vs функции", "T0 vs Tкуб" и т.д. Мне все-таки хотелось бы довести до логического конца поставленную задачу.
Основная проблема именно в отсутствии клиента! Хочется использовать автоматику сейчас - а нечем. Может стоит разбить lsync на собственно синхронизатор и консольный клиент?sig, 06 Апр. 20, 16:35
К сожалению, реальный клиент сильно зависит от решаемой задачи. Поэтому написать универсального клиента, не требующего от пользователя серьезного программирования, не так-то просто. Пока мне пришел в голову только один приемлемый вариант универсального клиента. Этот вариант клиента был реализован и отлаживался в "разобранном" виде. Частично в синхронизаторе, а частично - в пользовательском скрипте. Так было удобнее отлаживать. В одном процессе. Вся эта конструкция была отлажена, причем, что забавно, этот отладочный вариант оказался весьма удобным для рутинных ректификаций. Но, в результате, клиент так и "застрял" в таком разобранном виде. К сожалению, видимо в минуту слабости, я поленился выдернуть эти фрагменты и собрать из них полноценного клиента, а умудрился выложить всю эту "расчлененку" как есть :( Что и привело к куче недоразумений.

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

2Mikrocod
Сервер либо лежит, либо заблокирован. Но по screen прорва информации в Сети на других серверах. Воспользуйтесь гуглом.
Mikrocod Студент Челябинск 43 5
Отв.1947  07 Апр. 20, 05:59
Да, нашел дублирующий сайт.
OldBean Доцент Красноярск 1K 1.4K
Отв.1948  08 Апр. 20, 10:19
Мы слегка увлеклись работой с редиской и пользовательскими скриптами в погоне за предельным упрощением интерфейсов и разработки скриптов управления. В результате библиотека lite.py оказалась в глубокой тени. Причем, совершенно незаслуженно. Ну совсем как бедная Золушка. Тем не менее эта библиотека очень удобна для работы с установкой. Как в "ручном" режиме, так и в автоматическом. Причем, каких-то особо глубоких познаний компьютеров и всяких питонов она не требует...

Думаю, будет полезно показать несколько примеров работы с этой библиотекой. Возможно, ряд вопросов, которые мы недавно обсуждали, покажутся не такими уж актуальными :)

17.10. Библиотека lite v.0.4.x.x
17.10.1. Пример "ручной" работы с установкой

Библиотека lite (файл lite.py) представляет классы-обертки для всех устройств (модулей), используемых в варианте LITE с крейтом. Библиотека содержит некоторые вспомогательные функции, классы. Кроме этого, в библиотеке присутствуют средства для автоматического анализа аппаратной конфигурации. Особенностью версии 0.4.x.x является именование модулей оборудования (контроллеров и датчиков) именами, согласно их физического смысла, и генерирование питоновских объектов с соответствующими именами в процессе импорта библиотеки. После импорта, пользователь получает полный и непосредственный доступ к каждому устройству при помощи методов и свойств этих объектов. Никаких дополнительных средств (типа БД redis, синхронизатора lsync и т.п.) для работы не требуется.

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

screenshot.png
Screenshot. Ненавязчивая автоматизация ректификационной установки. Автоматика.


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

Итак, после соединения с малинкой по ssh и перехода в папку, где находится библиотека lite.py мы запускаем интерпретатор питона. Далее работаем уже в питоновской консоли.

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

Первая колонка - это имена объектов, соответствующие найденным элементам оборудования (контроллеры и датчики). Обращаться к объектам можно непосредственно по этим именам.

Вторая колонка - это, так называемый, hard-ключ, позволяющий пользователю легко идентифицировать конкретные устройства. Первые две цифры - шестнадцатеричный адрес устройства на шине i2c. Вторая цифра - номер канала хаба (от 0 до 7), к которому подключено устройство. Для нехабов - затычка в виде 8. Единственное на данный момент исключение - контроллеры PWM. 0-й канал этих контроллеров интерпретируется как датчик расхода. Это связано с тем, что PWM контроллеры в этой автоматике обычно используются для управления клапанами отбора. Ну и последние две цифры - это шестнадцатеричные коды типа устройства. Их расшифровка представлена в третьей колонке.

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

Итак, со списком обнаруженного оборудования разобрались. Если таблица во время работы уйдет в "глубь веков", ее всегда можно распечатать опять, просто вызвав функцию hinfo().

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

В следующем фрагменте - примеры как получать значения, измеренные датчиками. Для этого к имени объекта добавляется суффикс '.v'. Для питона это означает обращение к свойству v (value) соответствующего объекта. Я пока не знаю как обойтись без такого суффикса, не используя никакого препроцессинга команды. Но, думаю, это не такая большая плата. Даже для непрограммистов :)

Необходимо отметить, что, при обращении к некоторым датчикам, иногда может возникать небольшая пауза (не более 1 сек), вызванная тем, что данные стали неактуальными и необходимо повторно запустить цикл преобразования. Время "актуальности" данных, установленное по умолчанию, равно 5 сек с момента последнего обновления (цикла преобразования). Если необходимо, это значение можно изменить, модифицировав свойство cudtmax датчика или хаба, если датчик подключен к хабу.

Идем дальше. Некоторые товарищи не любят имена с индексами. Типа T1, w0, q0 и т.п. При работе с библиотекой lite есть очень легкий способ использовать более осмысленные имена для своих устройств. Причем, в таких именах можно использовать и русские буквы (в unicode). Пример определения такого имени для датчика атмосферного давления - в следующем фрагменте. Далее это новое имя можно использовать везде. Наряду со старым. Ну, мне кажется, проще уже некуда.

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

Таким образом, мы видим, что "ручное" управление установкой при помощи библиотеки lite, производится очень просто. Даже очень-очень ну совсем просто :)

Файл lite.py версии 0.4.0.0 - в приложении к топику. Библиотека совместима с предыдущей версией.

Предыдущий топик Вернуться к оглавлению Следующий топик
lite.py.zip 10.3 Кб
sig Кандидат наук Ростов-на-Дону 304 138
Отв.1949  08 Апр. 20, 18:07
Для этого к имени объекта добавляется суффикс '.v'. Для питона это означает обращение к свойству v (value) соответствующего объекта. Я пока не знаю как обойтись без такого суффикса, не используя никакого препроцессинга команды.OldBean, 08 Апр. 20, 10:19
Если во всех классах (где есть метод v) определить метод __repr__
def __repr__(self):
 return "Value="+str(self.v)
то вместо T0.v можно писать просто T0 и после нажатия Enter будет выведено текущее значение.
(Это одновременно повлияет и на print( T0 ) т.к. определение __repr__ переопределит и метод __str__).
OldBean Доцент Красноярск 1K 1.4K
Отв.1950  08 Апр. 20, 19:11
Если во всех классах (где есть метод v) определить метод __repr__sig, 08 Апр. 20, 18:07
С репрезентацией вопросов нет. А вот в формулах разве это будет работать? А при присваивании? В смысле - в левой части выражения. Не проверял, но боюсь что нет. Это же для строкового представления объектов.
sig Кандидат наук Ростов-на-Дону 304 138
Отв.1951  08 Апр. 20, 19:51, через 41 мин
С репрезентацией вопросов нет. А вот в формулах разве это будет работать? А при присваивании? В смысле - в левой части выражения. Не проверял, но боюсь что нет. Это же для строкового представления объектов.OldBean, 08 Апр. 20, 19:11
Безусловно - в формулах надо использовать T0.v Это предлагалось для лентяев (типа меня), кому лень набирать Т0.v в командной строке, чтобы посмотреть текущюю температуру.
OldBean Доцент Красноярск 1K 1.4K
Отв.1952  09 Апр. 20, 08:42
17.10.2. Библиотека lite 0.4.0.0. Пример автоматизации

В предыдущем топике мы рассмотрели примеры "ручной" работы с установкой при помощи библиотеки lite. Такой режим удобен для тестирования алгоритмов, отдельных устройств, при калибровке и т.п. Однако в реальных процессах, особенно длительных, необходимо организовать автоматическое выполнение питоновских команд. Для этого нужно записать нужные команды в виде обычного текстового файла и "скормить" этот файл интерпретатору питона. В таком режиме интерпретатор будет выполнять команды автоматически. Последовательно, одну за другой. С учетом ветвлений и циклов.

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

Критерием переключения нагрева на рабочий уровень (конец разгона) будет превышение температуры в царге, скажем, 65°C. Это означает, что жидкость в кубе закипела и по колонне пошла волна горячего пара. Далее, критерием выхода колонны в стационарное состояние будет приблизительное равенство температур пара в царге (датчик - в нижней части колонны) и в дефлегматоре. Равенство будем оценивать с точностью в 1 градус. Обычно, на этапах запуска установки, температура в царге всегда существенно превышает температуру в дефлегматоре. Затем, при выходе колонны на стационар, устанавливается постоянный поток флегмы вниз по колонне и температура в царге плавно снижается, стремясь к температуре датчика в дефлегматоре. Ну а в стационарном состоянии они почти сравниваются. Естественно, если количества этанола в кубе достаточно и датчик в царге находится не слишком близко к кубу :) Ну а окончание отбора голов (третий критерий) будем контролировать просто по суммарному количеству голов, прошедших через клапан. В каждом контроллере PWM определен виртуальный (программный) "датчик" интегрального расхода, суммирующий прошедшую через клапан жидкость. Его и будем использовать.

Текст скрипта приведен ниже в "раскладушке". В приложении к данному топику находится также и файл скрипта test01.py.

Скрытый текст
import time
from lite import *

# Определение алиасов ------------------------------------------------------
T_куб = T0
T_царга = T1
T_деф = T2
T_вода = T4
тэн = w0
клапан = q0
расход = Q0
# Этап разгона --------------------------------------------------------------
тэн.on() # Включаем ТЭН на максимальную мощность
print('\nРазгон...')
while T_царга.v < 65.0: # Ждем пока куб не закипит и пар не пойдет в колонну
 print(T_куб.v, T_царга.v, T_деф.v, T_вода.v, end = '\r')
 time.sleep(1) # Секундная пауза
тэн.v = 600.0 # Разогнались, переводим ТЭН на рабочую мощность
# Этап вывода колонны на стационар ------------------------------------------  
print('\nВыводим колонну на стационар...')
while abs(T_царга.v - T_деф.v) > 1.0: # До сравнивания т-р в дефе и царге
 print(T_куб.v, T_царга.v, T_деф.v, T_вода.v, end = '\r')
 time.sleep(1) # Секундная пауза
# Этап отбора голов----------------------------------------------------------
расход.v = 0 # Сбросим счетчик расхода
клапан.v = 50 # Влючаем отбор со скоростью 50 мл/час
print('\nОтбираем головы...')
while расход.v < 2: # Отберем 2 мл голов. Ну это просто для теста :)
 print(расход.v, end = '\r')
 time.sleep(1) # Секундная пауза
print('\nОтобрано ' + str(расход.v) + ' мл голов')
# Завершаем работу ----------------------------------------------------------
клапан.off()
тэн.off()

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

Первые две команды - это импорт модуля time для обеспечения пауз внутри циклов и нашей библиотеки lite.

Следующий блок - определение алиасов для нескольких объектов, с которыми мы будем работать непосредственно в этом скрипте.

Следующий блок скрипта помечен как "Этап разгоны". Мы включаем нагрев на полную мощность после чего входим в цикл while с условием на температуру датчика в нижней части колонны. Как только температура превысит 65°C, происходит выход из цикла. В самом теле цикла, для визуального контроля, на консоль выводятся интересующие нас температуры. После вывода температур, на каждом шаге цикла, интерпретатор делает секундную паузу. Чтобы не слишком "загонять и дергать" систему :)

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

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

После выхода из цикла отбора голов, выключаем отбор и нагрев. Конец работы, задача выполнена.

На рисунке ниже приведен скриншот экрана после окончания работы этого скрипта. Как и в предыдущих экспериментах, работа велась с рабочей станции под Ubuntu, соединенной с малинкой по ssh.
screenshot_2.png
Screenshot_2. Ненавязчивая автоматизация ректификационной установки. Автоматика.

Конечно, скрипты для реальной ректификации будут выглядеть посложнее. Будет больше стадий, обработка нештатных ситуаций, какой-нибудь UI. Нужна возможность рестарта процесса с нужной точки. Мало ли что может случиться. Но цель данного топика и скрипта заключается только в демонстрации приемов работы с библиотекой lite, простоты и эффективности ее использования :)

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


PS
Про головы. Обычно их скапливается столько, что никаких шашлыков и костров не хватит. Но, в условиях карантина, есть хорошее им применение. Из голов получается неплохая дезинфицирующая жидкость для рук. Головы нужно немного разбавить (до 70-80%) и от души накидать в емкость мандариновых корочек. Запах, конечно, так себе... Но, за счет масла мандариновых корочек, жидкость совсем не сушит руки и хорошо смягчает кожу. Высыхает очень быстро и руки совсем не жирные.

Предыдущий топик Вернуться к оглавлению Следующий топик
test01.py.zip 865.0 б
nubsaybot Студент Рязань 27 6
Отв.1953  09 Апр. 20, 11:37
Работает. И как бы понятнее, стало.
55.jpg
55. Ненавязчивая автоматизация ректификационной установки. Автоматика.

Осталось наворотить скрипт и сделать логи)
OldBean Доцент Красноярск 1K 1.4K
Отв.1954  11 Апр. 20, 14:28
Осталось наворотить скрипт и сделать логи)nubsaybot, 09 Апр. 20, 11:37
Как будет видно ниже, это сделать совсем не сложно :)

17.10.3. Библиотека lite 0.4.0.1. Пример скрипта для реальной ректификации

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

Чтобы немного "облегчить" написание скриптов, я добавил в библиотеку lite.py два дополнительных класса. Первый класс (TT) предназначен для перевода терминала в неблокирующий режим работы. В нем же реализованы две старые-добрые функции, знакомые еще со времен MS DOS. Это kbhit() и getch() :) Первая возвращает True, если была нажата какая-нибудь клавиша клавиатуры, а вторая - возвращает символ, соответствующий нажатой клавише.

Второй класс (Mode), добавленный в lite.py, это класс режимов работы установки. Ну типа: мониторинг, разгон, отбор голов и т.п. Класс очень простой и содержит три атрибута: название режима, ссылку на функцию init, которая вызывается, когда система переходит в этот режим, и ссылку на функцию cond, которая периодически вызывается в процессе работы для проверки условий выхода из данного режима и каких-нибудь полезных действий (например, какая-то температура достигла порога, отобрано заданное количество продукта, вычислить поправку к уставке при изменении атмосферного давления и т.п.).

Эта модифицированная версия библиотеки имеет номер 0.4.0.1, совместима с предыдущими версиями и находится в приложении к данному топику.

Кроме этого, в приложении к топику находится и сам файл скрипта test03.py при помощи которого можно проводить вполне "взрослую" ректификацию спирта-сырца на оборудовании, которое используется в варианте LITE. Как и в предыдущих случаях запускать скрипт можно как непосредственно с малинки, так и удаленно через ssh с другого компьютера, планшета или телефона. В том числе и в фоновом режиме (например, при помощи утилиты screen или непосредственно средствами ОС). Управлять процессом можно при помощи цифровых клавиш (выбор номера режима) и клавиши q (завершение работы). В процессе работы пишется лог (текстовый файл), в котором сохраняется вся существенная информация о процессе. Впоследствии (или даже непосредственно в процессе работы, если приспичило посмотреть :) этот файл можно загружать в Excel, Libre Calc или другую программу построения графиков для визуального анализа процесса. Пример таких графиков по информации в логе сегодняшней ректификации представлен на картинке ниже.

log.png
Log. Ненавязчивая автоматизация ректификационной установки. Автоматика.


На графике проиллюстрирована работа скрипта во всех режимах от мониторинга до отбора исправимых хвостов и продемонстрирована работа старт-стопа на финальном этапе отбора тела. Текущий режим работы схематично преставлен на нижней диаграмме.

На скриншоте экрана, представленном ниже, можно посмотреть как выглядит сама консоль во время работы скрипта.

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


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

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

Подробный "разбор" скрипта test03.py проведем в следующем топике.

Предыдущий топик Вернуться к оглавлению Следующий топик
ekochnev Магистр Екатеринбург 207 54
Отв.1955  11 Апр. 20, 18:56
А почему калибровки меняются у датчиков атмосферного давления BMP180, BMP280?
Если запустить lsync, то у этих датчиков показывает 0.007500000000000001, а если импортировать lite, то 0.00750061683

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

Еще в версии 0.4.0.1:
1. Запускаю в консоли python3
2. Набираю: from lite import *
После этого гасится курсор и отображение ввода: питон реагирует на введенные команды, но вводить приходится вслепую - курсора нет и то что вводишь не видно

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

Еще, Сергей, если не сложно, напомните пожалуйста про методику калибровки датчика MPX5010, что там за магические числа в качестве первого и второго параметра. У меня вчера в процессе перегонки почему-то раскалибровался этот датчик. Сходу на 99 страницах ветки не нашел информацию, а сам уже не помню - давно его собирал... Это уже не надо - сам нашел информацию в модуле api
OldBean Доцент Красноярск 1K 1.4K
Отв.1956  11 Апр. 20, 20:07
А почему калибровки меняются у датчиков атмосферного давления BMP180, BMP280?
Если запустить lsync, то у этих датчиков показывает 0.007500000000000001, а если импортировать lite, то 0.00750061683ekochnev, 11 Апр. 20, 18:56
Это связано с форматом хранения калибровочных данных в МК контроллеров и в редиске. Коэффициент (первое число в калибровочной тройке чисел) - вещественное число, но хранится оно в МК (и в редиске тоже) в виде двух целых чисел: целая часть коэффициента - в двух байтах и дробная часть (умноженная на 10000) тоже в двух байтах. Поэтому дробная часть, начиная с пятого знака после запятой, обрезается (см. функции ser() и deser() в модуле lite.py). Т.е. в сумме вещественный коэффициент хранится в 4-х байтах. Этой точности вполне достаточно. Если же брать этот коэффициент непосредственно из объектов классов BMP180 или BMP280 (см. свойство calibr), то мы получим необрезанное значение. В питоне вещественный тип (float) всегда хранится в 8 байтах (т.е. как double в Си).
После этого гасится курсор и отображение ввода: питон реагирует на введенные команды, но вводить приходится вслепую - курсора нет и то что вводишь не видноekochnev, 11 Апр. 20, 18:56
Да, так и должно быть. Терминал переводится в неблокирующий режим с выключенным эхом. Эхом, если нужно, "руководит" уже само приложение. Если в управляющем скрипте не нужен такой режим работы, то перед импортом lite нужно сбросить флаг kbdFlag в False:
import builtins
builtins.kbdFlag = False # Отменяем переход терминала в неблокирующий режим без эха при импорте lite
from lite import *
...
ekochnev Магистр Екатеринбург 207 54
Отв.1957  11 Апр. 20, 21:56
Да, так и должно бытьOldBean, 11 Апр. 20, 20:07

Я понимаю, уже посмотрел по исходникам.
Просто Вы сделали версию 0.4.0.0, показали на примере ручного набора строчек из test01 как можно всем рулить из питоновской сессии просто вводя команды, а на следующий день в версии 0.4.0.1 закрыли возможность это повторить, т.к. теперь набираемые руками команды не видны. И без данного пояснения как отменить такой режим все это выглядело странно.
sig Кандидат наук Ростов-на-Дону 304 138
Отв.1958  11 Апр. 20, 22:53, через 58 мин
Может быть, надо инвертировать логику kbdFlag? По умолчанию сделать kbdFlag = False в lite.py А если в клиенте будет нужна обработка нажатий клавиш, то в программе клиента можно сделать
import builtins
builtins.kbdFlag = True # Включаем переход терминала в неблокирующий режим без эха при импорте lite
from lite import *
ekochnev Магистр Екатеринбург 207 54
Отв.1959  11 Апр. 20, 22:55, через 2 мин
Может быть, надо инвертировать логику kbdFlag?sig, 11 Апр. 20, 22:53
Я тоже считаю что так будет лучше