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

Вы тут о высшем, а я с HUB'ом не справлюсь. Мистика какая-то. Сухие контакты видит отлично, а ds18b20 на отрез не видит. Перебрал кучу датчиков, как в гильзах, так и корпусе ТО-92.
Причем, когда вешаю датчик, hub говорит, что "контакт замкнут", т.е. садит ds'ка порт на землю.
Как плохо, когда осциллографа нет...

Может быть, надо инвертировать логику kbdFlag?sig, 11 Апр. 20, 22:53

Я тоже считаю что так будет лучшеekochnev, 11 Апр. 20, 22:55

Да, конечно. Согласен. Я тут немного перемудрил. Видимо сказывается увлечение идеей "сверхинкапсуляции" для непрограммистов :)

Давайте поступим так. Чтобы вообще избавить пользователя от неочевидных действий, вообще уберем флаг kbdFlag и создание объекта класса TT во время импорта lite. Сам класс TT, естественно, оставляем в библиотеке. А если пользователю в своем скрипте понадобится неблокирующий режим без эха, то он просто в нужном месте создаст объект класса TT с таймаутом (в мс) в параметрах конструктора: tt = TT(timeout). Кстати, при удалении объекта tt (по концу или явно) терминал автоматически перейдет в нормальный режим с эхом (метод __del__ в классе TT перегружен на восстановление прежних параметров терминала). Это даст возможность работать с разными режимами терминала в рамках одного скрипта.

Спасибо за замечание! Соответствующие изменения в файлы lite.py и test03.py я уже внес и перезалил эти файлы в этом же топике, где они и были.

Как плохо, когда осциллографа нет...BogAD, 11 Апр. 20, 23:35

Да. Глянуть бы на линии 1-Wire хаба не помешало бы.

Саша, а сами-то датчики точно рабочие? Может дохлые. Для проверки можно просто подцепить их их к линии 1-Wire малинки (по умолчанию пин GPIO 4, нужно не забыть про подтягивающий резистор к 3.3v и разрешить работу 1-Wire в малинке). Нужно посмотреть появятся ли соответствующие файлы в папке /sys/bus/w1/devices/. Подробности про проверку датчиков можно посмотреть, например, в этом топике (где-то в середине) или в каких-нибудь статьях в Сети по работе с ds-ками на малинке. Кстати, как дела с датчиком RMS?

17.10.4. Библиотека lite 0.4.0.1. Подробный разбор скрипта для ректификации

Рассмотрим подробнее структуру и организацию скрипта автоматизации процесса ректификации. Сам файл скрипта (test03.py) находится в приложении к предыдущему топику. Для удобства, текст этого скрипта приведен еще в раскладушке ниже.

Скрытый текст

from lite import *

dT = 0.0625 # Квант датчика DS18B20
''' Голобальные переменные ниже будут определены в процессе работы'''
T1max = 0.0 # Макс. т-ра в царге (для оценки уставки старт-стопа)
Tset = Tsb = 0.0 # Текущее и базовое значения уставки старт-стопа
Pb = 0.0 # Атм.давление в момент фиксации базового значения уставки

# Определение режима разгона ---------------------------------------------------
def finit(): # Инициализация режима
  w0.on(); q0.off()
def fcond(): # Проверка условий
  global mode
  if T1.v > 65.0: mode = 2
modes.append(Mode('Разгон', finit, fcond))
# Определение режима холостого хода --------------------------------------------
def finit(): # Инициализация режима
  w0.v = 600.0; q0.off()
def fcond(): # Проверка условий
  pass
modes.append(Mode('Холостой ход', finit, fcond))
# Определение режима отбора голов ----------------------------------------------
def finit(): # Инициализация режима
  w0.v = 600.0; Q0.v = 0.0; q0.v = 50.0
def fcond(): # Проверка условий
  global mode
  if Q0.v > 10: mode = 2 # 10 мл - только для теста :)
modes.append(Mode('Головы', finit, fcond))
# Определение режима отбора подголовников --------------------------------------
def finit(): # Инициализация режима
  global T1max # Макс. т-ра в царге за время отбора подголовников
  w0.v = 600.0; Q0.v = 0.0; q0.v = 400.0; T1max = 0.0
