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

После редактирования питоньего кода в винде символы конца строки выглядят в редакторе mc так: "^M".
Уберите их в заголовках.

Ну винда вроде здесь совсем никак и нигде не фигурировала. Или я что-то пропустил? У ZagAl, насколько я понимаю, проблемы с matplotlib начались при портировании скрипта на Ubutu 18.04.

---

Побродил по институту - нашел у хороших людей 18-ю убунту. Попросился немного посидеть за ней. Вот что выяснил.

1. По умолчанию (т.е. когда просто пишешь python) таки запускается 2-й питон. В нем на 18-й убунте скрипт не работает. BOM тоже не помог.
2. На 3-й питоне matplotlib не был установлен. Но разрешили установить. Установил (sudo apt install python3-matplotlib).
3. На третьем питоне (python3 скрыпт.py) все работает. И с BOM-ой и без нее.

Совет ZagAl - работайте в третьем питоне. Кстати, говорят, что 18-я убунта - это последний релиз в котором по умолчанию оставлен второй питон. Дальше будут ставить только третий. Так что, наверное, пора окончательно перебираться на третью змеюку...

По мере сил и времени, таки, "добил вчерне" автоматический анализ "железа" и конфигурирование софта. При старте системы (в данном случае - импорте модуля lite.py) малинка автоматически просматривает все что воткнуто в шину i2c и подцеплено к бриджам i2c-8x1-Wire (цифровым модулям), определяет типы устройств, читает, если нужно, из их EEPROM калибровочную информацию и, в конечном итоге, создает питоновское окружение, соответствующее текущей конфигурации железа.

К сожалению, не удалось обеспечить совместимость с первым вариантом прошивок из-за необходимости расширения протокола обмена малинки с периферией (сделана небольшая надстройка над канальными уровнями i2c и 1-Wire). Функциональность модулей, естественно, тоже соответственно расширена. Поэтому, если возникнет желание воспользоваться этой опцией, все модули предыдущего варианта LITE придется перепрошивать. Существующая библиотека nna тоже не будет работать с новыми прошивками.

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

Пример автоматического анализа железа (это мое железо из варианта LITE на данный момент) - на скриншоте в приложении к топику. В первой колонке - адрес на шине i2c, во второй - типы устройств (это "коды семейств", в духе 1-Wire ;), далее - расшифровка, а в скобках - калибровочная информация.

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

все модули предыдущего варианта LITE придется перепрошиватьOldBean, 30 Нояб. 18, 14:13

Сергей, приветствую! А новые прошивки уже есть?

И насчёт цифрового модуля интересно, он остаётся?

И насчёт цифрового модуля интересно, он остаётся?nic2015, 30 Нояб. 18, 16:45

Я так понимаю, что остался, по адресу 0х15

А новые прошивки уже есть?gol_avto, 30 Нояб. 18, 14:27

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

И насчёт цифрового модуля интересно, он остаётся?nic2015, 30 Нояб. 18, 16:45

Конечно остается. Его прошивка как раз и оказалась самой трудоемкой. Просто здесь он фигурирует как 8-канальный i2c-1-Wire бридж или просто хаб. Мне кажется это название более точно отражает суть дела. Сейчас это действительно бридж (мост, точнее - туннель из шины и протокола i2c в шины и протокол 1-Wire), обеспечивающий подключение к шине i2c устройств с длинными проводами и другим протоколом обмена. Но это все - на уровне софта. По "железу" это и есть чистый цифровой модуль. Здесь ничего не изменилось. Кстати, таких модулей-хабов в системе может быть несколько (в зависимости от количества "длиннохвостых" датчиков, которые нужно подключить). К каждому хабу можно подключить до 8 устройств 1-Wire (неважно, исполнительных, регистров или датчиков). Причем, однотипные устройства (или устройства просто имеющие одинаковый протокол прикладного уровня) могут функционировать параллельно.

17.7. Модуль lsync

Много воды утекло... Но, наконец-то модуль lsync "задышал" более-менее ровно. Похоже, настала пора опубликовать текущий вариант софта варианта LITE. Модуль lsync - главный модуль данной версии автоматизации. По сути дела он представляет собой "синхронизатор" состояния реального "железа" установки и ее виртуального образа, реализованного в "редиске" на малинке ;) Редиска - это быстрая и легкая нереляционная база данных типа "ключ-значение" по имени redis. Она работает непосредственно в оперативной памяти компьютера (малинки), но, естественно, периодически сохраняет информацию на энергонезависимых носителях. В данном случае в redis хранятся все параметры установки и процесса, проводимого на ней в данный момент. Как текущие параметры, так и история за истекшие двое суток (кольцевая организация БД, как, например, в регистраторах). "Глубина" истории, естественно, легко настраивается.

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

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

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

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

