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

Да. Порты периферии, подключенные к Int, либо выдают 0 (т.е. тянут шину к земле), либо отключаются от шины (т.е. переходят в высокоимпедансное состояние). 5 вольт на шину они выдать не могут, т.к. в скетче на соответствующем пине порта всегда установлен 0. Просто при разработке скетчей об этом не нужно забывать.

Я кстати, интереса ради через алиэкспрессовкский двунаправленный согласователь 5-3.3 на транзистрах подключил все, в том числе и DSки - работает нормально.

Я написал модуль ядра....Там же производится управление триаком.ys1797, 17 Дек. 17, 15:04

Дергать малинкой затвор триака, наверное, не самая лучшая идея. Все-таки, для выполнения действий в real time гораздо проще, да и эффективней использовать контроллеры. Выполненные, например, на младших ардуинках или AVR-ках. А малинке оставлять высокоуровневое управление всей системой. Собственно, варианты таких архитектур в данной ветке как раз и рассматриваются.

---

2 BogAD. Я на всякий случай с утреца проверил работу аварийной кнопки через малинкины прерывания. Все работает правильно. Так что паяйте спокойно свой переходник с 29 ногой малинки к шине Int ;)

---

Текст проверочного скрипта ниже. Он очень подробно прокомментирован. Поэтому его можно использовать как маленький тренинг, для новичков в питоне, желающих немного попрактиковаться. Для тренинга, нужно подключить к 29 пину на разъеме малинки нормально разомкнутую кнопку (другой конец кнопки, понятно, - к любому земляному пину малинки). Установить подтягивающий резистор (порядка 10 кОм) с этого же 29-пина на +3.3V (!!! ни в коем случае не на +5!!!!). Можно и не ставить резистор, но тогда нужно разремовать одну строчку в скрипте (см. текст скрипта). Далее нужно оформить скрытый текст, который ниже, в виде файла с расширением *.py (например, int_test.py) и запустить в консоли: python int_test.py. При нажатии на аварийную кнопку, на терминал будет выводится соответствующее сообщение. После 5 нажатий тест завершит работу.

Скрытый текст

#coding:utf-8	# Это позволяет использовать русские буквы в этом тексте
import RPi.GPIO as gpio  # Импортируем модуль для работы с GPIO
import time # В этом модуле есть задержка (sleep())

cntr = 0 # Глобальный счетчик нажатий аварийной кнопки (просто для теста)

def myCallback(intPin): # Эта функция - наш обработчик прерываний
  global cntr # global - чтобы использовалась внешняя переменная cntr
  cntr += 1 # Прибавляем единичку к счетчику
  print 'Кнопка аварийного завершения нажата ' + str(cntr) + '-й раз'

gpio.setmode(gpio.BOARD) # Используем нумерацию пинов как на разъеме GPIO
intPin = 29 # Сюда подключена шина Int (вариант LITE)
gpio.setup(intPin, gpio.IN) # Настраиваем этот пин - на ввод
# Если подтягивающего резистора на 29-м пине нет, то можно включить
# внутренний, "разремовав" следующую строку кода
# gpio.setup(intPin, gpio.IN, pull_up_down = gpio.PUD_UP)

# Регистрируем наш обработчик прерываний по спаду уровня на этом пине
gpio.add_event_detect(intPin, gpio.FALLING, callback = myCallback)

while True: # Делаем какую-нибудь бесконечную работу в бесконечном цикле
  time.sleep(0.5) # Например, поспим ;)
  if cntr >= 5: break # После 5-го нажатия кнопки - выходим

gpio.cleanup() # Почистим за собой GPIO