def fcond(): # Проверка условий
  global mode, T1max
  if T1.v > T1max: T1max = T1.v
  if Q0.v > 100: mode = 2 # 100 мл - только для теста :)
modes.append(Mode('Подголовники', finit, fcond))
# Определение режима отбора тела -----------------------------------------------
def finit(): # Инициализация режима
  global Tset, Tsb, Pb
  w0.v = 600.0; Q0.v = 0.0; q0.v = 400.0
  Tset = T1max + 5*dT # Уставка чуток больше макс. т-ры на предыдущем этапе
  Tsb = Tset; Pb = P0.v # Пер-е для коррекции уставки на атм. давление
def fcond(): # Проверка условий
  global Tset
  Tset = Tsb + 0.033*(P0.v - Pb) # Коррекция уставки
  if q0.v == 0.0 and T1.v <= Tset - dT: q0.v = 400.0 # Старт
  if q0.v > 0.0 and T1.v >= Tset + dT: q0.v = 0.0  # Cтоп
modes.append(Mode('Тело', finit, fcond))
# Определение режима отбора хвостов --------------------------------------------
def finit(): # Инициализация режима
  w0.v = 600.0; Q0.v = 0.0; q0.v = 400.0
def fcond(): # Проверка условий
  global mode
  if T2.v > 78.6: mode = 2
modes.append(Mode('Хвосты', finit, fcond))
#-------------------------------------------------------------------------------
print('\nСписок доступных режимов:')
for nm, m in enumerate(modes):
  print(nm, m.name)
print('q завершение работы')
#-------------------------------------------------------------------------------
def emergency(): # Проверка аварийных ситуаций
  ret = False
  if T4.v > 40.0: # Проверка воды охлаждения дефлегматора
    print('Недостаточное охлаждение дефлегматора')
    ret = True
#  elif:
  return ret
#-------------------------------------------------------------------------------
timeout = 500 # Время ожидания нажатия какой-нибудь клавиши
tt = TT(timeout) # Переводим клавиатуру в неблокирующий режим без эха

exitFlag = False # Флаг для выхода из главного цикла
st = mst = time.time() # Время старта всего процесса и текущего режима
log = open('log', "w") # Открываем файл лога
head = '     t   mt  m    T0     T1     T2   T3 T4  U0  P0   w0    q0    Q0   Tset'
print('\n' + head); log.write(head + '\n')
while not exitFlag: # Главный цикла приложения
  U0.conv(); H0.conv() # Запуск преобразований датчиков
  U0.update(); H0.update() # Обновляем данные с датчиков
  now = time.time() # Текущее время
  tim = round(now - st) # Время с начала процесса (сек)
  mtim = round(now - mst) # Время с начала текущего режима (сек)
  ''' Формируем строку данных для записи в лог и выдачи на терминал'''
  s = '% 6d% 6d% 2d% 8.3f% 7.3f% 7.3f% 3.0f% 3.0f% 4.0f% 4.0f% 5.0f% 5.0f% 7.1f% 7.3f'%\
  (tim, mtim, mode, T0.v, T1.v, T2.v, T3.v, T4.v, U0.v, P0.v, w0.v, q0.v, Q0.v, Tset)
  print(s, end = '\r') # Вывод текущего состояния на терминал
  log.write(s + "\n"); log.flush() # Вывод в лог
 
  oldmode = mode # Запомним номер текущего режима для контроля смены режима
  if tt.kbhit(): # Какая-то клавиша была нажата
    try:
      ch = tt.getch()
      if ch == 'q': # Конец работы
        mode = 0; exitFlag = True 
      elif ch >= '0' and ch < str(len(modes)): # Введен номер нового режима
        mode = int(ch)
    except: pass
  
  if emergency(): # Аварийная ситуация
    mode = 0; exitFlag = True
  else: # Штатный режим - проверяем условия смены текущего режима
    modes[mode].cond()

  if mode != oldmode: # Была смена режима
    modes[mode].init() # Устанавливаем состояние согласно новому режиму
    mst = now # Фиксируем время старта нового режима

  if exitFlag: break
  time.sleep(1)
#-------------------------------------------------------------------------------
log.close()
print()
#-------------------------------------------------------------------------------

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

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