Все железо автоматики взято из варианта LITE. Модули, крейт и прочие детали автоматики уже описаны выше (см. раздел 17 в оглавление на первой странице ветки). О новом варианте прошивок этих модулей поговорим в следующем топике. Там же будут сами прошивки и их исходники. А в данном топике рассмотрим дополнительный софт, который необходимо установить на управляющем микрокомпьютере.

В качестве управляющего микрокомпьютера используется Raspberry Pi 3 Model B. OS - свежая версия Raspbian от 13 ноября прошлого года. Базовая настройка малинки тоже была описана раньше (см. раздел 16 оглавления). Дополнительно установить нужно только саму СУБД (redis) и модуль redis-py, необходимый для общения с редиской из питона. Еще один важный момент - здесь и далее будем использовать только третью версию python! Она уже есть в системе. Также, как и вторая.

17.7.1. Установка сервера redis и redis-py

Установка довольно проста.

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

3. Если pip3 (инсталлятор питоновских модулей) не установлен, то установим его:4. Перезагрузим малинку и установим redis-py (модуль для работы с redis на питоне) командой:5. Проверяем работу с редиской из питона:
5.1. Запускаем интерпретатор:5.2. В интерпретаторе импортируем модуль redis:5.3. Устанавливаем соединение с redis:Примечание: если работаем удаленно, то используем следующую питоновскую команду:где 192.168.0.XX - IP адрес хоста, на котором работает redis.
5.4. Даем команду:должны увидеть True

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

1. Маленькая книга о Redis. Это русский перевод англоязычного издания. На этой же странице есть ссылка на самую актуальную версию перевода. В том числе и в pdf-формате.
2. Введение в REDIS-PY - неплохая статья для первоначального ознакомления с работой с redis уже из питона.
3. Ну и, естественно, полная документация по redis-py.

Ну а дальше, если захочется повозиться с этой замечательной СУБД, как говорится: "гугл в помощь". Информации в Сети очень много. В том числе и несколько англоязычных книг, которые можно свободно скачать с известных ресурсов.

---

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

17.7.2. Новые версии прошивок модулей

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

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

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

В данной системе автоматизации применяются два типа шин передачи данных. Для устройств, которые можно расположить вблизи малинки, используется шина I2C. К таким модулям относятся: силовые модули, датчик RMS напряжения питающей сети, датчик атмосферного давления и т.п. Но шина I2C - короткодействующая (обычно, без дополнительных усилий, это десятки сантиметров). Поэтому для модулей с длинными проводами, которые нужно располагать непосредственно на установке (датчики температуры, диф.давления, концевики и т.п.), используются шины 1-Wire, которые подключаются к шине I2C через специальный хаб (ака "цифровой модуль" ;) Для упрощения реализации 1-Wire хаба, в качестве протокола обмена прикладного уровня на шине I2C, было выбрано небольшое подмножество соответствующего протокола DS для шины 1-Wire. В этом случае, задача хаба заключается лишь в трансляции команд и данных, полученных с шины I2C, в одну или несколько шин 1-Wire, которые к нему подключены. Удобен еще и тот факт, что шина I2C поддерживает передачу блоков байтов на физическом уровне (состояние "стоп" на шине I2C можно интерпретировать как своеобразный аналог Reset для шины 1-Wire). В конечном итоге, согласованный с двумя разными шинами, протокол прикладного уровня на шине I2C выглядит следующим образом.

Обмен ведется блоками байтов переменной длины. Мастер - малинка. Структура блока проста. При передаче от малинки к модулю: первый байт - это код команды (совпадающий с соответствующими кодами команд на шине 1-Wire), остальные байты - данные, необходимые для выполнения команды. При приеме - весь принимаемых блок байтов представляет собой данные. На данный момент в прошивках модулей реализован следующий набор команд (шестнадцатеричные коды):

