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

Мы немного рискуем "зациклиться" на этом, с первого взгляда, простом вопросе ;) Начало цикла - здесь.

Очевидно, что есть несколько вариантов решения, "лежащих на поверхности": 1) купить готовый бридж и 2) сделать самому на базе какой-нибудь платки с МК и USB (и здесь, в общем-то, совсем не важно, AVR, STM32 или еще какой зверь). Понятно, что выбор за разработчиком. Тем не менее желательно, учитывая специфику данной автоматизации и, чтобы потом не огорчиться, учесть три важных момента:
1. Желательно, чтобы в бридже была аппаратная (не программная) реализация USB.
2. Поскольку на шину i2c планируется повесить много (активных!) slave устройств, должна быть аппаратная (не программная) реализация i2c.
3. Поскольку бридж будет играть роль мастера i2c шины, нужно обратить внимание, чтобы там был корректно реализован clock stretching (снижение скорости шины, если slave тормозит).
PS
Последний пункт, как правило, не уточняется продавцами, но он важен. Иначе, как с малинкой, придется a priory довольно сильно снижать скорость шины. Тогда вопрос - позволит ли адаптер это сделать (снизить скорость)?

Удаленная работа с малинкиными графическими приложениями по ssh

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

Если на клиенте установлен Linux, то достаточно просто выполнить несколько несложных настроек. Для клиентов под Windows тоже можно. И тоже не сложно. Но у меня Windows нигде не стоит. Проверить не могу - тут уже гугл в помощь... Поэтому опишу как работать с малинкиными графическими приложениями только с рабочей станции (клиента) под Linux (Ubuntu).

Полагаем, что ssh на малинке включен, на клиенте тоже установлен. И, естественно, все работает. Настроим малинку и клиентскую машину.

1. Из консоли клиентской машины соединяемся с малинкой по ssh:2. Редактируем файл /etc/ssh/sshd_config:   в файле напишем (или найдем соответствующую строчку, разремуем и отредактируем)   затем сохраняем файл (ctrl+o) и выходим (ctrl+x)
3. Перезапускаем сервис:4. На клиентской машине (в другой консоли) редактируем файл /etc/ssh/ssh_config:   пишем (или разремуем и отредактируем соответствующую строчку):   сохраняем и выходим из редактора.
5. Перезапустим ssh на клиентской машине:5. Теперь с консоли, которая соединена с малинкой по ssh (или снова соедимимся, если уже вышли) мы можем запускать графические приложения на малинке и работать с ними с клиенсткой машины, как и непосредственно на малинке. Например:Малинкино графическое приложение (13-й тест с gui) на рабочем столе удаленной рабочей станции под Ubuntu - на скриншоте в приложении к топику.

Подтверждаю, test_13_gui.py идет без сбоев более четырех суток, нет смысла дальше продолжать. Скорость 9600.

Подтверждаю, test_13_gui.py идет без сбоев более четырех суток, нет смысла дальше продолжать. Скорость 9600.nic2015, 24 Апр. 18, 18:18

Запас по скорости у нас очень большой... 9600 хватит "за глаза" :)

---

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

---

---

Софт будет писан на Python и планируется быть трехуровневым.

1-й (нижний) уровень - это библиотека классов-оберток для модулей и датчиков. Он необходим для того, чтобы инкапсулировать все технические (железные) детали реализации модулей и датчиков (предварительное тестирование, калибровки, физический и программный уровни обмена с малинкой, корреция ошибок и т.п.). Т.е. этот уровень - это как бы "виртуализация" отдельных компонентов варианта LITE. С API здесь в общем-то все более-менее понятно. При помощи этого API (после реализации этого уровня) пользователь может создавать виртульные элементы установки и управлять ими из интерпретатора python ( в ручном или программном режиме).

2-й (средний) уровень - это уровень виртуальной установки и алгоритмов ее функционирования. API этого уровня должен позволять "конструировать" виртуальную установку из объектов предыдущего уровня, настраивать режимы ее работы и, собственно, проводить сами процессы и их протоколирование. Я, естественно, буду ориентироваться на ректификационную установку моей конфигурации (кубовая ректификация, насадочная колонна, водоохлаждаемый дефлегматор с регулируемым клапаном для жидкостного отбора и стандартный "джентльментский" набор датчиков). Но, поскольку, разработку планируется вести в "открытом" режиме - можно будет учесть какие-то нюансы, выходящие за рамки указанной архитектуры). API второго уровня должен будет существенно упростить разработку рабочих скриптов для процессов ректификации. Да и, собственно, - выполнять их в консольном режиме. Локально или удаленно.

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

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

датчик суммарного расхода продукта

А он зачем? Есть ведь тарированный клапан и по числу его срабатываний можно легко определить кол-во полученного продукта. не так ли?

Было б неплохо учесть автономное охлаждение ( наверно силовой модуль с прошивкой контактора) из за проточной воды дефлегматор кальцием забивается. И второй клапан для тех кто работает с царгой пастеризации.nic2015, 25 Апр. 18, 07:31

Для модулей с типовым поведением (как в Ваших примерах) никаких проблем нет. Класс-обертка для типовых устройств создается один. А объектов данного класса, различающихся адресами и калибровочными данными, если они используются, можно создавать сколько угодно (в пределах 127 на одной шине i2c). Например, на первом уровне у нас есть класс-обертка, ну, например, CoilSwitch для включателей/выключателей всяких катушек (контактор, клапан воды охлаждения, вентилятор вытяжки, обдува и т.п.). В скрипте Вы создаете столько объектов данного класса, сколько нужно. Например, И все... Дальше, если Вам нужно, например, включить контактор пишете в нужном месте скрипта Или - выключить вытяжку: Т.е. сильно соображать почти не понадобится... ;)

