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

И обсуждаем мы методы создания таких файлов-алгоритмов.sig, 30 Авг. 21, 18:25

Это понятно. Но что мешает дать возможность пользователям незначительно отходить в настройках от шаблона? Например вы создали шаблон, где отбор заканчивается при Т в кубе 99.4 градуса, а я марамой и мне хочется ещё немножко спирта отжать. Вот в графическом интерфейсе и нарисовать ползунок со шкалой 98.00-99.8. И каждый пользователь сам себе подстроит этот параметр.
То есть пользователь не будет сидеть с инструкцией, как обезьяна с гранатой, и вводить одной кнопкой, смотря на двустрочный экран, что значение Р 12 равно 99,8, а просто подвинул ползунок и всё.
Или не учить питоны с сисей+, для переписывания кода, а просто подвинуть ползунок.
А в слово "программирование" я просто вкладывал немного другой смысл. С помощью визуального интерфейса запрограммировать поведение железа в системе. Как программируется кофеварка.

А в слово "программирование" я просто вкладывал немного другой смысл. С помощью визуального интерфейса запрограммировать поведение железа в системе.Shobby, 30 Авг. 21, 18:34

В том-то и дело, что поведение системы как бы "состоит" из двух частей. 1) Первая часть - данные (параметры системы/процесса и данные с датчиков). Это как раз о чем Вы говорите. 2) Вторая часть - алгоритмы. Это - "правила" по которым система обрабатывает данные и реагирует на них. Это как раз то, о чем говорит коллега sig. А всякие движки и ручки на экране - это называется "графический пользовательский интерфейс" (GUI). GUI для автоматики в общем-то не очень-то и нужен - в тренде "минимализма" малинка может работать и без дисплея (с единственной кнопкой - "старт").

По поводу параметров. В данной версии библиотеки, изменить параметры можно двумя способами. 1) Поправить значение пользовательской переменной непосредственно в файле пользовательского скрипта. Там никакого знания питона не требуется. Это обычный текстовый файл. Например, в шаблоне для дистилляции там обязательно будет строка похожая на "u.T0_end = 99.4 # Конечная температура в кубе". Ее легко найти и поправить в любом текстовом редакторе на, например, "u.T0_end = 99.8" и сохранить файл. Если же вдруг приспичило изменить этот параметр уже в процессе, то в последней версии библиотеки есть, так называемый, "универсальный клиент". Запускаете клиента на любом компьютере в локальной сети (или просто на той же малинке, если она с клавиатурой, мышкой и экраном, в отдельной консоли) и пишете там "u.T0_end = 99.8" (естественно, без кавычек) и жмете Enter.

На заметку! Наверное, стОит, для удобства и легкости ориентирования, вынести все пользовательские параметры процесса в отдельный конфигурационный файл. Пользователю, которому не нужно менять алгоритмы так будет гораздо удобнее. Хорошо. Принято! В следующей версии библиотеки это будет реализовано. Кстати, этот же config-файл можно будет использовать для "подсказок" в клиенте и при написании скриптов. И словарь более содержательных имен объектов (типа Tкуб вместо T0) можно разместить там же.

Гораздо хуже обстоит дело с какими-нибудь "дружественными" средствами для написания самих пользовательских алгоритмов. Программист-то это легко сделает в любом текстовом редакторе. А как быть непрограммисту? Как он сможет рассказать малинке о своем новом супер-алгоритме дистилляции, который он только что придумал? Причем, так "рассказать", чтобы она (малинка) его поняла однозначно. Вот в чем вопрос! Здесь "движками" и "ручками" уже не обойтись ;)

Наверное, стОит, для удобства и легкости ориентирования, вынести все пользовательские параметры процесса в отдельный конфигурационный файл. Пользователю, которому не нужно менять алгоритмы так будет гораздо удобнее. Хорошо. Принято! В следующей версии библиотеки это будет реализовано. Кстати, этот же config-файл можно будет использовать для "подсказок" OldBean, 31 Авг. 21, 06:03

Хорошее предложение по конфигурационному файлу и словарю.

