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

Все больше появляется вариантов самодельной автоматики с использованием микроконтроллеров.
Эта тема будет неспешный задел на будущее и попытка выработать протокол обмена данными между контроллером и исполнительными модулями, такими как датчики, клапаны, насосы, силовые нагрузки, регуляторы мощности и т.п. учитывая специфику нашего дела.
Чем может быть интересно - разнесение в пространстве модулей, гибкая конфигурация и ведение параллельных процессов.
Еще один важный момент, пожалуй на начальном этапе самый важный - стандартизация формата лога и обозначений который генерирует контроллер и отдаёт в последовательный порт
Логом могут пользоваться устройства, не имеющие прямого сопряжения с автоматикой
например насосы, узлы отбора, устройства маршрутизации потока и т.п.

Для того, чтобы учесть варианты нужно перебрать какие исполнительные модули могут быть
Вот что приходит пока в голову
1. Блок датчиков
     До 8 датчиков температуры.
     До двух датчиков давления.
2. Блок исполнителей вкл/выкл. (клапан и др.)
     До 8-ми каналов. Реле, симисторы, SSR
3. Перистальтический насос
     До 4-х каналов управления.
4. Узел отбора типа "лифт"

Серийный номер устройства.
Первая прикидка
(XXX)-(TT)-(MM)-(ZZZZZZ)
XXX - Идентификатор производителя
TT - тип устройства.
MM - модификация устройства
номера по договоренности, но до 099 - не использовать, резерв
ZZZZZZ - уникальный номер устройства
начиная с 000100. до 000099  - тестовые устройства

(Черновик)
формат лога генерируемого контроллером
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, 14 Июля 15, 13:54

Это для одной колонны или для "многотрубного" устройства?

нужно учесть все варианты я думаю

разнесение в пространстве модулейmak, 14 Июля 15, 13:54

назови хотя бы одну причину для организации 3d модульности в нашем деле.

ведение параллельных процессовmak, 14 Июля 15, 13:54

учитывая специфику нашего делаmak, 14 Июля 15, 13:54

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

m16, давай попробуем
1. Контроллер в комнате а аппарат на балконе/кухне/сарайке
2. Одновременно работают несколько процессов - нбк, ректификация, дистиллятор, затирание

Обеспечив каждый модуль своим МК основной контроллер очень сильно разгружается,
Программа заметно упрощается.

1. Контроллер в комнате а аппарат на балконе/кухне/сарайкеmak, 15 Июля 15, 05:20

По этой причине и переделал свой контроллер: сделал отдельно блок возле колонны, который только обрабатывает датчики, крутит шаговые, управляет силовыми симисторами и клапанами, и на столе небольшой пульт с дисплеем и кнопками, в котором вертятся все алгоритмы, подключенный по USB к ПК для сохранения логов. Сеть - CAN.

V_B, Именно!
Еще программа основного контроллера разгружается очень прилично, можно сосредоточиться на пользовательском интерфейсе, алгоритмах и внешним взаимодействии.
Физическая реализация сети дело уже второе, CAN или RS485, или и то и то

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

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

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

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

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

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

Капитан_Немо, нет, ты не правильно понял
речь идет о создании протокола обмена между контроллером и исполнительными устройствами.
Реализация этих устройств и даже физическая реализация канала связи за рамками данной темы

Тогда получается, что надо продумывать как минимум три вещи:
- формат идентификации устройства и установления сессии с контроллером;
- формат идентификации команды как контроллером от устройства, так и устройством от контроллера;
- формат передачи числовой информации, т.е. значений переменных.

Так?

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

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