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

Шину +3.3 конечно отключал. При этом шум на пине +3.3 малинки становится схожим по спектру и амплитудам шуму на +5, что имхо вполне логично. Остальные шумы при подключении +3.3 похоже чистой воды внешние наводки от близко расположенных других шин и прочих электромагнитных помех в корпусе. Особенно влияют пиковые помехи при срабатывании контактора (даже если подключена только обмотка и он ничего силового не коммутирует). Также проскакивают помехи если руками включать второй вспомогательный дифавтомат, расположенный тут же рядом на рейке. Короткие импульсные выбросы +-0.5-1.5 вольт без заметной периодичности. Т.е. если не щелкать контактором или еще чем-то, то вся схема может работать нормально в более-менее устойчивом состоянии. Если щелкнуть контактором или включить второй дифавтомат, то малинка ловит помеху на INT и вырубает все модули.

шум на пине +3.3 малинки становится схожим по спектру и амплитудам шуму на +5ekochnev, 17 Февр. 20, 07:13

Меняй блок питания 5В. Это очевидно...

Меняй блок питания 5В. Это очевидно...BogAD, 17 Февр. 20, 09:31

Согласен, для меня это тоже было очевидно... :-)
Уже менял, практически в первую очередь. Не помогло.

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

В том то и дело, что уровень помех на шине +5 вполне приемлемый всегда. На шине +3.3 КОГДА ОНА ОТСОЕДИНЕНА ОТ КРЕЙТА, шум такой же как на +5, т.е. тоже приемлемый. А вот когда +3.3 соединяем с крейтом (там к ней присоединены только ВМР180 и подтягивающий резистор на INT), то уровень шумов на +3.3 сильно возрастает и гадит на INT вынуждая малинку обрабатывать прерывание.

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

Тут подумал, а может и наоборот: не +3.3 гадит на INT, а наоборот: наводка идет на INT и пробивается с него через подтягивающий резистор уже на +3.3...

На шине +3.3 КОГДА ОНА ОТСОЕДИНЕНА ОТ КРЕЙТА, шум такой же как на +5, т.е. тоже приемлемый. А вот когда +3.3 соединяем с крейтом (там к ней присоединены только ВМР180 и подтягивающий резистор на INT), то уровень шумов на +3.3 сильно возрастает и гадит на INT вынуждая малинку обрабатывать прерывание.ekochnev, 17 Февр. 20, 09:39

Вероятно петля "шина 3.3V -> подтягивающий резистор -> шина INT" как раз и ловит наводку. Нужно эту петлю убрать. Как уже обсуждали выше (перенести резистор на малинку или включить внутреннюю подтяжку).
PS
И все-таки, повесьте небольшую емкость на INT около малинки (к земле, керамика, сотню нан). Не повредит.

По типу "из пушки по воробьям":
1. Между 29 ногой малинки и шиной INT попробовать резистор Ом на 200 ?
2. Стабилитрон между 29 ногой малинки и ее GND ?
3. Какая-нибудь оптопара на 29-ю ногу малинки ?
4. Какой нибудь TVS... Только понять на сторону 5В или 3.3В ?

ekochnev, Очень интересует судьба "больного"! Удалось ли победить ложные INT? Просто мне тоже это предстоит!

Удалось ли победить ложные INTsig, 04 Марта 20, 12:53

Все сложно. :-)
Кратко: в том варианте как у меня все было сделано кардинально победить не удалось.

Срабатывание модулей на помехи по шине INT удалось победить полностью после того как я поставил диод по схеме которую выкладывал чуть раньше, а вот малинка продолжала иногда срабатывать на сигнал по этой шине и, как следствие, отрубать после этого все модули. Частично помогли куча конденсаторов (керамика + электролит) в разных местах на шинах питания крейта, плюс керамический конденсатор между землей и самой шиной INT. Очень помогла замена проводов и прокладывание всего соединения между малинкой и крейтом попарно проводами из витой пары: 5в и земля, 3.3в и земля, SDA и земля, SCL и земля, INT и земля. Без подключенной обмотки контактора работало все идеально, а при подключенном контакторе лучшее что удалось добиться - это нормальные срабатывания 9 из 10 раз или даже 19 из 20.

Меня достигнутый результат не устроил.

