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

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

Итак, если я правильно понял, Вы предлагаете поступать так:

1. На уровне альфа-бета версий первая цифра всегда будет 0. Это пререлизы.
2. Если серьезные изменения концепции и функционала - изменяем вторую цифру.
3. Если небольшие изменения функционала - инкрементируем третью цифру.
4. Всякие мелочи, связанные с исправлением ошибок - меняем последнюю цифру.

Я правильно понял? Если да - давайте так и будем делать. Это вполне логично.

Да, абсолютно верно! Спасибо!

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

P.S.S. Ну и добавлю на всякий случай очевидную вещь: при изменении любой цифры, все остальные правее нее обнуляются. Изменили третью цифру - четвертая обнулилась, изменили вторую - третья и четвертая обнулились. У Вас до этого так и было, давайте менять не будем. Просто существует и альтернативный подход к нумерации когда четвертая цифра хранит сквозной номер изменения за весь жизненный цикл продукта, но это приводит в итоге на мой взгляд к не очень удобным номерам версий типа 1.5.9.21344 и т.п. - здесь у нас не тот случай, чтобы это было целесообразно.

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

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

Поэтому каких-то серьезных проблем с нумерацией версий вроде бы и не ожидается. Ну появится что-нибудь типа 0.4.1.x...

на данный момент запланирована только одна серьезная "перетряска". Она затронет прошивки контроллеров и потребует модификации соответствующих классов.OldBean, 15 Апр. 20, 08:12

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

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

А можно в функцию temp добавить номер режима, кажется было бы довольно наглядно

А можно в функцию temp добавить номер режима, кажется было бы довольно наглядноnubsaybot, 15 Апр. 20, 18:37

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

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

Есть большая просьба - если будут обновляться прошивки контроллеровsig, 15 Апр. 20, 14:06

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

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

Поясню.
Есть контроллер ТЭНа откалиброванный на 3000 Вт. А я отправляю в него команду выдать мощность 5000 Вт. И он ее нормально воспримет. И если я потом прочитаю значение из контроллера, то он радостно доложит, что работает на 5000 Вт. А по-хорошему, он должен был при записи обрезать 5000 до 3000 и при последующем чтении выдавать мне число 3000.
Аналогично с клапанами. Клапан откалиброван на максимальный отбор 2000 мл/час, а я его могу попросить 10 литров в минуту выдавать. Он конечно выдавать не будет, т.к. физически не может, но при чтении будет говорить что работает именно с такой скоростью. И счетчики расхода будут неправильно считать.

Важна точка (отметка) смены одного режима на другой чтобы была возможность оценить при каких параметрах это произошло.ekochnev, 15 Апр. 20, 18:57

Целиком поддерживаю

заложить в протокол контрольную сумму посылки.sig, 15 Апр. 20, 14:06

