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

OldBean, Что такое - "на обычный, маленький сетевой UPS-ик с USB".

Что такое - "на обычный, маленький сетевой UPS-ик с USB"us_ov, 18 Авг. 19, 12:14

Все, конечно, относительно... Я поставил Ippon Back Basic 650 Euro 360 Вт. По сравнению с остальными (моими) UPS-ами он действительно маленький, легкий и очень тихий.

Здесь тоже есть стандартные, простые и готовые решения. Это UPS (ИБП). Вначале я использовал 5-вольтовый UPS, совмещенный с 5-вольтовым источником питания. Но он 2-амперный. Для третьей малинки - это почти на пределе, а для 4-й, которую собираюсь попробовать, уже откровенно мало. Поэтому перешел на обычный, маленький сетевой UPS-ик с USB.

При исчезновении питающей сети, такой UPS будет держать малинку в рабочем состоянии столько, сколько потребуется. Использовать в данной задаче UPS-овый USB, конечно, никакого смысла нет. Об исчезновении напряжения в сети малинка сразу же узнает от датчика RMS и примет адекватные меры по корректному завершению работы. Как оборудования, так и себя...OldBean, 18 Авг. 19, 10:37

Стандартный UPS конечно хорошо, только надо 2 входа питающей сети к нашей системе тянуть. Первый, не гарантированного питания (не от UPSа), на питание крейта, второй от UPSa на AC/DC 5В.
Иначе смысла нет...

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

Для копилки.
Для малинки шляпа есть, которая есть продвинутый UPS, заточенный под потребности малинки, вот только ценник £47.99 GBP....
https://uk.pi-supply.com/products/pijuice-standard


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

Со стороны малинки я собираюсь подключить эту линию к 11-ому пину малинки (GPIO_GEN0). ИМХО, использование 7-го пина малинки (GPIO_GPCLK - General Purpose CLock) для этой цели - не очень хорошая идея. Лучше, таки, задействовать пины общего назначения.OldBean, 18 Авг. 19, 10:37

Сделал корректировку на 11 pin. Тут я спорить не буду. Перезалил в пост
[сообщение #13564328]

После некоторых размышлений было принято решение задействовать линию GND, расположенную между линиями SCL и Zero.OldBean, 18 Авг. 19, 10:37

Я бы все таки окружил I2C земелькой, на всякий "пожарный"

Стандартный UPS конечно хорошо, только надо 2 входа питающей сети к нашей системе тянуть. Первый, не гарантированного питания (не от UPSа), на питание крейта, второй от UPSa на AC/DC 5В.BogAD, 18 Авг. 19, 16:58

А зачем две тянуть-то? Одной вполне хватит. UPS-то рядом стоит. Силовая часть питается от незащищенной сети. К ней же подключен и вход датчика RMS. Малинка с монитором запитаны от этой же линии, но только уже через UPS. Низковольтная часть крейта (по 5В и 3.3В) запитана от gpio малинки. Поэтому модули (в том числе и датчик RMS) сохраняют работоспособность при выключении питания. Хотя сам датчик RMS измеряет незащищенную (пропавшую) сеть.

Сделал корректировку на 11 pin.BogAD, 18 Авг. 19, 16:58

Хорошо. Давайте на этом варианте и остановимся. Int у нас подключен к 29-ому пину малинки. Тоже давайте не будем менять.

Я бы все таки окружил I2C земелькой, на всякий "пожарный"BogAD, 18 Авг. 19, 16:58

Я бы тоже... Но 3.3В жальче... Параллельно рядом с каждой линией i2c (SDA и SCL) оставлено по одной возвратной земле. Думаю, для надежной компенсации внешних наводок, такой топологии вполне хватит. Все-таки в этой системе достаточно низкий уровень наводок. Слава великому PDM и его пророку Брезенхему! :)

Но 3.3В жальче...OldBean, 18 Авг. 19, 18:31

Я против лишней "антенны" в шине крейта.
Вангую - кроме BMP, 3.3В ни куда не припрётся.
Мою позицию знаешь... или есть в планах замутить  модуль на 3.3В? Типа esp?

Вангую - кроме BMP, 3.3В ни куда не припрётся.BogAD, 18 Авг. 19, 21:54