Привет миру честному!
Сегодня, чуток принЯвшись на дУшу, понедельник заглаживаю... упустим подробности, тут нет интереса для вас.
Подработал свои версии плат. В личке спросили, я обещал выложить.
Вкратце - сделал:
1. Плата под силу ТЭНа - триак в корпусе TOP-3. Отдельно плата под слабые клапана (триак ТО-220). Выбирайте.
2. Вышеперечисленные платы под автоматы защиты A-0702X или A-0802X (дорожки предусмотрены). Не хотите, меняйте под свои нужны. Хоть под плавкие. Ваша воля.
3. Я отказываюсь от отдельного аварийного контактора. Останавливаюсь на управлением диф.автоматом на аварийный "СТОП".  По схеме плату под его управление , обозначим QFD.  Избыточная мощность, но..., я решил не экономить. Причем гнездо на материнке под неё особенное и отдельное.
4. Плата сервера температуры на 8 датчиков. Использовал разъем 2х18 под шлейф.  Распиновку не стал расписывать. Заменив резюки 4,7 кОм на 10 кОм, можно сделать плату IN/OUT  по логике. Но это в планах...
5. Материнка:
Слаботочка -
Предусмотрел разъем 2х20 с материнки на 2х20 Малинки. В практике должно "Подоткнул без подсчета пинов и в ажуре." Зациклил массу. Может переборщил, пущай будет.
Сила -
Тут еще не полностью продумал. Плата как есть, далее под ваши хочушки - вашими фантазиями. Одно уточню - сила через стойки из латуни под М4. Величина от высоты разъемов 1х12... На нагрузки изолированной многожильным проводом под платой.  Должно получиться.

Архив в атаче...

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

Я все-таки сторонник классической последовательности разработки устройств: сначала - макетирование (в крайнем случае - симулирование), отладка, коррекция. Потом "черновая" разводка, тестирование и коррекция. И только потом - изготовление конечного устройства и публикация всех технический деталей (в том числе - подробных схем и печатных плат). Поэтому здесь нужно обязательно подчеркнуть, что те решения, которые публикует и предлагает для повторения уважаемый коллега BogAD, целиком лежат на его ответственности. Дело в том, что вариант LITE находится в процессе разработки (в том числе, и по некоторым вопросам концептуального уровня). Поэтому в конечной реализации возможны серьезные расхождения в логике, деталях работы (как аппаратных, так и программных частей) решений, предлагаемых коллегой BogAD, и варианта LITE. Я, конечно, постараюсь свести риски этих расхождений к минимуму. Но брать на себя дополнительные ограничения, вызванные чьими-нибудь быстрыми решениями, совсем не хотелось бы. В конце концов, я этим занимаюсь исключительно в виде хобби и исключительно ради удовольствия от самого процесса разработки. СтОит ли, как говорил Жванецкий, "подгонять фигуру под костюм" ;) ? Короче - этот абзац я написал для очистки совести... ;)

---

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

1. Иерархическая двухуровневая архитектура (в перспективе - трехуровневая; на третьем уровне - UI). Все "real time" - задачи, требующие жесткой синхронизации, вынесены на нижний уровень. Это уровень контроллеров исполнительных устройств и датчиков. Задачи координации и общие задачи управления процессами вынесены на второй (верхний) уровень. Это - уровень микрокомпьютера, работающего под управлением операционной системы (обычной, не real time). Про детали такой организации мы уже неоднократно говорили (в самом начале, потом здесь).

2. Вариант LITE. Более, чем годовой опыт эксплуатации такой системы в практической ректификации, показал, что элементы UI на нижнем уровне бывают очень полезны, но в полной системе (с малинкой, дисплеем, мышкой и клавиатурой, или просто сенсорным дисплеем - на любителя) используются очень редко. Тем не менее эти элементы существенно усложняли firmware контроллеров нижнего уровня и сильно затрудняли унификацию модулей. Поэтому возникла мысль сделать "вариант LITE", в котором нет UI на нижнем уровне и все "железо" нижнего уровня полностью унифицировано. А специализация контроллеров реализовалась бы исключительно на уровне firmware!

3. Вот эту задачу унификации элементов нижнего уровня почти удалось выполнить. Исключение составляет только датчик RMS напряжения питающей сети с детектором нуля. В самом начале я вообще хотел их разместить непосредственно на плате крейта, но потом решил сделать их съемными. В виде отдельного модуля, совместимого по шинам и разъемам с остальными модулями нижнего уровня. С практической точки зрения это действительно оказалось удобным и радикально упростило плату крейта (она превратилась просто в банальные силовые и цифровые шины). А вот остальной функционал нижнего уровня четко разбился на два класса, которые можно полностью "закрыть" двумя типами унифицированных модулей: силовым и цифровым.

4. Унифицированный силовой модуль представляет собой электронный ключ (твердотельное реле) с I2C-интерфейсом. Поскольку установка предназначена для работы в сухих, отапливаемых помещениях, где с потолка ничего не капает, то я не стал "валить в кучу" низковольтную (12-24В) "силу" и высоковольтную (220В). Поэтому ТЭНы, все "катушки" и прочие исполнительные устройства, работающие в LITE, это - 220-вольтовые устройства. Естественно, можно воткнуть в крейт и низковольтные модули. Абсолютно ничему не противоречит. Просто я (лично) не планировал это делать.