1. 0x33 - получить код семейства модуля (он в первом байте, как и в DS) (read ROM)
2. 0x4e - записать данные в рабочую область памяти МК модуля (write scratch)
3. 0xbe - считать данные из рабочей области памяти МК модуля (read scratch)
4. 0x48 - записать блок данных в EEPROM МК модуля (copy scratch)
5. 0xb8 - cчитать блок данных в EEPROM МК модуля (recall EEPROM)
6. 0x52 и 0x53 - команды управления, специфичные для конкретных модулей

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

Код семейства (тип данного модуля) представляет собой 1 байт. Во множестве кодов семейств DS есть пустая область (старший полубайт - шестнадцатеричная A). Поэтому для кодов семейств модулей данной автоматики были выбраны следующие коды:

1. 0xA1 - вольтметры переменного напряжения (например, датчик RMS)
2. 0xA2 - твердотельные реле
3. 0xA3 - регуляторы с модуляцией плотности импульсов (например, PDM-контроллер ТЭНа)
4. 0xA4 - регуляторы с ШИМ (например, PWM-контроллер клапана отбора)
5. 0xA5 - Хаб 1-Wire (8-канальный бридж с шины I2C на 8 шин 1-Wire)
6. 0xA6 - АЦП с интерфейсом 1-Wire
7. 0xA7 - Датчики давления с интерфейсом 1-Wire (например, тинька+MPX5010DP)
8. 0xA8 - Датчик расхода, весы

Естественно, все коды семейств устройств 1-Wire от DS остаются неизменными. Например, код 0x28 - это датчики температуры DS18B20.

"Исторически" (да и технически ;) получилось так, что некоторые "пустые" коды я тоже задействовал для целей данной задачи:

9. 0x06 - Отладочный макет
10. 0xff - Нормально разомкнутый контакт или просто 'пусто'
11. 0x00 - Нормально замкнутый контакт
12. 0x77 - Датчики давления BMP, поскольку они всегда торчат на шине по адресу 0x77. Пусть и в кодах семейств торчат там же ;)

Ну и из общей информации осталось немного рассказать о калибровочных данных. Если код семейства "железно" прошит и не может быть изменен, то калибровочные данные иногда нуждаются в коррекции. Поэтому они хранятся в энергонезависимой памяти микроконтроллеров модулей (EEPROM), которую можно перезаписывать. Записывать эти данные можно разными способами. Либо через программатор непосредственно при прошивке чипа, либо, посылая соответствующие данные и команды уже работающему в установке устройству. В модуле lsync, тоже предусмотрены средства для чтения и записи калибровочных данных в соответствующих полях БД redis, с последующей автоматической синхронизацией этих данных с EEPROM МК модулей. Об этом варианте мы поговорим подробнее, когда будем обсуждать сам модуль.

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

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

Ну и последний байт - это индекс единицы измерения физической величины, за которую "отвечает" данное устройство. На настоящий момент используются следующие единицы:

0 - безразмерная величина (пусто)
1 - Вольт (В, V)
2 - Ватт (Вт, W)
3 - Миллилитры в час (мл/час, ml/h)
4 - Градусы Цельсия (°C)
5 - Миллиметры ртутного столба (мм.рт.ст., mmHg)
6 - Миллилитры (мл, ml)

---

Ну вот, пожалуй и все из общей информации о первом ("железном") уровне нашей трехуровневой автоматики. Новые варианты прошивок находятся в архиве firmware в приложении к данному топику. Готовые hex-файлы и исходники разложены по отдельным папкам соответственно кодам семейств модулей. Я старался максимально подробно комментировать исходники. Так что, если кого-то заинтересуют детали, разобраться будет несложно.

В следующем топике мы перейдем уже непосредственно к рассмотрению модуля синхронизации lsync.

---

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

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

За свои не полных 50, много встречал фанатов. Но подобию OldBean'у увы...
Сергей, мои оценки в твой адрес много веса не дадут, была бы воля и возможность - орден вручил бы!

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

To BogAD
Да нет тут никакого фанатизма. Просто несколько затянувшееся (да и слава Богу!) увлечение интересной задачей ;)

По поводу сервы. Конечно, контроллеры для движков в формате крейта LITE стОит сделать. И прошивки соответствующие. Это интересно. Но попозже. Сейчас хотелось бы закончить базовый софт для LITE.

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

---

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

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

только как показометр работает, без саязки с малинкойMikrocod, 02 Февр. 19, 09:27

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