Пожалуй, соглашусь. В данном варианте системы, действительно, вряд ли еще что-то 3.3-вольтовое появится на шине. В конце концов всегда можно поискать 5-вольтовый аналог или, на худой конец, несложно получить 3.3В из 5В прямо на плате/переходнике к устройству. Хорошо. Снимаем этот вопрос. Как нибудь, "под настроение" перетащу Res на линию 3.3В, а BMP-шку воткну в переходник между малинкой и крейтом. Сейчас совсем не хочется железом заниматься - голова софтом забита.

Я против лишней "антенны" в шине крейта.BogAD, 18 Авг. 19, 21:54

А вот с "антеннами" обсудить было бы интересно. Ну и, наверное, познавательно :) Где Вы видите антенну? Топологически земля в крейте представляет собой решетку (лестницу): параллельно идут земляные линии, которые внутри каждого модуля замыкаются между собой сплошной перемычкой. Больших петель вроде бы нет. Отдельно висячих линий тоже. Рядом с каждой (сигнальной) идет "возвратная" земля. Что-то я не "догоняю": где же антенна?

А вот с "антеннами" обсудить было бы интересно.OldBean, 19 Авг. 19, 05:34

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

Понятно. Речь шла об источнике помехи. А я-то подумал про "антенну приемника". Т.е. что какой-то элемент в данной топологии разводки будет хорошо ловить внешнюю помеху. Как антенна.

---

Хорошо. Перестраховываемся и убираем линию 3.3В из низковольтной шины крейта.

Наконец дошли руки до изготовления датчика кубового давления. Собрал, он опознался, как-то заработал, но не разобрался как его калибровать. В документации к api есть для этого волшебная строчка:

cset('P0', 0.0734, 38, 5)

Если к первому и последнему параметру вопросов не возникает, то что за магическое число 0.0734 и почему его нужно записывать со смещением 38 (хотя для других модулей калибровочные данные писали со смещением 0) я к сожалению не понял. Указанную выше строчку я конечно выполнил, но понимания это не принесло. Сейчас не подключенный ни к чему датчик лежащий горизонтально выдает значение 0.0734 (хотя в моем понимании должен 0 показывать - он же дифференциальный и обе трубки ни к чему не подключены), если полежит подольше, то может и 0 показать, а если расположить вертикально, то всегда показывает 0.1468, но если дунуть в одну из трубок, то значение увеличивается до нескольких десятков.
Так и должно быть?

как его калибровать.ekochnev, 19 Авг. 19, 21:31

Показания датчиков (в мм.рт.ст.) вычисляется так: P = coef*(ADC_code - offset).

coef - это первое число в тройке калибровочных данных (в данном случае это 0.0734). Оно служит для перевода кода АЦП в мм.рт.ст. Если установлен датчик MPX5010DP, то максимальный код АЦП (у тиньки 10-разрядный - 1024) соответствует перепаду давления 10кПа. Отсюда и вычисляется этот коэффициент.

offset - необходим как раз для того, чтобы при открытых конца был 0 (эти датчики обычно имеют небольшое смещение). Поэтому, в отличие от большинства других устройств в системе, этот параметр здесь ненулевой. У Вас, судя по значению давления, смещение на единичку больше, чем у меня. Поставьте offset = 39. Смысла в этом немного, т.к. +-1 квант ничего не решает. Кроме этого, у датчиков еще есть небольшой дрейф. Да и какая-то температурная зависимость тоже должна быть... Кстати, слишком сильно не дуйте! MPX5010DP - он же до 10 кПа (75 мм.рт.ст.)

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

Сергей, можно поподробнее про вот эти установки:

  vset('w0', 600) - установить мощность нагревателя, подключенного к 0-му
    контроллеру PDM на 600 Вт (по номиналу, без учета напряжения в сети)
  vset('w0', 600, 232) - установить мощность нагревателя, подключенного к 
    0-му контроллеру PDM на 600 Вт с учетом напряжения сети. Здесь 232 - 
    RMS напряжения сети, измеренное датчиком RSM.