Гораздо хуже обстоит дело с какими-нибудь "дружественными" средствами для написания самих пользовательских алгоритмов. Программист-то это легко сделает в любом текстовом редакторе. А как быть непрограммисту? Как он сможет рассказать малинке о своем новом супер-алгоритме дистилляции, который он только что придумал? Причем, так "рассказать", чтобы она (малинка) его поняла однозначно. Вот в чем вопрос! Здесь "движками" и "ручками" уже не обойтись в клиенте и при написании скриптов. И словарь более содержательных имен объектов (типа Tкуб вместо T0) можно разместить там же.OldBean, 31 Авг. 21, 06:03

Чтоб было непрограммисту освоить написания алгоритма работы автоматики в пользовательском скрипте, нужно сделать по этому подробный букварь как составлять этот алгоритм. Хоть и прокомментирована практически каждая строчка, но непрограммистам это недостаточно, нужны более полные комменты.
Подробно разобрать, как говорится, полеты на примере одного пользовательского скрипта.
Ну и мысли в слух... Сергей, давно думаю назрело..., как на счет "расширения" системы не только на ректификационную колонну, а так же к НБК, ПВК и т.д.? У нас практически весь обвес имеется, кроме управления шаговиками.

Подробно разобрать, как говорится, полеты на примере одного пользовательского скрипта.BogAD, 31 Авг. 21, 09:47

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

давно думаю назрело..., как на счет "расширения" системы не только на ректификационную колонну, а так же к НБК, ПВК и т.д.? У нас практически весь обвес имеется, кроме управления шаговиками.BogAD, 31 Авг. 21, 09:47

В общем-то никаких проблем с шаговыми двигателями нет - это очень простой модуль. Он практически будет совпадать с модулем сервы. Можно будет их даже объединить в один модуль. Как люди делают. Только класс-обертку нужно будет написать.

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

PS
Я уже давно уже хотел ненавязчивую автоматизацию сделать не на крейте, а в виде "этажерки" над малинкой, и посмотреть как все это будет выглядеть. Удобно или нет. Естественно, вся высоковольтная часть будет вынесена отдельно. По софту практически никаких изменений не будет. Но, возможно, будет удобно. Часть модулей для автоматизиции можно будет брать готовые (не например, как для шаговиков и серв, по ссылке выше), а часть "в стандарте малики" ;))) можно разработать самим. Ну, в частности, силовые модули, 1-Wire хаб и т.п. Они специфические. Найти их готовые вряд ли удастся. Закажу-ка я на али несколько плат расширений для малинки, более-менее связанные с нашей тематикой. Хороший повод перейти к практическим шагам в этом направлении. Интересно, ведь! Платку RTC+WatchDog уже заказал на днях. Вот такой бюджетный ПЛК получится. Как настоящий, взрослый! ;)))

В общем-то никаких проблем с шаговыми двигателями нет - это очень простой модуль. Он практически будет совпадать с модулем сервы. Можно будет их даже объединить в один модуль. Как люди делают. Только класс-обертку нужно будет написать.

А можно и вообще взять готовый модуль с али. Например, такой и просто воткнуть его в малинку, а уже сверху воткнуть - шлейф на сигнальную шину крейта. Кстати, туда еще и 4 сервы можно подключить. Правда возможны некоторые проблемы с автоматичесим распознаванием конфигурации железа. Система, конечно, определит, что по данному адресу что-то сидит, но что конкретно - скорее всего не определит. Но это не страшно. Можно как с датчиком атмосферного давления сделать привязки типов устройств к I2C адресам. Для первого приближения - пойдет и готовый.OldBean, 31 Авг. 21, 11:41

Сергей, думаю лучше дистанционный драйвер управления шаговым двигателем!
Поясню - некий отдельный насос со своим питанием, своим контроллером с экраном и управлением энкордером или кнопками.
В автономке он должен уметь дозированно качать и разливать, согласно ручным командам. К примеру как умеют данные решения, которые уже обсуждались на форуме:
[Перистальтический насос на шаговом двигателе и ардуино в качестве мозгов] и [Перистальтический насос на 3D принтере]