Обычно, для ректификации спирта-сырца, я использую 7 режимов, которые нумеруются с 0:

0. Мониторинг. В этом режиме все контроллеры установлены в "нулевое" состояние, ТЭНы выключены, клапана отбора полностью закрыты и т.д. Периодически обновляются измеряемые параметры (напряжение в сети, атмосферное давление, температуры и т.д.). Кстати, при импорте библиотеки lite, система переходит в этот режим автоматически. Контроллеры всех обнаруженных исполнительных устройств (их имена начинаются с маленькой буквы) переводятся в нулевое состояние. Т.е. нулевой режим присутствует в системе по умолчанию. Дополнительные режимы пользователь должен определить сам в своем скрипте.

1. Разгон. Этот режим предназначен для ускорения вывода колонны в рабочий режим. Для этого в кубе обычно включаются дополнительные ТЭНы, либо единственный ТЭН включается на максимальную мощность. У меня - последний случай. Режим разгона должен быть выключен, когда жидкость в кубе закипит. Можно использовать различные варианты индикации факта закипания. Оценивать скорость роста температуры в кубе при разгоне. Резкое падение этой скорости будет свидетельствовать о закипании. Можно индицировать закипание и при помощи датчика давления, расположенного в кубе. У меня же в нижней царге, на высоте около 30 см от нижнего клампа есть палец для DS-ки. Этот датчик я и использую для индикации момента закипания. Как только температура этого датчика начала резко расти и превысила уровень, скажем, 65°C - нужно заканчивать режим разгона и переходить на следующий режим - режим холостого хода.

Обратимся теперь к тексту скрипта.

Строки 9 - 15 как раз и определяют поведение системы в данном режиме. Этот фрагмент скрипта состоит из комментария (строка 9), определения функции finit(), которая будет вызвана при переходе системы в режим разгона (строки 10-11), определения функции fcond(), которая будет вызываться на каждом такте главного цикла скрипта, если система находится в режиме разгона (строки 12-14), создания объекта класса режимов Mode и помещение этого объекта в список доступных режимов (строка 15).

В питоне все является объектами. В том числе и функции. Поэтому имена этих функций мы можем просто передавать конструктору объекта класса Mode как обычные параметры (см. строку 15). Они становятся атрибутами данного объекта (в нашем случае - init и cond, см. определение класса Mode в файле lite.py). В последствии мы можем вызвать эти функции, используя конструкции типа modes[mode].init() или modes[mode].cond().

Еще один комментарий необходимо сделать по поводу области видимости переменных. В строке 13 интерпретатору питона дается указание, что переменная mode находится снаружи тела функции. А иначе как он поймет, что нужно модифицировать именно внешнюю переменную (номер режима) а не создать свою локальную mode? Если переменная находится в выражении справа от оператора "=" и не определена в данной функции, то он, конечно, сообразит. А если слева от "="? Вот для однозначности как раз и используется ключевое слово "global".

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

В строках 16-21 скрипта находится определение режима холостого хода. С учетом вышесказанного здесь комментировать уже нечего. Единственный нюанс: из режима холостого хода не предусмотрен автоматический выход. Поэтому в функции fcond() не проверятся никакие условия и не производится никаких иных действий. Один оператор pass.

3. Головы. Смысл этого режима понятен из его названия - отбор головных фракций. Отбор ведется при рабочей мощности нагрева при небольшой скорости отбора (50 мл/час). Окончание режима происходит после отбора заданного количества голов.

Определение этого режима в скрипте представлено строками 22-28. При инициализации режима производится установка рабочей мощности нагрева, сбрасывается на 0 датчик расхода через 0-й клапан отбора и устанавливается скорость отбора 50 мл/час (строка 24). В строке 27 сформировано условие окончания режима отбора голов. В тестовом скрипте мы отберем всего 10 мл голов, а на практике, для своего объема куба (23 л) я обычно отбираю порядка - 200 мл неисправимой вонючести.