В прошлые выходные развел новый крейт. Пока на монтажной плате. Кардинально переработал. Сделал везде больше "земли" для исключения наводок, в том числе с двух сторон вокруг шины INT. Естествеенно, сразу же поставил вышеупомянутый диод Шоттки в разрыв шины INT с подтяжкой ее с двух сторон к питаниям +5 со стороны модулей и +3.3 со стороны малинки, предусмотрел места для размещения сглаживающих конденсаторов. Но САМОЕ ГЛАВНОЕ - я исключил провода между крейтом и малинкой. Совсем. С торца крейта сейчас стоит угловой разъем в который малинка непосредственно втыкается своей GPIO гребенкой. А так как размер малинки близок к размеру модулей, то получилось весьма симпатично, как будто сбоку еще один модуль пристыковался...
Высоковольтную часть в выходные доделать не успел, без нее все прекрасно работает. Впрочем, без нее и раньше проблем не было. На неделе закончить было некогда, работаю каждый день по 14 часов. Вот в эти выходные доделаю высоковольтную часть и буду проводить полноценные испытания. Самому интересно. О результатах доложу.

Пока приклыдываю фотку нового крейта и установленной в него малинки...

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

Просто мне тоже это предстоит!sig, 04 Марта 20, 12:53

Вы тоже УЖЕ столкнулись с подобной проблемой или просто на будущее переживаете, что начнете конструировать и столкнетесь?

Вы тоже УЖЕ столкнулись с подобной проблемой или просто на будущее переживаете, что начнете конструировать и столкнетесь?ekochnev, 04 Марта 20, 19:11

Уже столкнулся, и ситуация выглядит хуже вашей - не требуется ничем щелкать, достаточно оставить включенную систему на ночь (никуда не подключенную, просто лежащую на столе со всеми датчиками) и утром с вероятностью 90% обнаружить сообщение про сработавший INT.
Я еще попробую блок питания 5В помощнее поставить - бывают молнии на экране малинки.

Есть несколько простых правил компоновки и разводки электроники, существенно уменьшающих влияние помех:

1. Разделять аналоговые (сигнальные), цифровые и силовые земли.
2. Земляные шины сводить к одной точке (обычно на питании).
3. Избегать петель.
3. "Висячие" сигнальные линии желательно выполнять витой парой или экранированным проводом (естественно, с учетом пункта 2).
4. Печатные длинные линии желательно "обрамлять" земляными.
5. ...

Подробнее про всякие такие вещи можно почитать, например, здесь:
1. Заземление в системах промышленной автоматизации
2. 3.5. Методы экранирования и заземления

Вот в эти выходные доделаю высоковольтную часть и буду проводить полноценные испытания.ekochnev, 04 Марта 20, 19:11

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

Евгений, спасибо за решение и труды, а разводку крейта выложишь на форум?

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

Нужно?

Конечно нужно, это главное назначение форума - наглядно и доходчиво делиться и перенимать.

Нужно?ekochnev, 07 Марта 20, 16:11

Конечно же нужно и обратная сторона крейта важнее лицевой.
Просто мне похоже тоже предстоит борьба с контактором (я его еще не пробовал щелкать). Сколько у вас напряжения на крейте на +5 и +3.3?
У меня сейчас 4.95 и 3.25 - думаю, маловато. С предыдущим шнурком питания микро-USB было еще меньше (4.85) и часто выскакивали молнии на экране малинки (признак недостаточного питания). Купил БП +5В 5А, но пока пытаюсь заставить работать со старым БП (он со встроенным бесперибойником)

Вот что получилось...