Нужен так же дистанционные режим управления, т.к. насос может "мигрировать" на удаленный режим работы, поближе к бродильной емкости. Потребность в этом определяется по ситуации. К примеру бражка стоит в отдельном помещении, а колонна в другом. Не каждый хочет слушать жужащий перистальтический насос. Лучше убрать его подальше. Это как в примерах реализовали в указанных темах по управлению ими по ШИМ от HelloDistiller, но...
Это будет недостаточно. Малинка должна знать как себя "чувствует" насос, не порвалась ли трубка, нет ли аварийных событий, включая остановку по команде местной кнопки на насосе, какая текущая скорость, какой объем перекачен и т.д. Т.е. нужна обратная связь...
Т.к. у нас есть опыт использования с 1-Wire, почему бы не использовать данный протокол? Я уже примерно схему набросал...

думаю лучше дистанционный драйвер управления шаговым двигателем!BogAD, 31 Авг. 21, 12:07

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

PS

ИМХО, все равно малинка со всеми причиндалами должна быть где-то около установки. Или Вы хотите сделать что-то распределенное. Вроде "умной лаборатории". По аналогии с "умным домом"? Тогда здесь должна быть другая идеология и архитектура: автономные устройства, с возможностью ручного управления, объединенные в сеть типа IoT. У меня только не совсем укладывается в голове задача. Зачем? Ведь здесь не нужно согласованное управление одновременно несколькими установками. Если можно, опишите схему работы чуток подробнее. Почему нельзя, например, использовать камеру для визуального контроля? Зачем вся эта дополнительная городьба с возможностью автономной (ручной) работы?

Так никто и не заставляет драйверы шаговиков размещать рядом с малинкой! Да и датчик протечек тоже. Но зачем сам контроллер-то уносить далеко?OldBean, 31 Авг. 21, 12:31

А какое предложение?
Есть перистальтический насос под управлением шагового двигателя - силовые провода до драйвера с питанием от отдельного БП на напряжение от 24В и выше - управляющие провода до контроллера.
Это отдельный блок. Или не так?

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

Зачем вся эта дополнительная городьба с возможностью автономной (ручной) работы?OldBean, 31 Авг. 21, 12:31

Ок, вопрос понял.
Ввиду того, что перистальтический насос (голова+шаговый двигатель) один за самых дорогостоящих компонентов (не беру во внимание самодельные головы), в целях экономии и не собирать кучу насосов под разные задачи, хочется заложить функционал под эти задачи в один насос, контроллер которого должнен работать без малинки, автономно:
1. Регулировать скорость и направление вращения
2. Регулировать поток в л/час или мл/мин
3. Качать заданное количество жидкости, порционный разлив по емкостям
4. Калибровка под шланг. Хранение в памяти калибровку под несколько размеров шланг.
5. Плавный старт/стоп.
7. Подсчет "моторесурса" шлангов.
8. Другие плюшки, типа углевание, проточная мецерация.
9. Отслеживание аварийных состояний
9. Ну и внешнее управление от 1-Wire с обратной связью...
Смысл заставлять для этого малинку? Пускай отдельный блок трудится когда надо. А если понадобился, будет работать в составе системы под внешним управлением от малинки...

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

Схема, которую Вы нарисовали выше, в принципе, решает эту задачу. Я бы, правда, воткнул 2 МК, связанных каким-нибудь быстрым интерфейсом, который реализован аппаратно (например, USART или I2C). На один МК я бы повесил только шаговик, а на второй - 1-Wire, дисплей и кнопки. Это несколько облегчило бы программирование. Но можно и так, как у Вас нарисовано. На одном МК. Таки, 1-Wire достаточно "резиновый" протокол. :)))

А еще проще - использовать два насоса для этих разных задач. Не такие уж они (насосы) и дорогие (если просто головка+шаговик). Для автономного прибора есть готовые решения, ссылки на которые Вы приводили выше, а для встраиваемого в автоматику варианта - простые решения на готовых контроллерах с али.

А... Ну вот теперь все стало более-менее понятно. Вы хотите использовать перистальтический насос как некий автономный лабораторный прибор для решения разных лабораторных задач, связанных с перекачкой жидкостей и не требующих автоматизации. Но! Кроме этого, прибор должен иметь цифровой интерфейс, позволяющий подключить его к управляющему компьютеру (контроллеру) для проведения автоматических процессов.OldBean, 31 Авг. 21, 18:24

Да, вкратце так.