В основу мозгов силового модуля положен 8-пиновый МК от AVR - ATtiny85. Пока. Теоретически, его ресурсов хватает. Единственный тинькин нюанс - USI вместо полноценного TWI (как в мегах). Помехозащищенность USI (по datasheet) ниже. Поэтому (в сочетании с известной малинкиной "придурью" касательно I2C) надежность связи силовых модулей с малинкой по I2C пока не ясна. Нужно тестировать. Как раз хотел, в ближайшем "окне" дел, этим заняться. Если не удастся добиться долговременной стабильности связи - придется отказаться от тиньки и ставить меги. Ну тут, скорее всего - 328-ю. Для нее проблемы со связью по I2C уже полностью решены. Но количество, расположение ног и "обвязка" у тиньки и у меги разные. Поэтому, поскольку вопрос еще окончательно не решен, разводить и, тем более, изготавливать такие силовые модули сейчас было бы несколько опрометчиво.

Количество таких унифицированных силовых модулей (по одному на каждое исполнительное устройство) ограничено только конструктивом крейта и, естественно, "емкостью" одной шины I2C (т.е. 127 устройств) ;)

5. Унифицированный цифровой модуль, по сути, представляет собой программно-аппаратный интерфейс между шиной I2C и определенным количеством независимых однопроводных цифровых шин. Пока (для пробы) заложено 8 шин, но свободных ног у 328-меги еще много ;). Были две основные причины введения в систему такого типа модулей - защита GPIO малинки и перевод однопроводных шин на 5-вольтовую логику. В конечном итоге все это должно повысить помехоустойчивость системы.

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

---

Теперь по конкретике.

Плата под силу ТЭНа - триак в корпусе TOP-3. Отдельно плата под слабые клапана (триак ТО-220). Выбирайте.BogAD, 25 Дек. 17, 21:57

Как я пояснил выше - я выбираю унификацию ;)

3. Я отказываюсь от отдельного аварийного контактора.BogAD, 25 Дек. 17, 21:57

Не думаю, что это сильно хорошая идея. Дело в том, что контактор здесь стоит не только для автоматического отключения высокого, но и для автоматического запуска установки. Или я что-то не так понял?

В практике должно "Подоткнул без подсчета пинов и в ажуре.BogAD, 25 Дек. 17, 21:57

Это, конечно, дело вкуса, но ИМХО, имеет смысл только для полностью готовой разработки. А пока, со стороны малинки, лучше не увязывать отдельные провода в единый разъем. Все-таки один-два раза (за все время!), подключая проводки к малинке, несложно быть повнимательней. Но, при этом, сохранив "гибкость" подключения крейта к малинке. Разборка-сборка такая же быстрая (со стороны цифровых шин крейта - цельный разъем). Но не придется перепаивать, если захочется что-то изменить, попробовать/сравнить другие пины малинки и т.п.

Это, кстати, касается и шины Int. История этой шины такова. Сначала я хотел просто поставить кнопку "железного" сброса системы. Т.е. - hard reset. Поскольку система распределенная, то сигнал аппаратного сброса нужно подать на все модули (в том числе и на малинку). При этом, естественно, должно было бы (безусловно) отключаться и высокое. А потом я подумал, что это, наверное, будет некий "перебор" и недоверие к малинке ;). Зависания малинки у меня за все время эксплуатации не было ни разу. Подумал - пусть у малинки будет возможность самой принять решение по сигналу аппаратного прерывания (от периферии или от меня, по кнопочке). Она сама все выключит, обесточит, все сохранит... А, если тревога ложная, сама же вновь запустится и продолжит работу. Так и образовалась шина Int, которая является, образно говоря, "экстренным", независимым от I2C, каналом связи между малинкой, периферией и оператором. Увы, протокол этой шины пока еще очень туманный. Тут еще нужно поэкспериментировать. Возможно, толку от этого "экстренного" канала связи будет немного. Тогда можно вернуться к обычному "вульгарному" hard reset. Это я уже про гибкие коммуникации и провода... ;)

---