А он зачем? Есть ведь тарированный клапан и по числу его срабатываний можно легко определить кол-во полученного продукта. не так ли?gol_avto, 25 Апр. 18, 07:41

Сейчас именно так и реализовано (точнее - суммируется время, в течении которого клапан открыт, ибо - ШИМ). Но все равно накапливается небольшая ошибка, т.к. регулировка ведется с точностью до 1%. В варианте LITE регулировка будет с шагом 0.1%. В общем-то - посмотрим. Может быть и не придется делать специальный датчик. Может и не зря отложил ;)

OldBean, добрый день! У меня вопрос, я планирую повторить регулятор мощности, контроллер клапана и датчик RMS в варианте с индикаторами и кнопками. Пока сильно в исходники не вникал, ПО микроконтроллеров этих блоков совместимо с текущим софтом на питоне? Или нужно будет что то переделывать в прошивках?

Уряя! Наконец то "добил" SSH и через VNC соединение к рабочему столу малины с ноутбука под Win.

ПО микроконтроллеров этих блоков совместимо с текущим софтом на питоне? Или нужно будет что то переделывать в прошивках?SergeyMak, 25 Апр. 18, 09:55

День добрый, Сергей! Прошивки, естественно, несовмеcтимы. На уровне питона - тоже. Сделать новое питоновское ПО (для LITE) совместимым с первой версией железа (которые с кнопками и индикаторами) довольно сложно. Модули отличаются протоколами обмена с малинкой и, главное, модули первой системы могут управляться независимо от малинки (т.е. кнопками). Поэтому в питоновком софте первой версии предусмотрено перманентное чтение параметров модулей. Чтобы малинка всегда знала в каком состоянии находятся модули.

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

---

Уряя! Наконец то "добил" SSH и через VNC соединение к рабочему столу малины с ноутбука под Win.gol_avto, 25 Апр. 18, 11:01

Отлично! Если будут возможности и желание - сможете написать небольшие прописи для пользователей Windows? Чуть позже наведу порядок в оглавлении - можно будет добавить ссылку и на Ваши прописи.

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

сможете написать небольшие прописи для пользователей Windows?OldBean, 25 Апр. 18, 11:25

Да собственно прописей то особо и не надо писать. Попалась мне замечательная статья про SSH
http://zgo.narod.ru/...po_ssh/1-1-0-36
в которой всё подробно описано и про VNC
http://zgo.narod.ru/...tunnel/1-1-0-40
разумеется потребуется роутер, как связующее звено между ноутбуком и малиной, соединенный с ними по WiFi. Роутера у меня никогда не было, помогли его настроить IT-шники на работе.
============
Главное в малине надо прописать статический IP адрес для подключения через встроенный Wi-Fi-адаптер
в файле  sudo nano /etc/dhcpcd.conf

nohook lookup-hostname
nodhcp

interface wlan0
static ip_address=192.168.1.100
static routers=192.168.1.1
static domain_name_servers=192.168.1.1

==================
Вот ещё хорошая ссылка, как автоматом запускать VNS сервер при вкл. малинки
http://www.armlinux.ru/...ий-запуск-серв/

Тут мысль появилась, добавить к этой системе какой нибудь ЖК дисплей с i2C, куда выводить показания всех датчиков, просто чтобы без подключения к малинке можно было оценить параметры.SergeyMak, 25 Апр. 18, 11:31

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

дисплей нормальный графический к малине поискатьSergeyMak, 25 Апр. 18, 12:11

Я себе такой взял https://www.ebay.com/...=item238c8ee086

Да, у китайцев вариантов много. Интересно, 5 дюймов с разрешением 800х480 будет достаточно? Такой вариант совсем недорогой.

5 дюймов с разрешением 800х480 будет достаточно?SergeyMak, 25 Апр. 18, 12:47

Главное чтобы потом надписи под лупой не рассматривать.

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

---

Интересно, 5 дюймов с разрешением 800х480 будет достаточно? Такой вариант совсем недорогой.SergeyMak, 25 Апр. 18, 12:47

В принципе достаточно. Но зрение и нервы лучше поберечь. Поэтому я бы, все-таки, посоветовал поставить нормальный небольшой монитор с HDMI, клавиатуру и мышку. Это не обязательно делать сразу - можно пока спокойно работать с малинкой по SSH с любой рабочей станции. Если в доме есть локальная сеть. Если еще не перебрались на Linux (припоминаю - давным-давно собирались ;), то можно и из под Windows.

Установка будет не дома работать )) Да и не я буду с ней возиться, мое дело только электронику сделать, вот и хочу чтобы была местная индикация. Управлять и наблюдать по сети это само собой, vnc и ssh я быстро освоил. Просто если вдруг сеть ляжет, хотелось бы прям на установке все видеть. Закажу пожалуй на 5 дюймов, посмотрю как оно. А линукс у меня пока на виртуалке, изучаю периодически, но полностью перейти пока не получается :-))

Запустил test_13_gui_3v.py , только выкинул один клапан а вместо него поставил контактор охлаждения. С размерами еще не разобрался.

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

Гибкая система, можно как угодно сконфигурировать.

Есть ведь тарированный клапан и по числу его срабатываний можно легко определить кол-во полученного продукта. не так ли?gol_avto, 25 Апр. 18, 07:41

Не все однозначно на практике, по крайней мере у меня... При разном % ШИМа, получается разная пропускная способность устройства отбора. При чем и на обычном клапане и на перистальтическом насосике.