Схема, которую Вы нарисовали выше, в принципе, решает эту задачу. Я бы, правда, воткнул 2 МК, связанных каким-нибудь быстрым интерфейсом, который реализован аппаратно (например, USART или I2C). На один МК я бы повесил только шаговик, а на второй - 1-Wire, дисплей и кнопки. Это несколько облегчило бы программирование. Но можно и так, как у Вас нарисовано. На одном МК. Таки, 1-Wire достаточно "резиновый" протокол. ))OldBean, 31 Авг. 21, 18:24

Думаю один МК справится. Если использовать достаточно мощный драйвер на основе DM542, ТВ6600, или что-то подобное. От МК требуется только генерировать один импульс на один шаг. Ну и 2 вспомогательных сигнала - на реверс и включения драйвера.
А для 1-Wire нужно эмулировать 1-wire slave. Схему подсмотрел из статьи тут. Но.. в программной части разобраться ума нет.

А еще проще - использовать два насоса для этих разных задач. Не такие уж они (насосы) и дорогие (если просто головка+шаговик). Для автономного прибора есть готовые решения, ссылки на которые Вы приводили выше, а для встраиваемого в автоматику варианта - простые решения на готовых контроллерах с али.OldBean, 31 Авг. 21, 18:24

если имелось виду подобный контроллер

А можно и вообще взять готовый модуль с али. Например, такой и просто воткнуть его в малинку, а уже сверху воткнуть - шлейф на сигнальную шину крейта.OldBean, 31 Авг. 21, 11:41

то думаю что слабый будет, 1,2А при 12В хороший насос не вытянут...

Думаю один МК справится. Если использовать достаточно мощный драйвер на основе DM542, ТВ6600, или что-то подобное. От МК требуется только генерировать один импульс на один шаг. Ну и 2 вспомогательных сигнала - на реверс и включения драйвера.BogAD, 31 Авг. 21, 19:46

Так готовый проект с внешним управлением для перистальтики от Phisik есть и на данном форуме, если уж задумана модульность, зачем изобретать велосипед?
Хотя конечно в столь простой задаче (устройств у нас в процессах ограниченное количество), я не сильно понимаю зачем все усложнять кучей модулей.
Есть практически линейная задача, понятно что со вложенными циклами, но рулиться то все практически любым "тупеньким" контроллером. Какая то бОльшая мощность МК, нужна только на реализацию GUI, ну или обработку внешних так скажем скриптов (для предустановленных/заданных задач).

p.s. Извиняйте если обидел с задуманным подходом к решению вопроса...

Так готовый проект с внешним управлением для перистальтики от Phisik есть и на данном форуме, если уж задумана модульность, зачем изобретать велосипед?serjrv, 01 Сент. 21, 01:12

Насколько я понял, Александр прекрасно знает про насосы Phisik-а. Он сам и приводил ссылку в своем топике выше. Для внешнего управления там используются ШИМ. Если я правильно понял, но в детали не вникал. Генерирование ШИМ в данной автоматике представлены двумя модулями: силовой модуль с ШИМ (используется для клапана отбора) и контроллер сервы (используется для фракционирования). Поскольку Александр знает о существовании насоса Phisik-а, то вероятно, у него были какие-то соображения по поиску других решений.

я не сильно понимаю зачем все усложнять кучей модулей.serjrv, 01 Сент. 21, 01:12

Почему-то мало кто обращает внимание на название данной темы. В названии "ненавязчивая автоматика" как раз и отражен главный концепт этой автоматики :))) В рамках этого концепта, пользователь не изготавливает или покупает коробочку с автоматикой (сразу за 10-20 тыструб.) и с широкими возможностями, большая часть которых никогда не будет использоваться, а "взращивает" свою систему постепенно по мере появления новых задач и новых потребностей. Покупая или изготавливая дополнительные модули под свои конкретные задачи. При этом облегчается не только финансовая нагрузка. Упрощается апгрейд. Упрощается программирование, т.к. МК каждого модуля занят только своим "подопечным" (датчиком или исполнительным устройством). Вспомните какой прогресс был достигнут при переходе от "лапши" к модульному программированию. А ООП!? Полученные бонусы многократно превысили дополнительные расходы компьютерных ресурсов. В модульном подходе к железу тот же смысл: интеллектуализация каждого датчика и исполнительного устройства при помощи "личных" МК и инкапсуляция деталей их аппаратной реализации при помощи классов-оберток резко упрощает жизнь.

