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

Тем не менее, на текущий момент ни RES ни INT в софте малинки не используется, поэтому ничто не мешает запустить все это на ноуте в текущем функционале. RES вообще к малинке даже не подключен, INT подключен, но софтом не обрабатывается.ekochnev, 06 Дек. 21, 20:18

Да, сейчас это так. Сейчас идет проверка концепция передачи i2C на большие расстояния. Сергей проверил, и проверка успешна. Теперь добавляем заложенную концепцию по теме ветки в целом.. Получится? Думаю, без хотя бы дополнительного сигнала INT, окромя шины I2С не получится.
Хоть как убеждайте меня, но хоть одна сигнальная линия нужна для аварийного "стопа" критичных процессов управления. К примеру одна из перечисленных ситуаций: "повесилась" любая из AtMega на критических узлах, к примеру 1-Wire... пробило ТРИАКи ТЭНов накоротко... закис клапан охлаждения... подклинил поплавок уровня жидкости... ну и т.д. и т.п.
Как не крути, нужна линия прерывания INT, которую может "дернуть" любой модуль из нашей системы, который понял, что "АТАС"...
А по вашему варианту, МАСТЕР ни как эту шину не сможет дергать, и тем белее её анализировать.
А безопасность должна быть на очень большом уровне!

Сейчас мы обсуждаем основной функционал по обмену через I2C, не заостряясь на безопасности. Но! Это будет и тут мы будем искать как это сделать.
Что проще, улучшать функционал заложенный сразу в железе или делать изменения в программах?
PS
Пришли платы с завода. 20 минут назад принес курьер. Буду собирать, паять, и рассказывать, но по наличию времени. А рассказать давно язык чешется. LEGO должно получиться что надо!

BogAD, да Вы меня можете не убеждать, у меня уже несколько лет как на малинке все это собрано с небольшими доработками и успешно работает на своем собственном софте. Просто разработка данного концепта продолжается совсем не быстро вот уже как 5 лет, а человеку приспичило сделать это все на планшетнике. Я вполне допускаю, что если обсуждаемое развитие ему не нужно, а существующий функционал устраивает, то вполне реально это запустить на компе не используя ни INT ни RES. Пусть поэкспериментирует если хочет, теоретическая возможность запуска есть, а дальше его воля. Ну а мне лично результаты его экспериментов было бы просто интересно послушать.

хоть одна сигнальная линия нужна для аварийного "стопа" критичных процессов управленияBogAD, 06 Дек. 21, 21:07

Это кому как. В общем случае не нужна. Если модуль такой умный, что может просигналить аварию железом, пусть сначала просигналит ее по двухпроводной линии. Предусмотреть эти пару бит в "регистрах" модулей. Все равно высокоуровневым софтом асинхронно обрабатывать.

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

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

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

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

Опять-таки, как делать разборы полетов с сигнальной линией, которую может дернуть любой модуль на шине? Как понять что случилось, когда неизвестно даже который модуль ее дергал? Какая отладка при таких раскладах..makh, 07 Дек. 21, 00:54

Самый печальный сбой - это полная блокировка i2c. Например, когда какой-нибудь ухарь (модуль) глухо садит на землу SDA или SCL и не хочет ее отпускать. Так иногда бывало (не в штатных режимах, а на этапах отладки софта). Малинка, конечно легко распознает такую ситуацию, но сделать, увы, уже ничего не может. Поэтому и была предусмотрена отдельная линия RES для перезагрузки всех модулей. Но она, по причине редкости таких ситуаций, так и не была задействована в реале. В принципе без этой линии можно обойтись, если дать малинке возможность управлять питанием +5 (крейта или всей i2c сети). Т.е. малинка выполняет перезагрузку всех модулей снятием и последующей подачей питания. Это, конечно, более жесткое, но вполне справедливое решение в непонятных ситуаций, когда все "колом встало". Этого (в реальных процессах) еще не было, но, возможно, такое решение стОит предусмотреть в новом варианте (LEGO).

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

Для этих целей вполне может подойти ноутбук, если я не ошибаюсь. Может кто то подсказать по этому поводу или хотя бы показать в какую сторону копать?Resok, 04 Дек. 21, 23:14