Именно поэтому задача изготовления температурного сервера с собственным 7-сегментным индикатором и со связью с малинкой имеет не очень много смысла. В этом и причина тихой кончины этой задачи :(

Оч.хорошо,а есть версия температурного сервера не лайт, и скрипт(не лайт) его использующий ?

а есть версия температурного сервера не лайт, и скрипт(не лайт) его использующий ?Mikrocod, 04 Февр. 19, 10:10

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

17.7.3. Модуль lsync

Как и прошивки, модуль (библиотека) lsync инкапсулирован и закрыт от конечного пользователя. Поэтому ограничусь лишь кратким описанием его структуры и работы. Модуль написан на питоне. Текст скрипта - в приложении к данному топику. Если кого-нибудь заинтересуют детали, то более подробные комментарии можно посмотреть в тексте скрипта.

Модуль решает следующие задачи:

1. При загрузке анализирует содержание подключенного к малинке "железа" (I2C-модулей и хабов для шин 1-Wire).
2. На основе этой информации генерирует необходимые для работы установки объекты классов-оберток модулей.
3. Формирует структуру и начальное состояние базы данных в СУБД redis (по умолчанию база данных с номером 0).

Модуль может быть импортирован как обычный питоновский модуль. В этом случае в главном приложении становятся доступны все сгенерированные объекты и база данных. С другой стороны, модуль lsync может быть запущен отдельно как обычное приложение Python. В том числе и в фоновом режиме (при помощи, например, screen, nohup и т.п.). В этом случае реализуется дополнительная функциональность.

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

Остановимся немного на структуре библиотеки.

В модуле lsync реализованы следующие классы.

1. Класс I2C

Это базовый класс для все классов-оберток устройств, подключенных к шине I2C. В нем реализованы инструменты для блочного обмена с устройствами, подключенными к шине I2C и получения/записи калибровочных данных из/в EEPROM микроконтроллеров этих устройств (методы sc(), gc()).

2. Классы-обертки RMS, Relay, PDM, PWM, Hub и BMP

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

3. Класс Teh

Это класс-контейнер, содержащий объект класса RMS (датчик RMS напряжения питающей сети) и объект класса PDM (модулятор плотности импульсов, ака "Брезенхем"). Объект класса Teh служит для управления мощностью нагрева ТЭНа, который подключается к данному PDM-контроллеру. Если требуется управление мощностями более 2-3 кВт, то к этому классу-контейнеру можно добавить дополнительные модули релейного типа для включения, например, "разгонных" ТЭНов или других задач.

В принципе, классы-обертки, перечисленные в пункте 2 и класс Teh, могут быть использованы для создания соответствующих объектов и управления установкой из питоновских скриптов при помощи методов этих объектов. Для этого нужно просто импортировать модуль lsync в скрипт и явно создать в этом скрипте объекты нужных классов. Но в данной версии билиотеки реализован дополнительный сервис облегчающий создание скриптов управления. Это класс SUP.

4. Класс SUP

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

Во-первых, в конструкторе этого класса производится автоматический анализ подключенного к малинке оборудования и нужные объекты-обертки генерируются тоже автоматически. В результате формируется словарь devs, в котором, в качестве значений, хранятся ссылки на все автоматически созданные объекты. Ключами в этом словаре служат адреса (в шестнадцатеричном формате) этих устройств на шине I2C и номера каналов, если устройства подключаются к хабам шин 1-Wire. Например, ключ к контроллеру клапана отбора, подключенного по адресу 0x14 представляет собой строку 'x14', а, например, ключ датчика температуры, подключенный к каналу 2 хаба, "сидящего" на шине I2C по адресу 0x15 выглядит следующим образом: 'x15_2'. Понятно, что все эти адреса и ключи, как и сами объекты, генерируются автоматически.

Во-вторых, в этом же конструкторе формируется структура и начальное состояние базы данных redis. Кстати, в этой базе используются эти же ключи, как и в словаре devs. В списках redis с этими ключами как раз и хранится история параметров этих устройств. Для каждого устройства в базе данных формируется отдельная хэш-таблица для хранения кода семейства устройства, калибровочной информации и, для некоторых устройств, еще и дополнительной информации. Ключи к этим хэшам отличаются от ключей устройства наличием буквы 'i' в начале ключа. Т.е., например, ключ хэша для датчика с ключом 'x15_2' выглядит так: 'ix15_2'.

Помимо ключей, связанных непосредственно с подключенными модулями, в БД есть дополнительные ключи, через которые можно работать с другими объектами. В частности ключ 'time' связан со списком, в которых хранятся отсчеты времени, соответствующие отсчетам показаний датчиков и состояний контроллеров. Есть ключ 'status', через который клиент БД может управлять состоянием системы. Например, приостановить ее работу или вообще выключить. И ряд других ключей, о которых мы поговорим позже.

В-третьи, класс SUP содержит метод info(), позволяющий получить подробную информацию обо всех модулях, подключенных к системе.

Ну и, наконец, этот класс содержит метод sync(), позволяющий полностью синхронизировать поля БД c состоянием датчиков и контроллеров установки.

Таким образом, импортируя модуль lsync, мы получаем возможность работать как непосредственно с питоновскими объектами, так и, если нужно, с их образами в БД. Но в этом случае синхронизацию базы данных и "железа" необходимо проводить явно (вызывая метод sync() в скрипте управления). Если же мы запустим lsync как главное приложение (неважно, в фоне или в fg), то синхронизация будет осуществляться автоматически с интервалом 1 сек. В этом случае совершенно независимое пользовательское приложение (клиент redis) может ограничить свою работу только взаимодействием с полями БД redis. Их набор вполне достаточен для полного контроля над аппаратной частью системы.

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

Ну вот на этом, пожалуй, можно и закончить краткое описание модуля lsync.

---

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

1. По железу. Для аналоговых (точнее - не поддерживающих I2C или 1-Wire) исполнительных устройств необходимо будет изготовить соответствующий контроллер. Для аналоговых датчиков, если хватает точности 10-разрядного АЦП, ничего нового по "железу" разрабатывать не нужно.
2. По софту. Если устройству, по логике работы, будет невозможно "мимикрировать" под уже существующие в LITE типы устройств, то необходимо будет написать соответствующий класс-обертку и дабавить его в библиотеку lsync. В общем-то это сделать несложно. Я расскажу как это делается при случае. Например, когда будем подцеплять к системе сервомашинку или шаговик.

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

PS
В архив в приложении к данному топику, помимо lsync.py, я положил простенького консольного клиента cli.py. Это для расширенной проверки работоспособности системы. Этот клиентик позволяет посмотреть или установить текущее значение любого параметра установки (по ключу устройства), посмотреть и/или записать калибровочные данные и также посмотреть на графике динамику показаний всех температурных датчиков DS18B20, подключенных к системе (для этого на клиентском компьютере должны быть установлены библиотека matplotlib и redis-cli. Интерфейс самого клиентика в общем-то ясен из текста скрипта cli.py. Если кто-нибудь будет экспериментировать с такой системой и что-то будет непонятно - спрашивайте. Обсудим уже "по месту".

---

Добавление от 08.08.2019

Коллега ekochnev сделал добавления в модуль lsync, обеспечивающие:
1. Совместимость с версией Python 3.7.3
2. Добавлена возможность выбора в скрипте типа используемого датчика давления BMP280 или BMP180.
Модифицированный файл можно скачать из приложения к этому топику.

---

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

Нет слов, просто отлично!))