Так готовый проект с внешним управлением для перистальтики от Phisik есть и на данном форуме, если уж задумана модульность, зачем изобретать велосипед?serjrv, 01 Сент. 21, 01:12

Вы не внимательны. Я указал вариант от Phisik в сообщении вчера. И уже упоминал что уже есть реализация управление по ШИМ.
А ну ка, организуйте по данной схеме обратную связь чтобы насос общался с головным устройством и говорил об своем состоянии...

Хотя конечно в столь простой задаче (устройств у нас в процессах ограниченное количество), я не сильно понимаю зачем все усложнять кучей модулей.serjrv, 01 Сент. 21, 01:12

Интерфейс 1-Wireуже организован в модуле "Хаб 1-Wire устройств". Так что дополнительный модуль не понадобится.

Есть практически линейная задача, понятно что со вложенными циклами, но рулиться то все практически любым "тупеньким" контроллером. Какая то бОльшая мощность МК, нужна только на реализацию GUI, ну или обработку внешних так скажем скриптов (для предустановленных/заданных задач).serjrv, 01 Сент. 21, 01:12

Я не думаю, что реализация управления по 1-wire перистальтическим насосом (лучше двумя) сильно просадит малинку, и даже МК модуля "Хаб 1-Wire устройств".
GUI свет клином сошелся... Я тоже люблю экранный плюшки, но в данном варианте реализации от уважаемого OldBean'а как корове седло.
Тем более OldBean реализовал "Токен и ID telegram чат". Т.е. пользовательский скрипт можно настроить для получения некоторых полезных сообщений от работающей установки через
telegram-канал.

Да, вкратце так.BogAD, 31 Авг. 21, 19:46

Ну что ж, давайте продолжим обсуждение нашего лисапеда ;))) Можем себе позволить?

Чуток обобщим задачу. Мы рассматриваем устройства, которые можно использовать как автономно (с ручным управлением), так и в рамках автоматики. Многие лабораторные приборы имеют интерфейс для подключения к контроллеру. Часто это RS232, его клоны и потомки ;))) Наличие интерфейса часто бывает очень полезны. Но, кроме дороговизны, мне сильно не нравятся две вещи в таких приборах.

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

2. Второе, что мне не нравится - избыточность. Она чувствуется. Особенно, если такого рода устройств несколько. Насосы, весы, плитки (индукционные и простые) и т.п. Кстати, в первой версии "ненавязчивой автоматики" каждое исполнительное устройство имело два указанных выше интерфейса. Для человека и для контроллера (малинки). Потом я от этого отказался, т.к. просто не смог решить эту дилемму. Тем не менее, самым простым решением было бы оставить в устройстве один единственный интерфейс. Это может быть Wi-Fi, I2C, USB, 1-Wire и т.п. Но какой-то один. А для того, чтобы человек мог подключаться к этому интерфейсу, дать ему в руки пульт. Универсальный. Один для всех устройств. Пультом может быть смартфон с соответствующим адаптером (через USB), либо специализированная "коробочка". Для автономной работы, человек подключает пульт к устройству и управляет. Для автоматической работы через этот же разъем устройство подключается к автоматике. Это бы сильно упростило разработку таких устройств.

Конечно, эти рассуждения выглядят достаточно абстрактно, но мы можем обсудить их позже. Когда будет конкретика. А для начала давайте определимся с физическим интерфейсом для такого рода устройств. Вы предлагаете 1-Wire. Но 1-Wire хаб первоначально планировался для датчиков и класс-обертка написан исходя именно из этих соображений. Это связано с популярность датчиков DS18B20 для наших целей. Для их параллельной работы и одновременного чтения данных с них. А насос - исполнительное устройство. И просто так в хаб его воткнуть нельзя. Конечно там предусмотрена возможность работать с одним каналом (за счет маскирования) и возможность расширения списка команд (для исполнительных устройств). Но это в полной мере не реализовано и изменения кода будут существенными. Класс-обертка хаба в свое время много крови у меня попил. Очень не хотелось бы сильно в него залезать. Самое простое (с точки зрения программирования) для подключения исполнительных устройств это I2C. Они и сидят все на этой шине. Если не изменяет память, то длина шины I2C для скоростей до 100 кбод/сек может доходить до 1м. Это для витой пары. Хватит ли такой длины для подключения насоса к автоматике? Если нет, то можно уменьшить скорость, но не желательно. Или вообще что-нибудь типа USB. В малинке USB-порты есть, да и Arduino Nano имеет аппаратный USB...