" По идее, если ошибка обмена по IIC и обнаружена, то не надо в новой версии скрипта сразу рубить процесс в ноль "
Как я понимаю, обе стороны обмена не слишком загружены, так что можно сделать многократную передачу с запросом-переспросом. Думаю, это будет проще, чем резать-клеить биты.Sten58, 25 Дек. 17, 22:24

Да вроде никто и не собирался ничего "рубить". Более того, сейчас, в текущей версии софта некритические ошибки обмена просто игнорируются. В новой версии этих ошибок уже просто не будет.

По поводу резать/не резать байты. Дело в том, что, даже для того, чтобы просто обнаружить ошибку обмена, мы должны ввести в код (протокол обмена) некоторую информационную избыточность. Например, добавлять бит четности или еще что-нибудь. Ну это как закон сохранения энергии - за все нужно платить ;). Но, поскольку мы знаем точно, что единственный канал возникновения ошибок у нас - это пропадание старшего бита (если случилось, то - всегда одного бита и всегда старшего!), то мы вводим избыточность в код просто за счет уменьшения разрядности байта с 8 до 7. Т.е. старший бит всегда игнорируется. Избыточность кода всего 12.5%. На мой взгляд это как раз и есть самое простейшее решение проблемы. Вместо того, чтобы усложнять программный протокол ловлей ошибок, повторением обмена в случае ошибки и тому подобные "ветвления логики", isn't it?

Насколько это просто, можно убедиться по фрагментам кода со стороны ардуинки:

Скрытый текст

//---------------------------------------------------------------------------------------
int index = 0;
//---------------------------------------------------------------------------------------
// Передача масстеру I2C 14-битных слов в 2-байтовом формате. Старшие биты каждого байта
// в приемнике (мастере) должны игнорироваться. Если в качестве мастера выступает
// малинка, то можно использовать следуюшую последовательность команд:
// import smbus
// bus = smbus.SMBus(1)
// lo = bus.read_byte(0x04)
// w = (bus.read_byte(0x04) << 7) | lo
// и т.д.
//---------------------------------------------------------------------------------------
void sendData() { // callback для передаваемых по I2C байтов
  if(index) Wire.write((tval >> 7) & 0x7f);
  else Wire.write(tval & 0x7f);
  index = 1 - index;
}
//---------------------------------------------------------------------------------------
// Прием по I2C от мастера блока из 3 байт: команды (байт) и слова (2 байта). 
// Если в качестве мастера выступает малинка (библиотека smbus и язык python), то
// можно использовать следующую последовательность команд:
// import smbus
// bus = smbus.SMBus(1)
// bus.write_word_data(adrr, comm, word)
// и т.д.
//---------------------------------------------------------------------------------------
void receiveData(int byteCount) { // callback для принимаемых по I2C слов
  if(byteCount != 3) return;
  uint8_t buf[3]; // Буфер для приема команды и двух байтов
  while(byteCount--)
    buf[byteCount] = Wire.read();
  tval = buf[0]; tval <<= 8; tval |= buf[1];
  updateFlag = 1;
  if(buf[3]) index = 0; // Если команда отлична от 0, то еще и сбрасывается index на 0
}
//---------------------------------------------------------------------------------------

и со стороны малинки:

Скрытый текст

...
bus.write_word_data(0x04, 0, i)      # Отправка слова и команды
...
lo = bus.read_byte(0x04)             # Получение младшего байта
w = (bus.read_byte(0x04) << 7) | lo  # Получение старшего байта и формирование полного слова
...

---

PS
Кстати, неплохо было бы еще небольшой 5-вольтовый UPS для цифры сделать/приспособить ;). Недавно были кратковременные отключения света. Сбросить буфер, естественно, малинка не может - конец лога портится. При рестарте малинка ругается. Приходится руками этот "размохнатившийся" хвост лога править...  

Да любой повербанкys1797, 26 Дек. 17, 15:59

А ведь действительно! Использовать power bank в качестве 5-вольтового беспребойника - отличная идея! Готовое и очень "бюджетное" решение! Power bank как-то не приходил в голову. А ведь тут, действительно, много-то и не надо. Пары минут вполне хватит! Как только устойчиво исчезло напряжение с датчика RMS - сбросить всю периферию на 0, закрыть файлы, завершить приложение и - на sudo shutdown -h now  ;)  Отлично! Thanks!

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

Малинка+модули, как ни крути от 700мА хотят кушать в самом экономном раскладе. А так малинка под 1.5 А может захотеть.