Несколько комментариев:
1. Монтажка стандартная, размер 100х150 мм
2. Разъемы PBS-12 под модули по разводке совместимы с вариантом Сергея
3. Разъем PBS-6 слева для датчика ВМР280
4. Кнопки: слева Reset, справа Int
5. В зеленых кембриках просто перемычки, в красных подтягиваюшие резисторы по 10к, также можно увидеть недалеко от разъема для малинки рядом с подтягивающими резисторами установленный вертикально диод Шотки (марку не знаю, первое что дома под руку попалось)
6. Синяя клеммная колодка слева: вход питания +5в
7. Видны 9 красненьких керамических конденсаторов по 100нФ для снижения помех.
8. Четырехконтактный белый разъем для подачи 220 вольт. Два контакта на одну половину крейта (детектор нуля + модуль контактора), два контакта на другую половину крейта (остальные модули). Разъем выпаял с дохлой материнской платы компьютера из цепи питания микропроцессора. По характеристикам подходит.
9. Теперь про силовую часть. Почему я отказался от варианта Сергея и поставил разъемы PBD-20? Дело в том, что мне не очень понравилось пускать большие токи рядом с сигнальными и как следствие ставить громоздкие и дорогие латунные шины. Единственный модуль дающий большой ток - это управляющий мощностью ТЭНа. Для него в схеме опторазвязку MOC3083 и всю мелочевку вокруг нее вынес на отдельную маленькую платку, которая закреплена на радиаторе рядом с силовым симистором, а от модуля управления ТЭНом к ней идет лишь двойной сигнальный провод от ноги 2 атмеги + земля. Остальная нагрузка других силовых модулей слаботочная: это либо обмотка контакторов либо клапана отбора. В таком варианте можно использовать симисторы на силовых модулях без радиаторов, а вместо медных шин использовать разъем PBD-20. По спецификации через контакт такого разъема можно пускать ток до 1 ампера, у меня используется по 4 контакта параллельно, что с большим запасом для управления клапанами и контактором.

Вроде все, если какие-то участки не видно, пишите, перефотографирую покрупнее

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

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

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

Сколько у вас напряжения на крейте на +5 и +3.3?sig, 07 Марта 20, 16:57

На шину +5 с блока питания приходит +5.08в. Пробовал регулировать +- немного, на результат не влияет.
На шину +3.3 малинка выдает 3.28в.

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

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

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

Для работы необходим следующий минимум установленных модулей:
1. RMS (U0)
2. Контактор (r0)
3. ТЭН (w0)
4. Клапан отбора (q0)
Распакуйте содержимое приложенного архива в директорию гле у вас установлена программа, запустите синхронизатор и загрузите в него скрипт нажатием клавиши "U" выберите режим клавишей "1".

Далее информация для Сергея, ибо начинаю жаловаться что не понравилось...

1. Самое важное о чем я уже писал как-то выше: медленная реакция на нажатия кнопок. Это превращает работу в мучения. Невозможно БЫСТРО выставить нужную мощность или скорость отбора.
2. Получилось мало доступных и УДОБНЫХ кнопок на клавиатуре для управления. Все цифровые кнопки заняты под выбор режимов, что не очень имхо оптимально (а если режимов будет больше 10?). Кнопки "H", "Q" тоже заняты, хотя по идее реакцию на них можно оставить только в режиме мониторинга. Задействована еще скрытая кнопка "R", которая сейчас просто приводит к зависанию системы. Она нигде не описана, раскопал ее внутри программы - оказывается, она зарезервирована для сброса, но линия RESET пока вообще к малинке не подключена... Можно возразить: как это кнопок мало, а Контролы, Альты, Функциональные клавиши и прочие модификаторы? Они конечно есть, только вот с ними при работе по SSH в окне терминала могут быть проблемы с их распознаванием как и с кнопками расположенными справа на нумпаде...

1. Самое важное о чем я уже писал как-то выше: медленная реакция на нажатия кнопок. Это превращает работу в мучения. Невозможно БЫСТРО выставить нужную мощность или скорость отбора.ekochnev, 07 Марта 20, 18:16

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

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

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

Итак, уровни на которых можно работать с софтом:

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

2. Следующий (средний) уровень взаимодействия с "железом" позволяет инкапсулировать многие технические детали и работать с устройствами (контроллерами и датчиками) как с питоновскими объектами. Для этого разработан модуль lite.py. При его импорте автоматически анализируется состав "железа", создаются и инициализируются объекты соответствующих классов. Все объекты находятся в словаре obj и проиндексированы составным ключом (hard-ключ), состоящим их адреса устройства на шине i2c, номера канала и типа устройства. Собственно по этому ключу и осуществляется доступ к конкретному объекту. Интерфейсы классов более-менее унифицированы. Поэтому работать с ними легко. Кстати, именно этот вариант максимально удобен для "ручной" работы, который необходим при отладке оборудования или настройки автоматизируемого процесса. Никаких заметных задержек на этом уровне, естественно, тоже нет. Подробное описание классов есть в самом файле lite.py. Если кого-то заинтересует данный уровень работы - дайте знать - напишу примеры как работать на этом уровне.

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