Возможно, самый простой вариант использования ноута вместо малинки - купить USB-I2C адптер (только который именно мастер!) и подключить шину I2C к крейту. Питание +5V и +3.3V подать от отдельного источника. Линии RES и INT проигнорировать. Если поставить на ноут Linux, то, скорее всего, ничего больше не потребуется. Расскажите, pls, если будете делать. Мне тоже, как и Евгению, очень интерено.

Т.е. малинка выполняет перезагрузку всех модулей снятием и последующей подачей питания.OldBean, 08 Дек. 21, 10:53

Только учитывай в этом случае, что с резисторов подтяжки ОБЯЗАТЕЛЬНО тоже снимать плюсовое питание. Просто многим датчикам (и даже OLED дисплеям) хватает паразитного питания через подтягивающие резюки, и соответственно сброса/перезагрузки глюканувшего устройства не произойдет.

дать малинке возможность управлять питаниемOldBean, 08 Дек. 21, 10:53

А малинкин USB-контроллер позволяет включать-выключать питание на портах?

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

https://github.com/mvp/uhubctl

Все мозги накормить из USB и делать RESET по питанию. На мой вкус так наверное даже лучше.
Жырно было бы индивидуально дергать питание модулям. Какой-нить i2c-io чип одноканальный с полевичком на каждый модуль прилепить.

Можно мосфеты использовать, подключенные к какому-нибудь свободному пину GPIO малинки (или, к тому же USB, если не малинка). Можно погрубее - низковольтные реле. Если же в каком-нибудь модуле предусмотрен свой независимый источник питания логики, то сигналом для его отключения/подключения может служить отсутствие/присутствие напряжения на линии +5V. Соответствующее реле может просто тупо висеть на линии +5V. Таким образом, по каскаду, можно обесточить всю логику и, заодно, все подтяжки. Т.е. линию RES можно исключить "ваще как класс" :)

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

PS
Про линию INT

В принципе, малинка может работать с шиной i2c и как slave (ведомое устройство). Глубоко не копал, но как-то пробовал - вроде даже откликалась. Если не изменяет память, то для 3-й малинки, как ведомого устройства, линия SCL это GPIO 18, а линия SDA - это GPIO 19. Или наоборот? Если эти пины повесить на соответствующие линии шины i2c, то любой на шине контроллер, выступая уже как мастер, сможет обратиться к малинке и рассказать ей про свои насущные нужды. Это будет гораздо информативней, чем просто бинарная линия INT.

Таким образом сценарий отработки нештатных ситуаций может выглядеть следующим образом. Если шина i2c заблокирована, то малинка просто тупо перезагружает всю логику путем выключения питания. Если же i2c работает, то переволновавшийся контролер (уже как мастер) может захватить шину и послать малинке (уже как слейву) пакет со своими тревогами.
---------------
Нужно как-нибудь копнуть этот вопрос поглубже. Глядишь - и линия INT тоже не будет нужна. Тоже как класс. Так может и целая витая пара освободиться. Например, для дополнительного питания. Или наоборот, если 24V не нужно, то всю i2c сеть можно будет всего на четырех проводах (двух витых парах) слепить... :)

мосфеты использовать, подключенные к какому-нибудь свободному пину GPIO малинкиOldBean, 09 Дек. 21, 05:59

Хороший очевидный вариант в случае "материнки с отключаемыми слотами для модулей". Но если начать раскидывать модули по углам -- это будет уже борода а не шина. На этот случай первое что приходит в голову -- i2c-адресовательная отключалка питания на каждом модуле. Больше почему-то ничего не приходит..

захватить шину и послать малинке (уже как слейву) пакет со своими тревогамиOldBean, 09 Дек. 21, 05:59

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

i2c-адресовательная отключалка питания на каждом модулеmakh, 09 Дек. 21, 14:15

Не пойдет такое... Выше как раз рассматривали аварийный вариант, когда вешается все шина I2C

А почему бы контроллеру просто не записать в статус-регистры соответствующие значения?makh, 09 Дек. 21, 14:15

Можно и так. Через периодические опросы. Это проще в реализации - на первом этапе сойдет. Однако через прерывания, таки, идеологически правильней. Настоящая одноранговая i2c-сеть получится! Peer-to-peer, так сказать... ;)

Немножко поспорю за идеологию.

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