Мы имеем устройство (например, тот же насос), у которого для выполнения одних и тех же задач есть два совершенно разных интерфейса. Один для человека. Это кнопочки, энкодеры, дисплейчик (простой или сенсорный) и т.д. А другой интерфейс - для контроллера (управляющего компьютера). Мне не нравится что эти интерфейсы разные, независимые и часто односторонние. Что будет если насос подключен к автоматике, успешно чавкает, а человек подошел и крутанул ручку энкодера?OldBean, 01 Сент. 21, 14:39

Не думаю что это вызывает затруднение. Явно приоритет управления должен быть отдан автоматике, и если процесс с участием данного устройства присутствует в алгоритме, то к примеру с периодичностью 1 - 10 сек. шлем по выбранной шине данные для устройства. Пока данные с заданным периодом прилетают на устройство, просто блокируем ручное управление.

Пока данные с заданным периодом прилетают на устройство, просто блокируем ручное управление.serjrv, 01 Сент. 21, 15:26

Ну а как в этом случае быть со второй коллизией:

Или наоборот, человек видит что трубка насоса вот-вот порвется, пытается выключить насос, а автоматика тупо "поддает жару", как этого требует алгоритм.OldBean, 01 Сент. 21, 14:39

Будем смиренно ждать разрыва и протечки, который система сможет наконец-то обнаружить своим датчиком?

Будем смиренно ждать разрыва и протечки, который система сможет наконец-то обнаружить своим датчиком?OldBean, 01 Сент. 21, 16:08

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

Ну а как в этом случае быть со второй коллизией...OldBean, 01 Сент. 21, 16:08

Тоже не вижу проблемы, т.к. можно предусмотреть или комбинацию кнопок с длительным (или частым) нажатием на блокировку или паузу в работе, или вообще отдельную кнопку (можно даже с фиксацией) предусмотреть на этот случай.
В общем думаю что двустороннее управление вообще проблем не вызывает, по крайней мере сам в определенных местах это использую, бардака с управлением нет.

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

По идее, при работе в автоматическом режиме изменения состояния энкодера должны передаваться на управляющий контроллер (Малинку в нашем случае), проверяться на корректность и вызывать изменения в алгоритме управления.sig, 01 Сент. 21, 17:12

Очень не удобно и не практично в реализации.

пока с работы добирался, обсуждение началось...

Ну что ж, давайте продолжим обсуждение нашего лисапеда )) Можем себе позволить?OldBean, 01 Сент. 21, 14:39

Конечно обсудим, Сергей!

У меня такие мысли, чтоб коллизий не было. Допустим насос со своим МК, дисплеем, органами ручного управления (кнопочки или энкодер) и "группой безопасности" в виде датчика разлития и красного грибка "СТОП". МК может связываться с головным устройством по интерфейсу и в этом случае должен быть Slave. Если МК видит подключенный интерфейс, и он успешно "приконектился" к головному устройству, происходит блокировка только органов управления насосом. Но... "группа безопасности" в любом случае должна быть в высшем приоритете обработки аварийных событий. Т.е. человек увидел аварийную ситуацию, нажал на грибок "СТОП", насос должен остановиться и сообщить по интерфейсу головному устройству о нажатии кнопки "стоп". Так же должно отрабатываться событие на срабатывание датчика разлития. В остальном должна быть блокировка ручного управления при дистанционном управлении. Дисплей оставляем при любом режиме - на него можно выводить текущую информацию информацию о режиме работы насоса. Это по первому пункту...
По второму пункту надо сильно думать...
Я не спорю, можно использовать любой интерфейс. Вышеперечисленные имеют право на рассмотрение, но... интерфейс должен быть простым, надежным, проводным, обеспечивать "горячее" подключение и хорошую помехоустойчивость. К
На счет 1-Wire хаба понял, жаль. Но 1-Wire можно и самой малинкой обрабатывать, без 1-Wire хаба. Вот только посерьезней надо защитить схематически от сюрпризов с линии. Может посмотрим в сторону асинхронного интерфейса RS485? Ну а что, есть куча схем готовых и модулей под UART-RS485.