3. Третий, самый высокий на данный момент уровень работы с системой. Как-то, в недобрый час, возникла идея повысить уровень абстракции с наивной надеждой упростить написание скриптов для пользователей-непрограммистов-нефизиков-нехимиков :). В результате появился промежуточный программный слой между "железом" и пользователем в виде БД Redis и модуля синхронизатора lsync.py. Введение промежуточного слоя позволило полностью абстрагироваться от особенностей реализации "железа" и перейти с уровня "контроллеров и датчиков" на уровень "реальных физических величин". Версии 0.3x - как раз первые полные реализации такой задумки. Результат меня вполне удовлетворил: уже не первое ведро спирта СР2 получено на этом релизе LITE :). Тем не менее, совсем избежать программирования (без потери универсальности!) не удалось. Но оно стало очень простым.

Конечно, как и в любом деле, не обошлось без "накладных расходов". В частности - необходимость ввода тактирования синхронизатора с достаточно большой длительность такта (1 или 2 сек), обусловленной временами преобразования АЦП температурных датчиков, датчика RMS и др. Поэтому слишком прямолинейная реализация элементов UI (например, установка скорости отбора с инкрементом 1мл/час или мощности нагрева с шагом 1 Вт) вряд ли будет удовлетворительной. Тем более, что такие режимы работы на этом уровне абстракции как-то вообще не планировались. Здесь реализована совсем другая логика работы. Есть понятие "режима" (mode) в котором прописываются значения всех управляющих параметров (мощность нагрева, скорости отбора соответствующих устройств отбора и т.п.), задающих данный режим работы. Эти значения устанавливаются синхронизатором автоматически (и сразу же!) при смене моды. Количество мод, для реальных процессов, обычно невелико. 6-8 параметризованных режимов типа "разгон", "холостой ход", "отбор голов" и т.п. Сам автоматизируемый процесс рассматривается как конечный автомат, совершающий переходы между разными модами при выполнении определенных условий. Если же управляющий параметр (физическая величина) зависит от случайных внешних факторов (например, мощность нагрева зависит от колебаний напряжения сети, а температурная уставка - от атмосферного давления и т.п.), то текущая коррекция этого параметра выполняется автоматически.

Чуток позже я постараюсь, уменьшить время отработки запросов на изменения значений контроллеров. Если такая необходимость действительно нужна. Но еще раз хочу подчеркнуть, что основные режимы работы системы это все-таки автоматические процессы (!). Ручной режим нужен только для отладки. В этом случае вполне можно воспользоваться средним (вторым) уровнем работы. Т.е. - непосредственно через объекты устройств.

2. Получилось мало доступных и УДОБНЫХ кнопок на клавиатуре для управления. Все...ekochnev, 07 Марта 20, 18:16

Работа в консоли синхронизатора при помощи библиотеки curses первоначально была реализована исключительно для отладки синхронизатора. Но неожиданно этот как бы "отладочный сервис" оказался очень удобным и для рутинных, отработанных, автоматических процессов. В частности, - для практической ректификации СР1 и СР2. Так эта "примочка" и осталась в синхронизаторе. Я лишь немного расширил ее функционал и с удовольствием пользуюсь им в реальных процессах. Хотя (!!!) "правильная" работа на третьем уровне - это работа отдельного клиентского приложения непосредственно с БД Redis. Клиент может быть удаленный или локальный, с GUI и т.п. Там уже можно ни в чем себе не отказывать :) С точки зрения UI.

Сегодня мне в скриптах автоматизации понадобилось две вещи:
1. импорт функций из внешнего файла
2. собственные внутренние процедуры и функции

Оказывается и с тем и с другим есть подводные камни. При прямом использовании функции import в скриптах uscript.py конвертер (conv.py) при их перобразовании ошибок не выдает, но генерирует абсолютно неправильный код uscr.py, который потом не запускается. Аналогично с собственными процедурами, если, например, в скрипте определить процедуру, а затем ее напрямую вызвать, то возникнет ошибка, хотя конвертер при преобразовании ошибок не даст.

Пример ошибочного содержимого uscript.py:

# На следующей строчке возникнет ошибка.
import myfile
# На следующей тоже ошибка
from myfile import *

def test():
  print('test')

# На следующей строчке возникнет ошибка.
test()

Решением (точнее обходным маневром) данных ситуаций может быть заключение данного кода в скрипте в заведомо истинный блок оператора if, например, следующий код отработает абсолютно нормально:

if True:
  import myfile
  myfile.proc1()

def test():
  print('test')

if True:
  test()
  myfile.proc2()

