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

Сергей Владимирович, не передёргивайте "карты" с наивным лицом, и не ловите сам себя за "мою" руку.
Это некрасиво в любом случае.
Речь держится о том, что коллеги, идя по Вашим стопам, но не имея Вашего опыта в программировании, не могут самостоятельно решить ряд вопросов и обращаются к Вам с просьбой и предложениями, не ухудшающими универсальный функционал Вашей программы, но приближающий его к проф.уровню  и реальным навыкам Ваших последователей. Тем паче, что коллеги вложились в проект и зависли в неразрешённом недоумении. Что Вы предлагаете им в ответ? Учить "матчасть", т.е. Питон? Это нонсенс, потому что они это и сами понимают.
А за народ и я Вам предлагаю не решать, а просто написать предваряющий тему дисклеймер во избежание и пр.Asus, 22 Дек. 19, 16:43

Один мой родственник - выписал дорогой станок 3D лазерной гравировки..
Но, по причине того, что он не отягощал себя знаниями - как он будет на нем работать, станок - сдох мертвым грузом.
45 штук рублей - вылетели в трубу, ибо клиент - тупо не знал английского..

Так кто виноват, если в руки дикарю - попадет лазерный дальномер??

Саша, ты виноват, кто же ещё?)
Всё ведь знал, понимал - и не подсказал, не обучил, не облегчил. Кому больше дано, с того и спрос больший🙂.
А тут команда интересантов и сочувствующих в тематике.

Но я не понимаю почему я должен писать еще какой-то софт, который мне не нужен и абсолютно не интересен.OldBean, 22 Дек. 19, 19:02

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

Раз у Вас нет желания расслышать грамотные доводы  Евгения ekochnev, то и вопросов у меня тоже нет.Asus, 22 Дек. 19, 19:32

Ну что у Вас за дурацкая (извините!) манера общения? Менторская и обвинительная. Как у судьи последней инстанции. Ну откуда Вы можете знать мои желания!?

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

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

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

---

Могу и Ваш синхронизатор доработать на предмет калибровок и отдать Вам эту версию...ekochnev, 22 Дек. 19, 20:29

Уважаемый Евгений! Ну мне-то как раз полностью хватает текущих возможностей системы (03xx). "За глаза". Поэтому мне отдавать ничего не нужно. Но кому-то из коллег, возможно, это существенно облегчит жизнь и они будут Вам очень благодарны. Я публикую свои исходники абсолютно безо всяких ограничений на использование. Поэтому Вам не требуется моего согласия. Пишите, дополняйте, изменяйте как считаете нужным. Единственная просьба - публикуйте результат с небольшими комментариями. Либо здесь, либо в виде ссылки на внешний ресурс.

Ну мне-то как раз полностью хватает текущих возможностей системы (03xx). "За глаза". Поэтому мне отдавать ничего не нужно.OldBean, 23 Дек. 19, 04:54

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

Вы выложите вместо 3.0.1 версию 3.0.2 без учета их. Получится у меня мартышкин труд.ekochnev, 23 Дек. 19, 05:20