Если МК видит подключенный интерфейс, и он успешно "приконектился" к головному устройству, происходит блокировка только органов управления насосом.BogAD, 01 Сент. 21, 17:17

Так и я абсолютно о том же. И тут даже нет необходимости в двустороннем обмене. Просто распишу свою реализацию в одном из устройств:
Заводим таймер к примеру на 1 сек., и в нем у нас по прерыванию происходит инкремент переменной до ее максимального значения, т.е. уперлись в максимум, инкремент не делаем (при старте данной переменной сразу присваиваем максимальное значение). В подпрограмме приема пакета данных от ведущего устройства (малинка в данном случае), просто обнуляем эту переменную (конечно если данный пакет именно этому устройству предназначен). В подпрограмме обработки ручного управления просто анализируем значение данной переменной, увидели к примеру значение этой переменной 5 и не режим СТОП при этом - пискнули для привлечения внимания, добежали до 10 - просто все остановили. А т.к. переменная (счетчик) уже ушла выше контролируемых значений - становится доступным ручное управление. Естественно при таком подходе данные от управляющего контроллера должны идти с определенной периодичностью, не превышающей минимальный контролируемый временной интервал.

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

1. Итак, мы имеем устройство "двойного назначения". Первое назначение - это автономная работа с ручным управление, второе - работа в рамках автоматики под управлением контроллера.

1.1. "Горячее" подключение к контроллеру пока не предусмотрено.
1.2. При включении прибора активированы оба интерфейса (ручной и внешний), приоритет не устанавливается. Дисплей на приборе, естественно, работает всегда.
1.3. При инициализации контроллера, если прибор подключен к автоматике, ему посылается команда по которой контроллеру присваивается высший приоритет. Ручной интерфейс либо блокируется, либо имеет низший приоритет (только в случае двунаправленного интерфейса с контроллером (!)). Это состояние сохраняется на протяжении всего процесса, но может быть изменено либо нажатием "красной кнопки" на приборе (см.п.1.4), либо другой командой, меняющей приоритеты.
1.4. В приборе предусмотрена "красная кнопка" при нажатии которой приоритеты меняются. Ручное управление приобретает высший приоритет. Отработка команд контроллера (кроме команд смены приоритета) блокируется. Бразды правления (высший приоритет) можно опять вернуть контроллеру посылкой той же команды, что и при инициализации.

Ничего не забыл? Вроде бы достаточно для разруливания коллизий.

2. Список исполнительных устройств, которые могут быть реализованы как устройства "двойного назначения". В принципе, на этих приборах можно собрать очень широкий класс установок (для наших целей), которые могут работать как при "ручном", так при автоматическом управлении от контроллера. Может стОит именно так реализовать следующий вариант "ненавязчивой автоматики"? Скажем, "вариант NEXT" :)))

2.1. Перистальтические насосы с шаговыми двигателями
2.2. Клапанные дозаторы (регулировщики потока).
2.3. Весы на тензодатчиках.
2.4. Электроплитки комфорочные. Возможно, индукционные (см. Примечание 1).
2.5. Регуляторы (стабилизаторы?) мощности для активных нагрузок (см. Примечание 2).
2.6. Многоканальный термометр (см. Примечание 3).

Это только то, что мне сразу пришло в голову. Возможно его нужно расширить?

---

Примечание 1. Нужно глубоко влезать в схему управления плиткой. Возможно ли найти универсальное решение? Мне пока приходит в голову лишь одно универсальное решение - регулировка напряжения питания плитки. Т.е. что-то вроде "электронного ЛАТРа", но хорошего решения на уровень нескольких кВт я пока не видел.

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

Примечание 3. Наверное, пока можно ограничиться датчиками DS18B20 и 8-ю каналами. Какого-то управления здесь не предусмотрено (если дисплей достаточный), либо кнопочка выбора датчика, т-ра которого будет показываться (если дисплейчик слабенький).