Да. Вопрос с контролем обмена по i2c уже давно назрел. Даже перезрел. Но здесь нужно внимательно проанализировать не приведет ли изменение длин блоков к каким-нибудь проблемам в других местах. Поэтому введение контрольной суммы в протокол каждый раз откладывалось :( Не хотелось бы рушить обратную совместимость. Прошивка - дело хлопотное, туда-сюда каждый раз не будешь же перепрошивать... Попробую в этой "перетряске" прошивок как-то порешать этот вопрос.

А можно в функцию temp добавить номер режима, кажется было бы довольно наглядноnubsaybot, 15 Апр. 20, 18:37

Номер режима протоколируется синхронизатором в редиске под ключом b'moden'. В функции temp() модуля api список величин, значения которых которые будут записаны в текстовый файл, формируется в самом начале функции сразу после комментариев (строки 258-261 файла api.py):

  keys = []
  for key in rdb.hkeys('calibr'):
    if key[0] in [ord('T'), ord('q')] or key == b'time':
      keys.append(key)

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

  keys.append(b'moden')

сразу после приведенного выше фрагмента (т.е. сразу после строки 261). После этого в файле temp.txt появится еще одна колонка с номером режима. Ну и помним про питоновские отступы для блоков кода! Новая команда - уже после цикла. Т.е. - два отступа влево, относительно инструкции с номером 261.

Важна точка (отметка) смены одного режима на другой чтобы была возможность оценить при каких параметрах это произошло.ekochnev, 15 Апр. 20, 18:57

Я уже писал коллеге nubsaybot выше, что история номеров режимов записывается в редиске. Для удобства, с режимом связаны два поля: b'mode' - это скаляр, текущее значение режима и поле b'moden' - список номеров режимов в каждый момент времени (организация списка и временные привязки такие же как для температур, напряжения и т.п.) Анализируя этот список (с ключом b'moden'), Вы всегда можете определить моменты времени, в которые режим менялся и, соответственно, значения других параметров в эти моменты времени. К сожалению, редиска - не RDB и не позволяет непосредственно делать запросы, связанные с данными. Поэтому время выполнения этой операции будет порядка O(N). При неспешном анализе это некритично. В крайнем случае, учитывая тот факт, что номер режима это целые числа, можно воспользоваться numpy или какими-нибудь другими специализированными библиотеками для анализа длинных списков.

Уже писал как-то выше, повторюсь.ekochnev, 15 Апр. 20, 18:57

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

---

---

Чтобы не откладывать в долгий ящик, поправил классы Relay, PDM и PWM на предмет учета предельных значений. Теперь в геттерах учитываются предельные значения контроллеров. Ограничения, как и раньше учитываются по коду, посылаемому устройству (макс равен 1 для Relay, 100 для PDM и 1000 для PWM). Исходя из этих значений и калибровок устанавливается возвращаемые значения физических величин. Это, конечно, тоже "затычка", но по крайней мере не будет смущать пользователя и должен правильно считаться расход. Скорректированный файл библиотеки lite - в приложении к данному топику.

Посмотрел код 0.4.0.2

А зачем такие сложные вычисления в сеттерах?
Почему просто первой строчкой сеттера не ограничить задаваемое значение:

  @val.setter
  def val(self, value):
    value = min(value, self.calibr[0])
    # а дальше оставить все как было в 4.0.1

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

Я больше склоняюсь к железу.OldBean, 16 Апр. 20, 07:16

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

А зачем такие сложные вычисления в сеттерах?ekochnev, 16 Апр. 20, 13:19

Для этого есть несколько причин.

1. Обмен с контроллерами ведется не вещественными числами (ваттами, мл/час, вольтами), а целыми числами - кодами. Как раз максимальные и минимальные значения кодов для контроллеров абсолютны. А для физических величин - нет. Например, для контроллера PDM это 0 (%) минимум и 100 (%) максимум. Это будет всегда, независимо от того, что код 100 может соответствовать мощности как 1500 Вт, так и 3000Вт. Для контроллеров PWM это - от 0 до 1000 (в десятых долях процентов), тоже назависимо от калибровок клапана. Поэтому, при фразе w0.v = 4000.0, сначала вычисляется код, который необходимо послать контроллеру, затем этот код обрезается (если от превышает 100% мощности) до 100, затем этот код (100) посылается контроллеру, а атрибуту self._val присваивается значение физической величины, соответствующее максимуму. Уже при помощи калибровочных данных.

2. Есть еще один момент. Я на нем специально не акцентировал внимание сейчас, чтобы не погружаться в "философские" вопросы, связанные с нужностью/ненужностью стабилизации мощности нагрева. Но, если PDM управляет мощностью нагрева ТЭНа, то максимальная мощность совсем не обязана быть равной номинальной мощности, которая указана в коэффициенте calibr[0], т.к. максимальная мощность нагрева зависит еще и от напряжения в сети (U0). Т.е. должна вычисляться так: self._val = 100*calibr[0]*((U0/220.0)**2). А если PDM-контроллер управляет не нагревом ТЭНа, а каким-нибудь другим устройством, то и максимальное значение модуляции контроллера (100%) может иметь совсем другой смысл и вычисляться совсем по другому. Таким образом, в ряде ситуаций, ваше решение не будет давать 100% возможной мощности нагрева.

3. Ну и третье. Исторически сложилось так, что обмен с устройствами ведется целочисленными кодами. Физические величины и калибровки - это всего лишь надстройки, облегчающие программирование. Поэтому команды w0.code = 100; w0.v = 98765; w0.on() эквивалентны. Но первая - первична. Иногда непосредственная работа с кодами бывает удобней.

PS

получается, что если использовать lite, то это будет работать, а если обращаться напрямую через api или из скриптов синхронизатора, то это не отработает.ekochnev, 16 Апр. 20, 13:19

Отработает. api работает через редиску (и, естественно, синхронизатор), а синхронизатор работает через lite.

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

Так не проще сначала ограничить на входе вещественную value До максимального значения,ekochnev, 16 Апр. 20, 14:20

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

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

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

К примеру в контроллер записано 3000 Вт, а когда происходит чтение, то можно указать текущее напряжение и эта величина превратится в 3050 или 2950. Аналогично в сеттере указывать текущее напряжение и желаемую мощность и в контроллер запишется отнормированная относительно 220. Тогда не будет ситуации когда контроллер откалиброван на 3000 а в нем записана текущая величина 3500, причем непонятно при каком напряжении эта величина была высчитана.

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

А для того чтоб контроллер был стабилизатором, он как минимум должен быть совмещен с RMS чтобы самостоятельно без внешних команд отслеживать отклонение напряжения от номинального и корректировать в зависимости от этого число прошедших в нагрузку полупериодов...

Интересную железяку нашел у желтых братьев!

https://aliexpress.ru/....54f833edcqGINW
Не удержался, заказал...

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

Коллеги, прошу сильно не пинать и подсказать, как доработать плату контролера ТЭНа на 3 Квт.

как доработать плату контролера ТЭНа на 3 Квт.ganj_steel, 01 Мая 20, 22:35

А зачем дорабатывать? Судя по datasheet, BTA16 вполне тянет 3 кВт. Вместо BTA16 можно поставить симистор и с запасом - BTA20.

PS
Ну а если просто сеть плохая и сильно просаживается от 3 кВт, то лучше использовать два ТЭНа. Один разгонный (на пару кВт), подключенный, например, к релейному модулю, второй рабочий (на один-полтора кВт), подключенный уже к регулируемому контроллеру (PDM). При разгоне работают оба, а в рабочем режиме - только регулируемый от PDM.

А зачем дорабатывать? Судя по datasheet, BTA16 вполне тянет 3 кВт. Вместо BTA16 можно поставить симистор и с запасом - BTA20.OldBean, 02 Мая 20, 06:32

Спасибо за ответ. Тоже почитал, что 16А как раз соответствует 3кВт. А BTA16 рассчитан как раз на 16А. Но автор схемы сделал двукратный запас в схеме и подозреваю не от щедрой души. Если поставлю ВТА20 или ВТА25 то следует ли остальную обвязку изменить? Может емкости изменить или схема усложнится?

Ну а если просто сеть плохая и сильно просаживается от 3 кВт, то лучше использовать два ТЭНа. Один разгонный (на пару кВт), подключенный, например, к релейному модулю, второй рабочий (на один-полтора кВт), подключенный уже к регулируемому контроллеру (PDM). При разгоне работают оба, а в рабочем режиме - только регулируемый от PDM.OldBean, 02 Мая 20, 06:32

Сеть хорошая, новый МКД. Да и на руках один ТЭН на 3кВт

Если поставлю ВТА20 или ВТА25 то следует ли остальную обвязку изменить?ganj_steel, 03 Мая 20, 09:56

Остальную обвязку можно не менять. У меня в модулях стоят от BTA08 до BTA25 без изменений. Изменения нужны только в снабберной RC-цепочке в зависимости от типа нагрузки: это пассивный ТЭН или, допустим, индуктивная нагрузка в виде обмотки контактора. Сергей об этом писал когда схему публиковал.