Как бы ничего сложного, но я потратил некоторое время чтобы понять почему не работает. Может кому пригодится.

Евгений, я бы не советовал использовать импорт собственных модулей в пользовательских скриптах. Проблема здесь глубже, чем просто глюки конвертера. Дело в том, что переменные или константы, которые будут храниться в БД, должны быть "объявлены" явно через присваивание (переменная = выражение). А конвертер - однопроходный. Поэтому все что внутри импорта им обрабатываться не будет. Пользовательские скрипты в LITE - это все-таки весьма ограниченное подмножество питона и предназначено для решения сравнительно простых задач - обработки условий смены режимов работы установки(конечного автомата). Не требуйте от конвертора слишком много.

С пользовательскими функциями непонятно. Доберусь до железа - посмотрю. Вроде бы они должны работать. Эта опция тестировалась. Правда в Вашем примере немного смущает print() в curses. Куда он должен печатать?

---

PS
Ну и на худой конец. Релиз еще очень сырой. Если какие-то непонятки совсем непонятные, то Вы вполне можете написать непосредственно "съедобный" для синхронизатора скрипт. Т.е. писать сразу файл uscr.py и не использовать конвертер. Шаблон файла достаточно простой. Думаю, для Вас это никаких проблем не составит. Зато все будет под полным контролем...

смущает print() в curses. Куда он должен печатать?OldBean, 29 Марта 20, 06:15

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

я бы не советовал использовать импорт собственных модулейOldBean, 29 Марта 20, 06:15

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

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

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

С пользовательскими функциями непонятно. ... Вроде бы они должны работать.OldBean, 29 Марта 20, 06:15

Не работают когда функция при вызове стоит НЕ в каком-либо блоке. В Вашем пользовательском скрипте, который Вы прилагаете вместе с версией 0.3.0.1 прописана функция fss() вот так (вырезано из Ваших исходных текстов):

'''Пользовательские функции'''
def fss(): # Простейший старт-стоп. Гистерезис - 2 кванта DS18B20
  '''Если отбор ведется и т-ра превысила уставку, то выключим отбор'''
  if q0 > 0.0 and T1 >= Tset + 0.0625: q0 = 0.0
  '''Если отбор выключен и т-ра опустилась ниже уставки, то включим отбор'''
  if q0 == 0.0 and T1 <= Tset - 0.0625: q0 = modes[mode].q0

Используете Вы ее ниже вот так:

if mode == 1: # Разгон
  if T1 > Trcr: # Закипело - переходим на холостой ход
    mode = 2
elif mode == 2: # Холостой ход; автоматического выхода из этого режима нет
  pass
elif mode == 3: # Головы; скорость отбора - 50 мл/час
  if Q0 > 200.0: # Переход в режим холостого хода после отбора 200 мл
    mode = 2
elif mode == 4: # Подголовники (оборотный спирт); скорость отбора 400 мл/час
  if ss != 0: fss() # Если включен режим старт-стопа - используем его
  if Q0 > 1000.0: # После отбора 1000 мл подголовников - переход на х/ход
    mode = 2

В этом случае все работает, т.к. вызов функции стоит внутри блока if.
А сейчас попробуйте вынести эту функцию из блока if, гарантировано получите ошибку

fss()

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

---

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

# Если я попытаюсь вывести строку 'Мax.PDM (w0):'
def ui(raw, col):
  raw += 1
  stdscr.addstr(raw, col, 'Max.PDM (w0):'; raw += 1

# То на экране в результате получу строку 'Мax.PDM (r.w0):'
# аналогичная подмена будет если в строках использовать имена других переменных

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

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

# вот так будет ошибка
my_logical_var = False

Если же переменную "спрятать" в блок if, то все заработает нормально

if True:
  my_logical_var = False

С целочисленными и строковыми переменными такого нет.
Проблем нет только с числовыми переменными. Со строковыми тоже проблема.

А сейчас попробуйте вынести эту функцию из блока if, гарантировано получите ошибкуekochnev, 29 Марта 20, 06:32

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

Еще один интересный баг присутствует при выводе строк на экранekochnev, 29 Марта 20, 06:32

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

Проблем нет только с числовыми переменными.ekochnev, 29 Марта 20, 06:32

Да. В текущей версии пользовательские переменные могут быть только числового типа. Это связано с редиской. А для логики используйте "0" и "какой-нибудь не ноль".