4. Подголовники. В режиме отбора голов я обираю около 2-3% этанола, находящегося в кубе. Остальной объем легких фракций я отбираю в виде подголовников, представляющих собой оборотный спирт, используемый в следующей ректификации. Режим отбора подголовников отличается от режима отбора голов лишь скоростью отбора (400 мл/час) и объемом отобранных подголовников (1 л для 23 литрового куба). Поэтому структура команд, определяющих данный режим (строки 29-37), практически те же, что и для голов. Отличаются скоростью отбора и критерием завершения режима. За одним небольшим исключением - оценкой максимальной температуры в царге во время отбора подголовников.

Необходимо пояснить зачем это нужно. На следующем этапе (отборе тела) для регулирования средней скорости отбора мы будем использовать известный импульсный регулятор отбора, известный как "старт-стоп". Я использую достаточно жесткий регулятор. Гистерезис всего +- 1 квант датчика DS18B20. Поэтому изначальную уставку, зависящую, кстати, еще и от атмосферного давления, желательно задать как можно точнее. Обычно я делал это "вручную" при переключении из режима отбора подголовников в режим отбора тела. Но в данном скрипте мне хотелось избежать дополнительных интерфейсных элементов для редактирования уставки. Поэтому я реализовал автоматическое определение уставки следующим образом: уставка равна максимальной температуре в царге во время отбора подголовников, увеличенной примерно на 5 квантов датчика DS18B20 (примерно 0.3°C). Обычно это - хорошая оценка.

В связи с этим, при инициализации режима отбора подголовников, обнуляется глобальная переменная T1max (см. последний оператор в строчке 32 скрипта), а в функции fcond() эта переменная периодически сравнивается с температурой в царге T1 и корректируется, если нужно (строка 35).

5. Тело. Определение режима отбора тела представлено в строках 38-49 скрипта (см. рисунок ниже).

Помимо установки мощности нагрева, скорости отбора и сбросе счетчика отбора, при инициализации режима происходит вычисление значения уставки на момент старта режима (строка 42) и определении вспомогательных переменных, необходимых для коррекции уставки при изменении атмосферного давления (строка 43). В функции fcond() происходит корреция уставки (строка 46) и регулирование отбора методом старт-стоп (строки 47, 48). Смысл этих строк таков: если отбор выключен и температура в царге упала на один квант DS18B20 ниже уставки, то включаем отбор (строка 47). Если же отбор включен и температура поднялась на один квант выше уставки, то отбор выключаем (строка 48).

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

6. Хвосты. В конце отбора голов в колонне остается еще вполне чистый оборотный спирт. Для извлечения его предусмотрен данный режим (строки 50-56). По управляющим параметрам он такой-же, как и режим отбора подголовников, только используется другой критерий выхода из него. Не по объему отобранного спирта, а по температуре в дефлегматоре (строка 55).

Итак, мы рассмотрели все нужные для ректификации режимы. Теперь рассмотрим другие фрагменты скрипта.

Следующее действо - распечатка на экране списка режимов с их номерами. Это удобно для "ручного" переключения режимов. Распечатка выполняется в строках 58-61 скрипта.

В следующем блоке кода (строки 63-69) находится объявление функции emergency(). Эта функция вызывается на каждом такте основного цикла. Она возвращает True, если сработал какой-нибудь аварийный датчик, или False если все в порядке. Для примера в данном скрипте показана проверка датчика температуры воды охлаждения дефлегматора, установленного на выходной трубке.

Идем по скрипту дальше (см. рисунок ниже).

В строках 71, 72 создается объект tt класса TT. При создании этого объекта происходит перевод клавиатуры в, так называемый, неблокирующий режим. Такой режим дает возможность оперативно реагировать на нажатия клавиш в главном цикле приложения.

Следующие строки (74-76) прокомментированы в тексте самого скрипта и в дополнительных комментариях не нуждаются. В строке 76 открывается файл, в который будет записываться лог. В строке 77 определена "шапка", которая затем выводится на экран и в лог (строка 78).

Наконец, после всех подготовительных операций, рассмотренных выше, мы входим в главный цикл приложения (строка 79). Это бесконечный цикл, выход из которого происходит при установке флага exitFlag в True. В самом начале цикла происходит запуск преобразователей "медленных" датчиков. Время преобразования датчика RMS - 1 сек, температурных датчиков, подключенных к хабу и управляемых через него, - 0.75 сек. Лучше, если эти преобразования будут происходить одновременно. Поэтому сначала запускаются все преобразования датчиков, а уже затем - считывание их показаний (строка 81). Чтобы преобразования происходили параллельно, а не последовательно.

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