Что значит "с учетом напряжения" и "без учета"? Я так понял, что после одной из команд при изменении напряжения сети установленная выходная мощность не изменится и останется на выходе стабилизированной, а после другой команды мощность будет меняться в ту же сторону что и напряжение. Только не совсем ясно какая из них какая... :-) И еще, если я прав, то при чтении как понять какой из режимов перед этим был установлен? Пробовал у себя задавать vset('w0', 2000) и vset('w0', 2000, 220) и хотя после этого напряжение сети немного плавало vget('w0') всегда выдавал ровно 2000.
Попробовал задать vset('w0', 2000, 200), тогда vget стал выдавать 2420. Откалибровано на тэн 3 кВт. Не понял как получилось 2420.

И еще: сквозная нумерация ключей в базе - это прекрасно, только получается, что элементы к которым данные ключи относятся бывают встроенные и внешние подключаемые. В основном это неудобства не доставляет, кроме случая с давлением. Датчик атмосферного давления BMP - встроенный, он всегда есть в системе, его невозможно извлечь, а датчик(и) кубового давления - внешне полключаемые: они могут быть и могут не быть в разных конфигурациях. Когда их нет, датчик атмосферного давления числится как P0, а когда подключаются датчики кубового давления, то он сдвигается как Р1 или Р2 в зависимости от кол-ва внешних датчиков давления из-за того, что сидит на шине с самым старшим адресом 0х77. Может быть в данном случае внести исключение в опрос шины и искать сначала неубираемые атмосферные датчики, чтобы он вставал всегда как Р0? Иначе при перетыкании проводов одна и та же сущность появляется под разным именем что вызывает в голове небольшой диссонанс. :-) С остальными ключами вроде такого случиться не может... Можно не менять алгоритм опроса, а просто именовать атмосферные датчики другой буквой: Ра0, а кубовые другой Рс0, Рс1... Как Вы на это смотрите?

И еще: сквозная нумерация ключей в базе - это прекрасно, только получается, что элементы к которым данные ключи относятся бывают встроенные и внешние подключаемые.ekochnev, 20 Авг. 19, 19:22

Поясню почему принято именно такое решение.

Цель проекта (LITE) - попробовать сделать максимально гибкую и универсальную систему кубовой  дистилляции/ректификации. Как с точки зрения состава оборудования, так и с точки зрения различных алгоритмов проведения процессов. Причем так, чтобы изменение конфигурации системы не требовало бы перепрограммирования управляющего софта. Чтобы пользователю нужно было бы только воткнуть в систему нужные модули и объяснить малинке только логику процесса на каком-нибудь очень простом языке. В такой постановке как раз заключается вся сложность и интерес данного проекта. Ну, по крайней мере, для меня.

Обеспечение гибкости по части железа уже решена. За счет использования трехуровневой архитектуры (железо-редиска-пользователь) и концепции a la "plug and play". От конкретной реализации оборудования пользователь полностью абстрагирован. Втыкай что хочешь и куда хочешь. Система все это сама распознает и создаст всю необходимую инфраструктуру для создания скриптов управления. В данном случае - набор соответствующих экземпляров классов всех устройств. Питоновских.

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

Но тут вдруг "совершенно неожиданно" :) возник вопрос:"А как быть пользователю, который не умеет программировать на питоне?" И я почему-то решил подумать в этом направлении... Так сформировалась задача разработки универсального софта для варианта LITE. Задача оказалась увлекательной, но весьма и весьма нетривиальной. И "хвост" немного увяз... Сейчас, похоже, в голове все более-менее "уложилось". Может быть удастся реализовать эту задачу в разумные сроки.

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

Ну и теперь конкретно по Вашему вопросу.

В данной системе нет "встроенных и внешних подключаемых" устройств. Они все подключаемые. Самая минимальная конфигурация системы - всего один ТЭН и термодатчик в бачке (например, для простой перегонки осветленной бражки на сырец). В принципе, даже градусник можно убрать. Если бражка примерно одинаковая, то можно перегонять просто по таймеру. Таким образом, минимальная аппаратная конфигурация системы - это один ТЭН с контроллером PDM, который системе будет известен как w0 :) Скрипту нужно будет только включить нагрев v.w0 = 2000 и проверять в бесконечном цикле условие: if v.time >= tMax: v.w0 = 0; break. Ну а "максимальная" конфигурация - пара-тройка ТЭН-ов, несколько устройств отбора, переключатели потоков спирта и куча всевозможных датчиков. Ну и скрипты соответствующие... Легко видеть, что, при таком разнообразии, выделение каких-то устройств в отдельную "привилегированную" группу - не очень хорошая идея.

