Форум самогонщиков Сайт Барахолка Магазин Соточку можешь?

Создадим свой открытый протокол обмена данными между контроллером и модулями

Форум самогонщиков Автоматика
1 2 3 4 ... 12 1
mak Модератор Екатеринбург 6.3K 1.8K
14 Июля 15, 13:54
Все больше появляется вариантов самодельной автоматики с использованием микроконтроллеров.
Эта тема будет неспешный задел на будущее и попытка выработать протокол обмена данными между контроллером и исполнительными модулями, такими как датчики, клапаны, насосы, силовые нагрузки, регуляторы мощности и т.п. учитывая специфику нашего дела.
Чем может быть интересно - разнесение в пространстве модулей, гибкая конфигурация и ведение параллельных процессов.
Еще один важный момент, пожалуй на начальном этапе самый важный - стандартизация формата лога и обозначений который генерирует контроллер и отдаёт в последовательный порт
Логом могут пользоваться устройства, не имеющие прямого сопряжения с автоматикой
например насосы, узлы отбора, устройства маршрутизации потока и т.п.
mak Модератор Екатеринбург 6.3K 1.8K
Отв.1  14 Июля 15, 13:54, через 1 мин
Для того, чтобы учесть варианты нужно перебрать какие исполнительные модули могут быть
Вот что приходит пока в голову
1. Блок датчиков
     До 8 датчиков температуры.
     До двух датчиков давления.
2. Блок исполнителей вкл/выкл. (клапан и др.)
     До 8-ми каналов. Реле, симисторы, SSR
3. Перистальтический насос
     До 4-х каналов управления.
4. Узел отбора типа "лифт"


mak Модератор Екатеринбург 6.3K 1.8K
Отв.2  14 Июля 15, 13:54, через 1 мин
Серийный номер устройства.
Первая прикидка
(XXX)-(TT)-(MM)-(ZZZZZZ)
XXX - Идентификатор производителя
TT - тип устройства.
MM - модификация устройства
номера по договоренности, но до 099 - не использовать, резерв
ZZZZZZ - уникальный номер устройства
начиная с 000100. до 000099  - тестовые устройства
mak Модератор Екатеринбург 6.3K 1.8K
Отв.3  14 Июля 15, 13:55, через 1 мин
(Черновик)
формат лога генерируемого контроллером
dd.mm.yyyy hh:mm:ss "операция" "исполнитель" "параметр" "значение"
например контроллер без RTC будет относительное время выдавать
01.01.0000 02:14:42 GET TEMP_KUB TEMP 82.3
01.01.0000 02:14:43 SET UZEL_OTB_TELO SPD 35%
mak Модератор Екатеринбург 6.3K 1.8K
Отв.4  14 Июля 15, 13:55, через 1 мин
резерв
mak Модератор Екатеринбург 6.3K 1.8K
Отв.5  14 Июля 15, 13:55, через 1 мин
резерв
mak Модератор Екатеринбург 6.3K 1.8K
Отв.6  14 Июля 15, 13:56, через 1 мин
резерв
V_B Академик Таганрог 2.7K 920
Отв.7  14 Июля 15, 21:19
Для того, чтобы учесть варианты нужно перебрать какие исполнительные модули могут бытьmak, 14 Июля 15, 13:54
Это для одной колонны или для "многотрубного" устройства?
mak Модератор Екатеринбург 6.3K 1.8K
Отв.8  14 Июля 15, 21:48, через 29 мин
нужно учесть все варианты я думаю


m16 Модератор Тамбов 1.9K 1K
Отв.9  14 Июля 15, 22:47, через 60 мин
разнесение в пространстве модулейmak, 14 Июля 15, 13:54
назови хотя бы одну причину для организации 3d модульности в нашем деле.
ведение параллельных процессовmak, 14 Июля 15, 13:54
учитывая специфику нашего делаmak, 14 Июля 15, 13:54
специфика нашего дела не требует вычисление полиномов , рядов, преобразований всего лишь контроль вялотекущих изменения температуры и давления по которым проц лениво открывает и закрывает клапаны, зевая регулирует мощность на тэне , нехотя крутит шаговиками и взбодряеться лишь при расчёте среднеквадратичного тока(напряжения) и пид-регулятора и при этом чего-то выплёвывает на дисплей. а при желании смс пошлёт хозяину с отчётом о своей скучной работе. в наказание его можно заставить вести лог о проделанной работе. и со всей этой хернёй справится один жирный(многоногий) авр. не хватает авровских таймеров - есть пик24, стм32 на худой конец.
зачем ещё сковывать сетью кучу лаботрясов?
mak Модератор Екатеринбург 6.3K 1.8K
Отв.10  15 Июля 15, 05:20
m16, давай попробуем
1. Контроллер в комнате а аппарат на балконе/кухне/сарайке
2. Одновременно работают несколько процессов - нбк, ректификация, дистиллятор, затирание

