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

мы договорились поменять местами линии SDA и SCLOldBean, 09 Апр. 18, 12:49

Видимо я пропусти сей момент, каюсь.
===============
Запустил тест у себя - всё работает

Знал бы про засаду с датчиком заказал бы сразу, а так дней 20 ждать(((

Знал бы про засаду с датчиком заказал бы сразу, а так дней 20 ждать(((nic2015, 09 Апр. 18, 17:14

Ничего страшного.
Вы можете пока спокойно работать и без датчика давления. В тексте скрипта test_13_gui.py заремуйте (закомментируйте) 4 строчки: 5, 71, 72 и 122. Т.е. - поставьте в начале этих строк решетку - '#'. У Вас должны получиться такие строки: Скрипт не будет ругаться из-за датчика давления. С помощью этого теста Вы можете, например, поуправлять ректификационной установкой в "ручном" режиме. Для тестирования и отладки.

Хотел спросить, matplotlib ставить по какой ссылке, есть ведь разные варианты.

Уважаемый OldBean. Хотел ненавязчиво спросить. Я сделал сразу 3 модуля для клапанов. А как бы на эту красивую картинку теста всей периферии добавить еще 2 клапана. Они у меня по адресам 0x16 и 0x17.
Полагаю, что этого будет мало
# Адреса устройств
addrR = 0x11 # Адрес датчика RMS
addrC = 0x12 # Адрес контроллера контактора
addrT = 0x13 # Адрес контроллера ТЭНа
addrV = 0x14 # Адрес контроллера клапана отбора на шине i2c
addrD = 0x15 # Адрес цифрового модуля
addrV2 = 0x16 # Адрес контроллера клапана отбора на шине i2c
addrV3 = 0x17 # Адрес контроллера клапана отбора на шине i2c

А вот дальше сложнее
============
Или я опять тороплюсь, ещё ведь не готова основная программа.
============
переменные поправил addrV2 и addrV3

gol_avto, будет работать только третий клапан, 0х17
Переменные должны быть разными, ну и в коде тоже будут изменения.

matplotlib ставить по какой ссылкеnic2015, 10 Апр. 18, 07:25

Есть несколько способов установки питоновских модулей. В данном случае проще поставить такой командой из консоли:Система постарается поставить самый свежий.

А как бы на эту красивую картинку теста всей периферии добавить еще 2 клапана.gol_avto, 10 Апр. 18, 08:18

Это не сложно. Вводите переменные для адресов (имена должны быть разные, не так как у Вас). С массивами заморачиваться не будем. Поэтому пишите так: Поскольку калибровки у Ваших клапанов, скорее всего, будут разные, нужно создать три объекта типа "клапан отбора", каждый из которых будет управлять своим клапаном.

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

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

параллельная работа клапанов будет предпочтительнееgol_avto, 10 Апр. 18, 09:55

Тогда совсем просто. Вот попробуйте в качестве прототипа скрипт во вложении. Там просто все что нужно тупо сдублировано. К сожалению, у меня только один модуль с прошивкой клапана отбора. Поэтому полностью протестировать скрипт не могу. Пробуйте сами. Ежели что не так - давайте попробуем отладить дистанционно.

---

PS
В прототипе я не стал корректировать компоновку объектов. Удалите лишние или увеличьте высоту окна сами.

Благодарю! Почему то не скачивается, типа отсутствует файл. Может его заархивировать?

Запаковал. Скачивается?

 Да. Скачалось

А попробуй ка воплотить свои "партизанские" хотелки с любой другой автоматикойEsc, 10 Апр. 18, 13:24

И я про то ж Респект автору.
Дособеру до человеческого вида, чтобы опять не сжечь чего либо, протестирую

Здорово, запустил test_13_gui.py- идет!!!



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

+ 4-й клапан планирую для "польского буфераgol_avto, 10 Апр. 18, 09:55

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

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

Редко, но выдает ошибку "ошибка контроллера клапана отбора". Test_13_gui.py.

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

При этом значение RMC становится равным 0, а в терминале ноли идут.


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

И по i2cdetect не находит, перезагружу, тогда идет нормально.

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

Что интересно test_12_gui.py и test_13_2.py запущенные вместе идут без сбоев.

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

Перепрошил другой модуль на клапан отбора. Пока без сбоев Test_13_gui.py.

Запаковал. Скачивается?

Редко, но выдает ошибку "ошибка контроллера клапана отбора".nic2015, 10 Апр. 18, 14:43

Скорее всего, RMS "вклинился" во время обмена по событию изменения состояния спинбокса клапана отбора. Или, что вероятнее, наоборот. Сейчас (в тестах) не предусмотрено никакой синхронизации процессов обмена. Поэтому такие коллизии, в принципе, возможны. Хотя в своих тестах я их никогда не "ловил". Поэтому и не стал усложнять жизнь...

---

Хорошо. Спасибо за информацию - в конечном приложении предусмотрю флаг "занятости" шины при многобайтном обмене. Коли такое случается. GUI оно и есть GUI... Это я про событийную модель ;)

И по i2cdetect не находит, перезагружу, тогда идет нормально.nic2015, 10 Апр. 18, 14:43

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

Вот, опять поймал сбой, вот что на шине i2c творится при этом:pi@raspberrypi:~ $ i2cdetect -y 1
    0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
10: 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f
20: 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f
30: 30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f
40: 40 41 42 43 44 45 46 47 48 49 4a 4b 4c 4d 4e 4f
50: 50 51 52 53 54 55 56 57 58 59 5a 5b 5c 5d 5e 5f
60: 60 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f
70: 70 71 72 73 74 75 76 77                       
pi@raspberrypi:~ $



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

Что характерно на всех предыдущих тестах до test_13_gui.py сбоев не наблюдал, хотя запускал на сутки. Фото экрана при сбое прилагаю.

Какой то из модулей шину SDA "завесил". У меня такое было, когда "поджарил" малинку и на SDA постоянно висело 1,12V.
Забей, Сергей ведь сказал, что тестовые программы не отслеживают занятость шины, поэтому сбои возможны при большом кол-ве модулей.

Я запустил test_12_gui.py и test_13_2.py одновременно, идут без сбоев, завтра напишу как оно, через 24 часа.

Вот, опять поймал сбой, вот что на шине i2c творится при этом:pi@raspberrypi:~ $ i2cdetect -y 1nic2015, 11 Апр. 18, 14:49

Такой результат бывает когда SDA постоянно замкнуто на землю (на линии логический 0). Это либо физически глючит какое-нибудь устройство на шине, либо "сопля". Посмотрите на всякий случай с лупой монтаж всех плат и крейта в окрестностях этой линии.

---

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

К сегодняшнему утру пока сбоев не обнаружено (скриншот в приложении). Ну пусть дальше работает пока не надоест. ;)