Ну учитывая что 3700 маЧ 1 элемент 18650 гдето, то и плевать. Можете убедиться в достаточности просто посмотрев на такое чудо китайпрома как электронная сигарета. Хватит на долго.

Китайцы уже все сделали за нас. Заказал готовое... ;)

OldBean, а если напруга пропала всего на 10 минут? Или 20?
Я все питаю от СКАТа с гелевой батареей

а если напруга пропала всего на 10 минут? Или 20?mak, 27 Дек. 17, 07:06

Да тут уже без разницы, хоть на 10 мин, хоть на час, хоть на сутки... Все равно придется по новой запускать колонну, выводить ее на стационар и только потом продолжать прерванный процесс. Но делать это автоматически мне бы очень не хотелось, хотя и не сложно. Одно дело - автоматический запуск по расписанию или дистанционно. И совсем другое - после исчезновения высокого (сети). Мало ли почему оно исчезло? После такой ситуевины осмотр оборудования перед запуском таки весьма желателен.

Max. Power Output: 10W (2.1A) OldBean , ну не знаю не знаю... Чего у тебя малинка жрет замерял?
Я к тому, что если просто батарейка на выход то можно не париться, потянет. А вот если чето ограничивает со стороны железа - млаовато как то написано.

Чего у тебя малинка жрет замерял?PavelSaratov, 27 Дек. 17, 16:17

Не замерял. Для 3-й малинки рекомендуется источник питания на 2.5А. Но, похоже это с солидным запасом. У меня от 2А зарядки спокойно работала (без сбросов) при любой загрузке (на USB была только мышка и клавиатура). Для ориентировки у них на сайте есть неплохая табличка. Скрин-шот - в приложении.
-----------------
Придет Mini UPS 5V из поднебесной - попробую - расскажу хватает или нет. А ежели нет - и в других делах сей девайс пригодится ;)

Коллеги. Разговор не заслуживает внимания. Не поленился, измерил. Малинка + 5 модулей с индикаторами

Коллеги. Разговор не заслуживает внимания. Не поленился, измерил.gol_avto, 27 Дек. 17, 17:51

Конкретные цифры - это всегда хорошо. Тем не менее, "потребительский" вопрос для любой программно управляемой системы обычно весьма непрост. Он сильно зависит от того, о чем в данный момент система думает ;) Посмотрите таблицу, приведенную выше. В ней потребляемый ток 3-й малинки в бессознательном состоянии (idle ;) 0.3А, а в сильно озадаченном (stress) - 1.34A. Они отличаются почти в 4.5 раза! Задайте малинке какую-нибудь задачку. На все 4 ее ядра. Посчитайте хэш какого-нибудь большого файла. Скорее всего получите уже что-нибудь порядка пары ампер...

---

Кстати, как Ваш питон? Привыкаете помаленьку?

Вероятно не совсем в тему, но спрошу. На достаточно длинном кабеле(ок 6 м.) как лучше обвешивать DS18B20? Где ставится 4.7 кОм, или он делится? Про сбои встречал [сообщение #13176612] , а про согласование линии нет(R= 110 Ом). С симисторным регулятором стал ловить помеху: Т= -127.00*С. На ДС-ку повесил небольшую керамику. Дроссели/трансформатор на входе регулятора пока не ставил, в процессе моделирования. У ТС тоже не встречал.

http://mcus.ru/posts/ds18/
http://netstorage.iar.com/...-002_1-wire.pdf - смотри прямо первую страницу апноута. Там видно кто и куда втыкается.

Чт за согасование 110 ом я не в курсе. Чето мне сдается это из другой оперы. Уточните.
Ссылка вами приведенная вроде про i2c а не про 1-wire.

Вот тут вообещ куча всего что нужно знать про 1wire для ds вообще http://mypractic.ru/...kom-yazyke.html

PavelSaratov, ПМСМ, кроме программных вопросов есть и "железные". Любая линия связи(кабель) имеет своё волновое сопротивление. Витая пара имеет ок 110 Ом. (РК= 50-75). Если нет согласования- сигналы имеют хер знает какую форму. На одной из тобой приведённых ссылок 4.7 кОм у каждого датчика параллельно, а их 3.
ПС, возможно не так ставил вопрос. У Ардуино при длинных проводах, пишут, проблемы с датчиками. Разными.