Обеспечив каждый модуль своим МК основной контроллер очень сильно разгружается,
Программа заметно упрощается.
V_B Академик Таганрог 2.7K 920
Отв.11  15 Июля 15, 10:58
1. Контроллер в комнате а аппарат на балконе/кухне/сарайкеmak, 15 Июля 15, 05:20
По этой причине и переделал свой контроллер: сделал отдельно блок возле колонны, который только обрабатывает датчики, крутит шаговые, управляет силовыми симисторами и клапанами, и на столе небольшой пульт с дисплеем и кнопками, в котором вертятся все алгоритмы, подключенный по USB к ПК для сохранения логов. Сеть - CAN.
mak Модератор Екатеринбург 6.3K 1.8K
Отв.12  15 Июля 15, 11:05, через 7 мин
V_B, Именно!
Еще программа основного контроллера разгружается очень прилично, можно сосредоточиться на пользовательском интерфейсе, алгоритмах и внешним взаимодействии.
Физическая реализация сети дело уже второе, CAN или RS485, или и то и то
Дятел Новичок NA 554 118
Отв.13  15 Июля 15, 11:11, через 7 мин
Имхо,если говорить о контроллере для обычного пользователя, то получаем либо однокристальный вариант, либо двух- с вынесенным контроллером для управления высоковольтными клапанами и стабилизацией мощности.
Если делать по второму варианту ( я лично к нему склоняюсь) -  то контроллер можно сказать будет спать.
Да и вообще о загрузке контроллера в этой задаче ( управления ректификацией)   не приходится, некоторые проблемы возникают с таймерами и прерываниями, но не с вычислительной мощью ядра.
ПК, логи -  это все больше для экспериментатора, но не рядового пользователя.

mak Модератор Екатеринбург 6.3K 1.8K
Отв.14  15 Июля 15, 11:28, через 18 мин
Дятел, пусть спит. ресурсы лишними не бывают, хуже когда наоборот
У нас из процессов не только ректификация есть. есть еще нбк, варка сусла, дистилляция как минимум. Даже перемешивание браги по таймеру.
и нередко хотелось бы вести эти процессы параллельно
Капитан_Немо Доктор наук Москва 843 477
Отв.15  15 Июля 15, 12:01, через 33 мин
Насколько я понял, речь идет о создании некоего подобия блока управления входами-выходами в промышленных контроллерах. Например, как это реализовано в Siemens Simatic.

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

Рассмотрим, для примера, управление температурой. На входе I1 у нас висит термопара, которая поставляет в контроллер сигнал в виде разности потенциалов. Блок входа-выхода должен считать этот сигнал, высчитать температуру, которой он соответствует, и передать ее ЦП в виде "I1, 70". В программе ЦП стоит проверка, что если I1 меньше 80 градусов, надо включить нагрев, подав сигнал на выход O1. ЦП передает блоку входов-выходов команду "O1, TRUE", а блок входов-выходов на основе этого подает на выход, где висит нагревательный элемент, питание, т.е. включает его.

В связи с этим комментарии:
- нам понадобится, по существу, два протокола: один для обработки сигналов с устройств, другой для передачи их в программу ЦП;
- при наличии достаточно большого количества устройств один датчик, воткнутый "не в ту дырку", обрушит сразу несколько процессов, следовательно, нужен еще признак процесса, к коорому относится то или иное устройство.
mak Модератор Екатеринбург 6.3K 1.8K
Отв.16  15 Июля 15, 12:16, через 15 мин
Капитан_Немо, нет, ты не правильно понял
речь идет о создании протокола обмена между контроллером и исполнительными устройствами.
Реализация этих устройств и даже физическая реализация канала связи за рамками данной темы
Капитан_Немо Доктор наук Москва 843 477
Отв.17  15 Июля 15, 13:57
Тогда получается, что надо продумывать как минимум три вещи:
- формат идентификации устройства и установления сессии с контроллером;
- формат идентификации команды как контроллером от устройства, так и устройством от контроллера;
- формат передачи числовой информации, т.е. значений переменных.

Так?
mak Модератор Екатеринбург 6.3K 1.8K
Отв.18  15 Июля 15, 14:05, через 9 мин
вначале нужно продумать какими данными и в каком формате нам нужно обмениваться
создать структуру
mak Модератор Екатеринбург 6.3K 1.8K
Отв.19  15 Июля 15, 14:42, через 37 мин
т.е. сначала описать структуры данных и формат их передачи так, чтобы была возможность даже читать в консоли - т.е. понятно взгляду
далее спускаемся уровнем ниже на уровень опроса контроллеров и продумываем протокол.