Далее начинается проверки различных условий и, если условия выполняются, переход в новый режим (целочисленная переменная mode). Номер текущей моды сохраняется в переменной oldmode.

В первом блоке проверок (строки 92-99) проверяется была ли нажата какая-нибудь клавиша (строка 92). Если "да", то принимаются соответствующие решения. В строках 101, 102 проверяются аварийные ситуации, а в строке 104 - условия, определенные для текущего режима.

В строках 106-108 выполняются действия, если произошла смена текущего режима работы установки, проверяется условие завершения и работы и делается секундная пауза.

При выходе из главного цикла закрывается файл лога и завершается работа скрипта.

---

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

---

Предыдущий топик Вернуться к оглавлению Следующий топик

if emergency(): # Аварийная ситуация
    mode = 0; exitFlag = TrueOldBean, 12 Апр. 20, 13:59

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

но разве это повод останавливать процесс при наличии оператора в шаговой доступности?makh, 12 Апр. 20, 14:21

Абсолютно согласен. Сам пару раз накалывался - ночью давление в водопроводе падало, деф. перегревался. Но не критично. Нет бы позвонить и разбудить - я бы краник приоткрыл побольше... Но автоматика тихо, но неумолимо все отрубала. Утром просыпаешься - бли-н-н-н... А глянешь лог - второй бли-н-н-н...

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

PS
Насчет флажка присутствия оператора - очень интересная мысль. Спасибо! Замечательно то, что выставление этого флажка вполне автоматизируется (датчик движения, емкостные датчики и т.п.)

выставление этого флажка вполне автоматизируетсяOldBean, 12 Апр. 20, 16:31

Концевик у входной двери, на который вешается ключ от машины .)

Насчет флажка присутствия оператора - очень интересная мысль. Спасибо! Замечательно то, что выставление этого флажка вполне автоматизируется (датчик движения, емкостные датчики и т.п.)OldBean, 12 Апр. 20, 16:31

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

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

Саша, а сами-то датчики точно рабочие? Может дохлые. Для проверки можно просто подцепить их их к линии 1-Wire малинки (по умолчанию пин GPIO 4, нужно не забыть про подтягивающий резистор к 3.3v и разрешить работу 1-Wire в малинке). Нужно посмотреть появятся ли соответствующие файлы в папке /sys/bus/w1/devices/. Подробности про проверку датчиков можно посмотреть, например, в этом топике (где-то в середине) или в каких-нибудь статьях в Сети по работе с ds-ками на малинке.OldBean, 12 Апр. 20, 05:01

Сергей, как вводу глядел. 2 датчика в корпусе ТО-92 и один в гильзе мертвые. Проверил Ардуинкой.
Еще 3 нашел, в закромах и 1 снял с китайской платы живого термостата.
2 какие-то левые, надпись "7Q-Tek 18b20" в корпусе ТО-92. Ардуинка их все видит и показывает температуру в терминале.
А вот только в hub'е замеренные значение... какие-то не реальные (библиотека 0400).
Копия из терминала:

pi@raspberrypi:~ $ cd /home/pi/WRK/LITE/Soft_0400
pi@raspberrypi:~/WRK/LITE/Soft_0400 $ python3
Python 3.7.3 (default, Dec 20 2019, 18:57:59)
[GCC 8.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from lite import *
T0 15_0_28 Датчик температуры DS18B20 [0.0625, 0, 4]
T1 15_1_28 Датчик температуры DS18B20 [0.0625, 0, 4]
T2 15_2_28 Датчик температуры DS18B20 [0.0625, 0, 4]
T3 15_3_28 Датчик температуры DS18B20 [0.0625, 0, 4]
Z0 15_4_FF Нормально разомкнутый контакт [1.0, 0, 0]
Z1 15_5_FF Нормально разомкнутый контакт [1.0, 0, 0]
Z2 15_6_FF Нормально разомкнутый контакт [1.0, 0, 0]
Z3 15_7_FF Нормально разомкнутый контакт [1.0, 0, 0]
H0 15_8_A5 Хаб 1-Wire
>>> T0.v
644.25
>>> T1.v
642.5
>>> T2.v
4082.5
>>> T3.v
4095.9375
>>>

Грею руками, значения не меняются.
Т0 и Т1 в корпусе ТО-92 "7Q-Tek 18b20",
Т2 и Т3 в гильзах
Совсем нет у меня идей... все перепробовал. В чем затырка?

Кстати, как дела с датчиком RMS?OldBean, 12 Апр. 20, 05:01

Тут банально, поставил новый камень, прошил и RMS ожил...

ИМХО, так же банально надо и с датчиками.. Только брать не у китайца..

Проверить ДС-ку на "настоящесть" можно довольно просто, при наличии ардуинки.. В два этапа -- сперва причитать ROM и проверить CRC, а потом прочитать скратчпад, проверить TL и TH на соответствие значениям по умолчанию согласно даташита, и проверить CRC.. Если все сидит -- возможно, будет рабочая..

А как вытащить данные для графиков из редиски?

все нештатные ситуации она должна обязана отрабатывать сама , оператор может только по ходу подкрутить...m16, 12 Апр. 20, 18:23

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

Совсем нет у меня идей... все перепробовал. В чем затырка?BogAD, 12 Апр. 20, 19:51

Ну если датчики распознаются - значит что-то уже начинает дышать. А если с ардуинкой датчики работают нормально, то первой под подозрение попадает связь по i2c. По сути HUB (физически) - это та же ардуинка. Для начала можно снизить скорость обмена (как это сделать - можно посмотреть в конце этого топика или в Сети).

А как вытащить данные для графиков из редиски?nubsaybot, 12 Апр. 20, 20:44

В api есть функция temp. Ее описание и примеры использования есть прямо в самом файле (api.py). После работы этой функции будет создан текстовый файл "temp.txt" в котором есть таблица. Разделитель - пробел. Этот файл можно импортировать в любую электронную таблицу (типа Excel или Libre Calc) и там построить графики.

вариант оповещения начальства - телефонный звонокOldBean, 13 Апр. 20, 02:04

Ну хз.. Вот корячусь я на работе, и тут приходит смс или даже звонок -- и што мне делать? Бросить все и думать что ему ответить? Да ну в пень, пусть сразу молча все глушит и молчит пока по совокупности показаний приборов не определит пожарную тревогу.. Вот тогда придется думать, не дай б-же конечно..

Вот на шаблонном примере, когда вода в дефе погорячела выше 40-ка цельсев.. Пар ведь из ТСА не свистит при этом, наверное даже до 50-ти не будет свистеть.. И вот "удаленный" оператор получает весточку.. Был бы на месте, сразу бы понял -- просто просело давление в водопроводе, или вода таки совсем кончилась, или мыши шланг перегрызли, и что можно или нельзя с этим делать не остановливая процесс..

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

Естессна, если известно, что при 60-ти цельсиях пар уже свистит из ТСА, то на 50-ти надо безусловно отключать..
Error levels, заморочиться и разложить по полочкам, долго и муторно..

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

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

В свете моих проблем с ds18b20, решил сделать тестер для этого семейства, тем более не так давно, где-то на gitHub'е, читал про простецкий тестер.
Поискал в записях, и нашел: https://github.com/joysfera/DS18B20-tester. Тут и схема, и скетч.
Спаял на 30 минут, без дисплея NOKIA. Контроль по монитору порта.
Что получилось на шилдике Arduino NANO:
Ножки на шильд не стал запаивать, даже в разъем ISP.
Со стороны AtMega напаиваем ЧИП резисторы 1206: А0-А1 и А2-А3 по 270 Ом. Резистор 2,2 кОм, один контакт напаиваем на +5v платы, второй контакт, тонкой проволочкой во фторопластовой изоляции (МГТФ) на контакт А3.
На этой стороне все.

С обратной стороны на термоклей китайский, клеем на плату гнездо прямое 2.54мм 1х3, PBS-3 (DS-1023 - 1x3).
Теми же проволочками в изоляции МГТФ, паяем перемычки:
VDD гнезда на А0, BUS (средний) на А2, GND на соответственно.
Должно получиться так:

Усиливаем в гнезде контакты Китайскими соплями, иначе вылазят, сволочи...

И прошивать, я руками прижимал под углом 6-ти контактный ISP
Питаемся от miniUSB, по нему же монитором порта смотрим тест.
Да, скорость монитора порта ставим 115200, иначе идут крокозябры...

Следующим постом результаты испытаний. А они интересны...

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

Для начала можно снизить скорость обмена (как это сделать - можно посмотреть в конце этого топика или в Сети).OldBean, 13 Апр. 20, 02:04

Мдя... упустил это. Нужно было догадаться.
Но не все так просто.
Вопрос по [сообщение #12950730] :
sudo cat /sys/module/i2c_bcm2708/parameters/baudrate
Ругается, что нет папки.
Посмотрел путь /sys/module/ , там папка не 2708, а 2835...
Т.е. другой чип.
Значит меняем options i2c_bcm2708 baudrate=9600 на options i2c_bcm2835 baudrate=9600?
И от куда взялся у тебя в описании чип i2c_bcm2708, хотя тут [сообщение #13029695] говорилось про чипы 2835 и 2837?

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

и... на команду
sudo cat /sys/module/i2c_bcm2835/parameters/baudrate (изменил 2708 на 2835)
ругается что "нет такого файла или каталога"
В каталоге parameters (путь /sys/module/i2c_bcm2835/parameters) один файл debug. Создаем папку или файл под именем parameters?

И от куда взялся у тебя в описании чип i2c_bcm2708,BogAD, 13 Апр. 20, 13:10

Давно это было. Сейчас уже и не вспомню :(

---

Чтобы не привязываться к чипу, сделайте так. Откройте в текстовом редакторе файл

/boot/config.txt

и найдите строчку

dtparam=i2c_arm=on

Добавьте к ней про baudrate, чтобы получилось:

dtparam=i2c_arm=on,i2c_arm_baudrate=9600

Сохраните файл и перезагрузите малинку.

Проверить скорость i2c можно командой:

xxd /sys/class/i2c-adapter/i2c-1/of_node/clock-frequency

Увидите шестнадцатеричное число. Переведите его в десятичный формат. Это и будет частота работы шины i2c в герцах

Да, спасибо. сменилась скорость. Вот только сильно то и н чего не изменилось.

Вводная, стоит ВМР280, в HUB'е по адресу Т0, Т1 стоят левые датчики, моему тестеру не нравятся, в Т2 поставлен герметичный его тестер пропускает.
Т3 - адаптер 1-wire датчика даления.
Не стал делать скрины экрана, через буфер обмена терминал (красным мои вставки):

pi@raspberrypi:~ $ cd /home/pi/WRK/LITE/Soft_0400
pi@raspberrypi:~/WRK/LITE/Soft_0400 $ python3
Python 3.7.3 (default, Dec 20 2019, 18:57:59)
[GCC 8.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from lite import *

166 эта цифра появляется при включении адаптера 1-wire

96 эта цифра появляется при включении BMP280
U0 11_8_A1 Датчик RMS [0.3839, 0, 1]
T0 15_0_28 Датчик температуры DS18B20 [0.0625, 0, 4]
T1 15_1_28 Датчик температуры DS18B20 [0.0625, 0, 4]
T2 15_2_28 Датчик температуры DS18B20 [0.0625, 0, 4] пропали порты Z0-Z4
H0 15_8_A5 Хаб 1-Wire
>>> T0.v
20.25 значение одно и тоже, даже если греть датчик
>>> T1.v
5.3125 значение одно и тоже, даже если греть датчик
>>> T2.v
4081.9375 значение одно и тоже, даже если греть датчик
>>>

Причем объекты урезаны! Смотрим ниже.
Удалил адаптер 1-wire и ВМР280
Терминал:
pi@raspberrypi:~/WRK/LITE/Soft_0400 $ python3
Python 3.7.3 (default, Dec 20 2019, 18:57:59)
[GCC 8.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from lite import *
U0 11_8_A1 Датчик RMS [0.3839, 0, 1]
T0 15_0_28 Датчик температуры DS18B20 [0.0625, 0, 4]
T1 15_1_28 Датчик температуры DS18B20 [0.0625, 0, 4]
T2 15_2_28 Датчик температуры DS18B20 [0.0625, 0, 4]
Z0 15_3_FF Нормально разомкнутый контакт [1.0, 0, 0]
Z1 15_4_FF Нормально разомкнутый контакт [1.0, 0, 0]
Z2 15_5_FF Нормально разомкнутый контакт [1.0, 0, 0]
Z3 15_6_FF Нормально разомкнутый контакт [1.0, 0, 0]
Z4 15_7_FF Нормально разомкнутый контакт [1.0, 0, 0]
H0 15_8_A5 Хаб 1-Wire
>>> T0.v
20.25 значение одно и тоже, даже если греть датчик
>>> T1.v
5.3125 значение одно и тоже, даже если греть датчик
>>> T2.v
4081.9375 значение одно и тоже, даже если греть датчик
>>> U0.v
218.5314182249609
>>>

Объекты все, но показания датчиков температуры не изменяются!
Что за "166" и "96"?
RMS один в адеквате.
У меня мозг взорвется

У меня мозг взорветсяBogAD, 13 Апр. 20, 19:55

Давайте не будем ничего взрывать и все-таки будем делать скриншоты экрана (при нажатии клавиши PrintScreen в корне домашней директории появится файл скриншота). Иначе у меня мозг взорвется: по Вашему тексту у меня вообще складывается впечатление, что Вы втыкаете и выдергиваете модули прямо "на ходу", без выключения питания и малинки. Итак делаем все последовательно и точно как написано.
1. Выключаем малинку, отключаем ее питание и питание соответствующих линий на крейте, если они запитаны отдельно.
2. Оставляем в крейте только датчик RMS.
3. Включаем питание всего - малинка начнет загружаться.
4. После загрузки малинки запускаем терминал и переходим в папку, где находится lite.py
5. Пишем python3 затем уже в питоне from lite import *
6. Ждем пока малинка напишет все буквы и нажимаем клавишу print screen
7. Демонстрируем скриншот

PS
Саша, я только сегодня вспомнил, что у Вас, кажется, линии крейта +5 и +3.3 запитаны отдельно. В этом случае питание на крейт нужно подать не позже подачи питания на малинку.

Небольшое исправление в библиотеке lite v.0401

Для устранения конфликта устройств типа 0x00 (нормально замкнутый контакт), атрибуты fc классов TT и Mode установлены в 0xFE. Исправленная версия перезалита в тот же топик, где была изначальная и в данном топике. Эта коллизия может повлиять только на работу с нормально замкнутыми контактами, подключенными к хабам.

Небольшое исправлениеOldBean, 14 Апр. 20, 05:51

Сергей, у меня есть к Вам просьба.

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

Может быть, если уж Вы используете для обозначения версии последовательность чисел, то будем использовать в нумерации общепринятый подход?
Рассмотрим на примере 0.4.0.1:
1. Мажорная версия 0. Ее смена используется при кардинальных изменениях в готовом продукте. Вы считаете, что Ваша система еще не закончена, поэтому тут 0. Согласен.
2. Минорная версия 4. Внесение серьезных изменений в функционал текущей мажорной версии продукт, но недостаточный для выделения в отдельную мажорную версию. Согласен как это было при переходе от 0.2 к 0.3
3. Вторая минорная версия: 0. Внесение мелких изменений в функцинал текущей мажорной версии. В моем понимании Ваш переход 0.4.0.0 -> 0.4.0.1 должен был выглядеть как 0.4.0.0 -> 0.4.1.0
4. Третья минорная версия: 1. Багфиксы. А вот тут имхо как раз должны были быть последних два публикуемых изменения версии 0.4.0.1

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

Извините, что поучаю, но я много лет работаю в сфере разработки программного обеспечения, и считаю Ваш текущий подход не правильным.
Просто у меня сейчас на руках три разных версии 0.4.0.1. Помимо их тупого использования, я при просмотре текста программы хочу понять Вашу мысль и последовательность вносимых изменений. Сейчас когда три архива с этими версиями лежат рядом это очень неудобно для понимания какой из них был раньше. Поэтому прошу Вас при КАЖДОЙ публикации хоть какого изменения софта менять хотя бы самый младший разряд в номере версии.

С уважением к Вам.