Сергей, можно поподробнее про вот эти установки:
...
Что значит "с учетом напряжения" и "без учета"?ekochnev, 20 Авг. 19, 19:22

Система должна уметь работать как с датчиком RMS, так и без него. Если напряжение питающей сети примерно 220 В и колеблется в пределах +-5-10 В (у меня дома, например, так), то номинальная мощность ТЭНа (при 220 В) будет не сильно отличаться от реальной. В этом случае, при автоматическом регулировании скорости отбора, стабилизировать (корректировать) мощность нагрева не обязательно. В такой ситуации датчик RMS не обязателен и можно задавать мощность нагрева, просто руководствуясь номинальной мощностью ТЭНа. В этом случае функция установки мощности нагрева принимает только один параметр - желаемая мощность нагрева в ваттах (второй параметр rms по умолчанию равен None). В данной ситуации система работает так, как будто в сети напряжение точно 220В.

Если же сеть смещена и/или колеблется в более широких пределах - необходимо учитывать напряжение сети при установке мощности. Поэтому в функции установки мощности ТЭНа предусмотрен еще один параметр - среднеквадратичное напряжение сети (rms). В этом случае система, при при отправке контроллеру запроса на установку мощности нагрева, будет ориентироваться на реальное напряжение в сети. Она (система) думает примерно так: "Ага, пользователю нужно 600Вт, а напряжение в сети сейчас 200В, значит я должна попросить контроллер PDM установить номинальную мощность 600*(220/200)^2 = 726Вт; тогда в реальности (по нагреву) получится как раз те самые 600Вт.". Поскольку PDM - это линейный регулятор, то коэффициент пересчета получается очень простой: coef = (220/rms)^2. Контроллер PDM туповат - он всегда работает с процентами от номинальной мощности. И, в глубине своего МК, всегда уверен, что работает с сетью ровно 220В :))) За него думает малинка (точнее - синхронизатор).

---

PS
Про PDM можно почитать здесь.

В данной системе нет "встроенных и внешних" устройств.OldBean, 21 Авг. 19, 04:38

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

выделение каких-то устройств в отдельную "привилегированную" группу - не очень хорошая идея.OldBean, 21 Авг. 19, 04:38

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

пользователь не имеет возможности отключить датчик атмосферного давления.ekochnev, 21 Авг. 19, 05:58

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

"Жестких" автоматик (в том числе и просто великолепных!) хоть пруд пруди...

Если пользователь ограничен в изменении конфигурации железаOldBean, 21 Авг. 19, 09:31

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

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

Не понял этой фразы: что значит "если", разве это не так?
Мы размещаем датчик атмосферного давления стационарно на крейте, остальные датчики вижу подключаемыми к разъемам...ekochnev, 21 Авг. 19, 09:45

Не так. Во-первых, разместить датчик атмосферного давления на плате крейта и, в связи с этим, убрать линию 3.3V из общей шины - это решение Александра. У меня датчик атм.давления втыкается в любое гнездо крейта наряду с датчиком RMS, контроллерами, хабами и любым другим i2c-устройством, которые в принципе могут понадобиться. Во-вторых, крейт (у меня) - это открытый стенд. Втыкание/вытыкание i2c-устройства занимает практически столько же времени, что и подключение 1-Wire устройства к хабу. Поэтому для меня этот датчик атмосферного давления ничем не выделен.

У меня датчик атм.давления втыкается в любое гнездоOldBean, 21 Авг. 19, 10:17

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

Во-вторых, крейт (у меня) - это открытый стендOldBean, 21 Авг. 19, 10:17