Да. Что-то я не подумал об этом :( А Вы можете сделать свои дополнения в виде отдельного модуля? С минимальными изменениями в самом синхронизаторе.

А Вы можете сделать свои дополнения в виде отдельного модуля?OldBean, 23 Дек. 19, 05:35

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

Докторам НЕТ! Самогонщикам ДА!

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

Докторам НЕТ! Самогонщикам ДА! 

Ну что у Вас за дурацкая (извините!) манера общения? Менторская и обвинительная. Как у судьи последней инстанции. Ну откуда Вы можете знать мои желания!?OldBean, 23 Дек. 19, 04:54

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

Точно сказать не могу, я уже не помню как там внутри синхронизатора у Вас все оформлено. Но обещаю, что попробую сделать именно так.ekochnev, 23 Дек. 19, 05:44

Внутри синхронизатора пока все "эволюционно". До глубокого переструктурирования руки еще не дошли - концепт токо-токо "откристаллизовался". Ну может в каникулы удастся почистить... Но Вы можете выполнить "калибратор" в виде обычного клиента (приложения), взаимодействующего с железом только через БД с помощью api.py. В этом случае достаточно будет обеспечить аккуратность при модификации лишь одного модуля - api.py. А там никаких радикальных изменений пока не планируется. По крайней мере - в интерфейсной части. А я со своей стороны, при "чистке" синхронизатора, обеспечу актуализацию всех рабочих переменных при любых изменениях калибровок в БД и добавлю возможность вызова Вашего калибратора по нажатию какой-нибудь клавиши. ИМХО, так мы сможем "разойтись по-хорошему" с минимальными временн'ыми затратами :)

---

PS
Если понадобится добавить в api.py дополнительный функционал - давайте добавим.

^{В копилу по освоению Python (приоритетно к 3-й версии): http://judge.mipt.ru/mipt_cs_on_python3/
Обучение достаточно несложное и практически с нуля, по крайней мере "отечественная разработка", позволит понять куда ищущему надо будет идти дальше.}

В наше время владение компьютером и азами программирования - это как обычная грамотность век назад. Поэтому лозунг "Даешь ЛИКБЕЗ!" актуален и сейчас. А питон - однозначно лучший выбор. По мощности, лаконичности и простоте освоения. Кстати, есть MicroPython. Это Python 3 для микроконтроллеров. Есть вполне приличные реализации и для ESP-шек. Причем, питоновские скрипты можно загружать и сразу же выполнять в МК "лету"! Безо всякой предварительной компиляции и отдельной "прошивки". В том числе и по Wi-Fi. Можно и пошагово выполнять питоновские команды. Это круто! Я пробовал... 

---

С Новым годом, коллеги!  

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

1. Начал с доработки железа по рекомендациям к версии софта 0.3.0.1: сделал как рекомендуется общий Reset для всех модулей, т.е. перерезал на каждом модуле дорожку от массы к 4-й ноге разъема и добавил перемычку оттуда на 1-й контакт контроллера.

Небольшое недоумение вызвала схема подключения отсюда:
[сообщение #13606720]
Теперь получается, что резисторы R2 каждого модуля встают через крейт параллельно. При десяти установленных на крейт платах суммарное притягивающее шину Reset к шине 5в сопротивление упадет с 10 кОм до 1кОм. А если плат будет еще больше? И еще один момент: может быть на каждый модуль вместо перемычки от контакта 4 до ноги 1 контроллера надо ставить не перемычку, а диод. Тогда модуль можно будет сбрасывать как общим сигналом с шины крейта, так и индивидуально со штырька на плате не перегружая при этом остальные модули установленные на крейт.

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

2. Дальше я решил не кидаться в омут с головой, а идти пошагово и для началала собрать своеобразный "hello world моргающий светодиодом". Если быть конкретным, то оставил на крейте только RMS и контактор. И решил в синхронизаторе написать простейший пользовательский скрипт, который в ответ на нажатия клавиш будет включать и выключать контактор. Для RMS в версии 0.3.0.1 прошивка не изменилась, а для контактора залил новую. И тут начались проблемы.

Новая прошивка контактора не хочет работать нигде, хотя lsync видит модуль в списке устройств. Ни со старым синхронизатором и api ни с их новыми версиями. Симптомы одинаковые: при отправке команды vset('r0', 1) контактор щелкает включаясь и тут же отключается. Если в предыдущей версии после этого прочитать vget('r0') то прочитается 1, т.е. как будто контактор включен, хотя физически он выключен. В новой версии читается 0.

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

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

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

С остальными модулями пока не экспериментировал.

дошли рукиekochnev, 10 Янв. 20, 22:26

По-белому завидую... :)

1. Про сброс. Да. Эта реализация общего сброса получилась не очень удачной - при большом количестве модулей нагрузка на линию RES может оказаться существенной. Проблему можно решить при помощи мосфета в качестве согласователя уровней выхода малинки с линией RES. Ну и, конечно, диод вместо перемычки ничему не противоречит. Более гибкое решение.
2. Про релейный модуль. К сожалению, он просто "выпал" из поля зрения. Освободившийся силовой модуль контактора был перепрошит в ШИМ-модуль. Делал фракционирование с несколькими клапанами отбора. Сейчас отказался от такого варианта в пользу переключателя ("краника") с сервой. Поэтому его можно будет перепрошить обратно в релейный модуль и посмотреть что не так с работой реле. Сделаю это чуток попозже - сейчас, к сожалению, совсем нет возможности заняться нашими делами.

---

А как у Вас с азами технологии, допуски и посадки, режимы мехобработки,режущие и обрабатываемые материалы, режимы термообработки, сварочные процессы....да дохрена ещё !Пикаль, 10 Янв. 20, 21:29

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

Неработающий контактор отложил в сторону и вчера немного снова поигрался с железячками.

Задачу себе поставил следующую: на простейшей конфигурации (плата RMS + PDM) написать пользовательский скрипт имитирующий работу в ручном режиме, т.е. при нажатии на определенные клавиши должна увеличиваться или уменьшаться мощность подаваемая на ТЭН.

PDM в отличие от контактора с новой прошивкой заработал нормально, проверил и со старым софтом и с новым. Пользовательский скрипт реализующий поставленную задачу написать тоже оказалось не сложно. А вот результат не понравился, совсем не понравился. Очень большие задержки реакции синхронизатора на события нажатия клавиш, делающие работу с софтом очень некомфортной. Т.е. если синхронизатор работает в автоматическом режиме с минимальным вмешательством человека, сам переключает режимы, то это как-то не заметно. А вот в ручном режиме когда то мощность оперативно добавить-убавить, то клапаном отбора поиграться, пользоваться становится очень тяжело. Запускал все зайдя на малинку с компа через VNC сессию. Не знаю, попробую попозже остановить на малинке VNC сервер, зайти просто через SSH и повторить эксперимент, но в текущем варианте подобные задержки для меня просто не приемлемы.

Думаю как быть...

Думаю как быть...ekochnev, 13 Янв. 20, 05:43

Сейчас такт работы синхронизатора (dt) поставлен на 2 сек. Это лимитирующий модуль. Т.к. curses работает в отдельном потоке без дополнительных задержек. В принципе, для неторопливой работы мне показалось вполне достаточным. Несколько ректификаций (в автоматическом режиме) с этой версией я уже делал. Вполне комфортно, если не "топить педаль в пол" :) Если же хочется все руками и побыстрее, то простейший способ ускорить реакцию системы - уменьшить dt до 1 сек. Если Вам и этого будет недостаточно, то тогда придется перестраивать основной цикл работы синхронизатора - делать несколько проверок запросов на обновление контроллеров на один цикл преобразований датчиков RMS и температур (времена преобразования 1 сек и 0.75 сек соответственно). В принципе, несложно это реализовать в следующих релизах синхронизатора с соответствующими параметрами, которые можно вводить, например, в командной строке при запуске синхронизатора. Ну если это действительно нужно. Вы уверены?
PS
С точки зрения реакции системы разницы в работе непосредственно на малинке и с другой станции (локальная сеть) по SSH практически нет. Да и не должно быть. Какой-то заметной. С VNC не пробовал.