Проект обещает быть захватывающим, ещё раз респект автору. Перехожу к перепрошивке модулей и несколько запутался. Правильно ли я понимаю, что модули:
A1_RMS - это понятно, модуль RMS на контроллере Atmega 328P
A2_relay - модуль контактора также на Atmega 328P
A3_PDM - модуль управления мощностью ТЭН на Atmega 328P
A4_PWM - контроллер клапана отбора на Atmega 328P
A5_Hub - подозреваю, что это модуль температурного сервера на Atmega 328P. Так?
A6_ow_ADC - что это (АЦП?) и на чём сделан? Этот модуль в теме ещё не рассматривался.
A7_ow_MPX5010DP - это тоже понятно. Модуль остался на ATtiny85 или переделан на Atmega 328P?
==============
Все блоки прошились на раз. Вопрос по A6_ow_ADC остаётся открытым.

A6_ow_ADC - что это (АЦП?) и на чём сделан? Этот модуль в теме ещё не рассматривался.gol_avto, 08 Февр. 19, 09:38

Тут все проще. Фактически, это - такой же модуль, что и MPX5010DP, только без самого датчика. Т.е. 10-разрядный АЦП с 1-Wire интерфейсом. К нему можно подключить любой аналоговый датчик с соответствующим согласованием сигнала. По схеме это тоже что и датчик диф.давления, только без самого датчика. Прошивка - та же.