В идеально жырной ситуации мы бы дали модулям индивидуальный INT. Чтоп понимать где горе и насколько оно критично. Если с данным модулем может возникнуть только одна нештатная ситуация -- можно принимать решение что делать дальше. Если более одной -- захочется таки опросить модуль на предмет текущих параметров. И таки да, решение будет принято на менее чем секунду раньше, нежели при периодическом опросе. Ну вот ни разу не критично с нашими железками, ИМХО.

Ну вот ни разу не критично с нашими железками,makh, 10 Дек. 21, 01:58

В общем-то да. Времена не те :). Согласен. А с другой стороны, никто же не мешает малинке, как равной среди равных в пиринговой i2c-сети, периодически обращаться к контроллеру с запросом о его чувствах. Посылать кого-либо по сети (особенно малинку) контроллерам просто запретим ;).

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

А с точки зрения организации сети, авторитарный режим самый простой. Конечно, с него и имеет смысл начать. В этом случае и софт, который сейчас есть, менять почти не придется. Только слегка расширить функционал модулей. В том числе и по части формирования статуса.

Ноутбук не позволяет подключать датчики и управлять клапанами.sig, 05 Дек. 21, 13:56

Да и к Малинке датчики и клапана подключены не напрямую, а через i2c (теперь уже с "удлинителем") и контроллеры. Так что никто не мешает вместо "удлинителя" поставить Адруину с примитивным скетчем которая своим Serial смотрит в USB ноутбука и получает от него команды, а через i2c раздает эти команды контроллерам и получает от них ответы закидывая эти ответы обратно через Serial в USB ноута. Соответственно, питоновские скрипты нужно будет поправить чтобы они не искали i2c на ноуте, а работали с /dev/tty* под Линуксом или COM* под Виндой.

Ноут физически не способен сутками работать как сервер.

Мягко говоря спорное утверждение...

А почему бы контроллеру просто не записать в статус-регистры соответствующие значения?makh, 09 Дек. 21, 14:15

И дальше классический пинг-понг мастера со слейвом:
- мастер регулярно посылает слейвам запрос/команду - типа "как дела, дружище?"
- слейв отвечает что у него все хорошо при этом поднимает у себя флаг - "мастер жив" и ближайшие N секунд вкалывает не разгибаясь
- если эти N секунд прошли, а мастер ничего нового не прислал, то слейв понимает что кто-то халявит, работать не обязательно и прекращает активные действия (щелкать клапаном, греть ТЭН и тд)
- еще через N*2 секунд слейв понимает что мастер пропал и ловить тут нечего и просто перегружается в надежде на то что это был зависон i2c.
- мастер также ждет ответа от слейва и по истечении Z секунд помечает слейв аварийным, дальнейшие действия зависят от стратегии - мастер может ждать, перегрузится, отправить СМС оператору и тд.

То есть ничего нового, всё это придумано много лет назад.

А с точки зрения организации сети, авторитарный режим самый простой. Конечно, с него и имеет смысл начать. В этом случае и софт, который сейчас есть, менять почти не придется. Только слегка расширить функционал модулей. В том числе и по части формирования статуса.OldBean, 10 Дек. 21, 06:03

Т.е. INT и RES в перспективе будут удалены? Из железа можно их вырезать?
...

до полного разгула демократииOldBean, 10 Дек. 21, 06:03

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

только брутальная диктатура!makh, 10 Дек. 21, 12:45

Для автоматизации процессов никакого плюрализма быть не может.
В нашем случае Slave должен быть только таким https://translate.google.com/...mp;op=translate
Кстати, Modbus Organization в свете общемировой тенденции переименовала Master/Slave в Client/Server, что конечно прибавило контроллерам свободы и независимости. :-)

Для автоматизации процессов никакого плюрализма быть не может.Tomat7, 10 Дек. 21, 13:24

Не-не. Конечно не может.
А если без шуток, то в данном случае речь идет просто о возможности реализации распределенной автоматики на базе пиринговой сети. Или (как альтернатива!), о механизмах реализации прерываний в рамках концепции "master-slave".

Т.е. INT и RES в перспективе будут удалены? Из железа можно их вырезать?BogAD, 10 Дек. 21, 10:18

Частично - да. Без специальной выделенной линии RES точно можно обойтись.