Вы уверены?OldBean, 13 Янв. 20, 07:32

В данном случае я не уверен в правильности подхода в целом, когда цикл опроса клавиатуры совпадает с циклом записи и чтения из железа.

Подробнее:
Пусть нам необходима реакция системы на нажатие клавиши, увеличивающая мощность на единицу.
Значение мощности хранится в двух местах: в базе и в контроллере модуля. Эти значения синхронизируются в одном цикле одного потока. Если делать опрос нажатий клавиши в этом же цикле, то за один цикл мы обрабатываем только одно нажатие. Поэтому если цикл длится 2 сек, то за две секунды мы можем изменить мощность только на одну единицу. Если же клавиатуру опрашивать в другом потоке, то за эти 2 сек я могу нажать кнопку 5 раз и изменить значение в базе на 5 единиц. И в железо из базы в итоге перенесется не пять изменений по единице, а одно на 5 единиц.

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

когда цикл опроса клавиатуры совпадает с циклом записи и чтения из железа.ekochnev, 13 Янв. 20, 07:58

Нет. Не совпадает. Curses вообще работает в отдельном потоке (v. 0.3.0.1 и далее) без каких либо дополнительных задержек. Реакция системы на нажатие клавиш происходит без заметных задержек. Посмотрите реакцию на экране малинки или на консоли (если по SSH). Лимитирует реакцию системы именно такт синхронизатора (сейчас 2 сек). Как уменьшить время его реакции писал выше.

Ок, гляну вечером

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