Сейчас - да, открытый, а дальше? Вы это так заявляете, как будто не планируете довести проект до какого-либо логического завершения и так и хотите навсегда оставить его открытым стендом. Я же считаю продукт законченным когда он находится в корпусе и пользоваться им может не только тот кто его создал. Возьмем, к примеру персональный компьютер. Там такой же крейт внутри - материнская плата в которую вставлены платы расширения. Пользователь работает за ним и не думает, что там натолкано внутри. Он может подключить к нему любое количество внешней периферии через предоставленное ему число внешних разъемов и все будет работать. Однако внутрь пользователь обычно не лазит. Для этого приходит сисадмин и подключает/отключает платы внутри корпуса производя при этом специфичную настройку. Так и я видел будущее этого проекта - законченное изделие в корпусе в котором установлен какой-то набор плат расширения - модулей. Приходит ко мне друг: дай попользоваться! А что будешь делать? - Брагу перегонять на сырец. Держи: вот тебе коробка, вот тебе один датчик температуры к ней иди перегоняй. В другой раз приходит: буду ректификат делать - держи коробку, клапан отбора, три датчика температуры и датчик кубового давления. А когда сам буду гнать, то у меня еще датчики в ПБ и ЦП стоят, плюс на воде на входе и на выходе, плюс два клапана отбора, плюс клапан на воду и т.п плюс еще много чего с полным фаршем...

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

Возьмем, к примеру персональный компьютер.ekochnev, 21 Авг. 19, 11:13

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

Иначе с таким подходом: выдергиваю когда хочу и что хочу и программа должна работать можно договориться, что и RMS можно выдернуть и все должно работать и силовой модуль тэна можно выдернуть, они же тоже в разъемах стоят, не так ли?.ekochnev, 21 Авг. 19, 11:13

Возможно Вам покажется это странным, но именно так и задумывалось. Можно и без датчика RMS работать (вокнуть копеечный детектор нуля на шину Zero). А можно даже и без ТЭНа :) Если, например, жесткий лимит на электроэнергию или на мощность. Вы можете представить контроллер для газового нагревателя? Я - легко. Это, конечно, совсем не означает, что в жизни я буду греть куб газом и питать автоматику от солнечных батарей. Или сделаю автоматику на пневматике. Кстати, отличный пример такой автоматики демонстрировал уважаемый коллега Zapal. Слава Богу энергии и воды пока хватает! Но мне очень хотелось бы понять: можно ли сделать действительно реальную, но полностью универсальную автоматику для данного класса задач? Безо всяких ограничений (ни в железе, ни в алгоритмике управления). Причем, особый вкус этой задаче придает условие, чтобы алгоритмику мог задавать не программист.

Должен быть определен минимальный набор оборудования, который считаем стационарно установленным.ekochnev, 21 Авг. 19, 11:13

Конечно должен. Но он может быть разным.

---

Мне кажется, что мы сильно углубились в философию.

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

не со младших i2c адресов, а наоборот со старшихOldBean, 21 Авг. 19, 12:37

Это тоже не совсем хорошо. Чревато тем, что при апгрейде системы и установке следующих однотипных модулей у предыдущих будет сдвигаться именование ключей. Например, установили вторую плату контактора в крейт с адресом, например, 0х16, после этого тот контактор что был до этого превратится из r0 в r1, а новый контактор станет r0. И надо будет софту объяснять, что сейчас общее питание надо включать через r1, а не через r0, а r0 сейчас стал включать автономку охлаждения. Ну и так с остальными...

А чем Вам мысль именовать датчики атмосферного давления по-другому в отличие от кубовых не нравится? Тогда не будет всей этой чехарды. Ведь я приводил пример как у Вас сделано с устройствами Zc и Zo.

P.S. Картинка с компом хороша! Но это Вы умеете за таким работать и я умею. А моя мама-старушка к такому даже подойти побоится, а младший сын через полчаса колой обольет и чипсами засыплет и все работать перестанет. Ладно, не буду больше про это. :-)

А чем Вам мысль именовать датчики атмосферного давления по-другому в отличие от кубовых не нравится? Тогда не будет всей этой чехарды.ekochnev, 21 Авг. 19, 12:53

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

---

PS
А именовать датчики давления в кубе и в атмосфере с разными префиксами несложно. Но это не решает проблемы. Ну появится еще датчик давления (по типу атмосферного) где-нибудь в колонне или буфере. Атмосфера стоит на 0x77, а новый, скажем, станет на 0x76. И номер у атмосферного датчика опять поплывет. Или что? Еще один префикс заводить?