Давайте общий сброс (RES) реализуем через выключение питания по линии +5V. Для модулей с собственным/автономным питанием логики, ноль на линии +5V как раз и будет означать сигнал сброса. Эта линия (+5V) все равно будет заходить в любой модуль как "обвивка" линии SDA. Ну а этот собственный/автономный источник питания нужно проектировать так, чтобы он подавал питание для своих подопечных только если на линии +5V есть напряжение (+5V). Таким образом малинка сможет "дотянуться" до любого модуля в i2c-сети и на какое-то время обесточить его. Т.е функционал линии RES легко реализуется при помощи уже имеющейся линии +5V. Линия RES - лишняя сущность.

О линии INT. В принципе, при работающей шине i2c, периодический запрос малинкой статусов других устройств - приемлемое решение. Если же шина колом встала, то все равно малинка должна инициировать перезагрузку всех модулей. Ну а если уже и перезагрузка всех модулей не помогла, то аварийное завершение работы. Тем не менее, предлагаю все-таки еще немножечко подумать о возможных вариантах реализации механизма прерываний в нашей i2c-сети. Взвесить все плюсы-минусы...

Некоторым модулям нечего будет аварийно сигналить. Тот же измерительный сервер, например. Ему дела нет до того, в процессе работы отвалился градусник, или это я с установкой ковыряюсь. А вот окончание измерительного цикла сигналить вполне мог бы. Шоп цыфры в системе поактуальней были. Ну да, секунда-полсекунды разница, но ведь приятно )

Боюсь, вывод INTа из коробки плохо кончится. Как минимум какими-то ограничениями топологии проводов, типа 1 девайс на порт. А тут кто-то гирлянды внешних девайсов хотел помню, и васче хотплужность это важно.. Или это будет один INT на всю гирлянду..

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

Одним портом можно попробовать подключить гирлянду из двух внешних девайсов -- GND+SDA, GND+SCL, INT0+VCC0, INT1+VCC1.
Как-то ассоциировать прерывания с контроллерами придется думать.. Мутно.. Я б забил на это дело..

Как-то ассоциировать прерывания с контроллерами придется думать.. Мутно.. Я б забил на это дело..makh, 11 Дек. 21, 02:46

Да нет... Все планировалось гораздо проще и прозаичнее.

Малинке-мастеру сейчас приходится опрашивать устройства довольно часто (1 раз в 2 секунды). Это немножко напрягает. Если бы контроллеры могли бы сами опрашивать датчики, которые им нужны (в новой версии так и планируется), то малинке остались бы только мониторинг и "общее руководство" процессами. Тогда опрашивать все устройства малинка могла бы пореже. А если протоколирование не нужно, то вообще лишь изредка. При переходе к следующей стадии процесса, по велению пользователя или когда что-то пошло не так. В этом случае периодический опрос в конфигурации мастер-слейв - ну совсем слабенькое решение :(( Ведь не зря же люди придумали такую штуку, как прерывания! Поэтому и была введена ОДНА линия INT, подтянутая к VCC, по которой любое устройство, роняя INT в ноль, могло было бы сигнализировать малинке, что требуется ее вмешательство в процесс. Если на INT низкий уровень, то в Малинке инициировалось бы прерывание и она, либо напрямую нештатно опрашивала бы все устройства, либо через General Call по нулевому адресу и далее разбиралась бы кто и зачем бил тревогу. Но до конкретной реализации этого механизма в варианте LITE (с крейтом) руки так и не дошли.

На тот момент я не знал, что у SoC Broadcom (у малинки) есть возможность работать с i2c не только в качестве мастера, но и слейва. А как узнал, то, естественно, ткнул пример из инфы. Он вроде сработал (i2cdetect показал заданный адрес малинки как слейва). Глубже пока не смотрел, но стало понятно, что, в принципе, можно организовать прерывания малинки не только по выделенной линии INT, но и по той же шине i2c. Следующим образом : контроллер, который хочет срочно связаться с малинкой объявляет себя мастером (т.е. генерирует на шине start, сигналы SCL) и обращается к малинке по ее slave-адресу, инициируя нужное прерывание по i2c.

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

Малинке-мастеру сейчас приходится опрашивать устройства довольно часто (1 раз в 2 секунды). Это немножко напрягает.OldBean, 11 Дек. 21, 08:17

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