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

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

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

Пока не вижу, как это поможет человеку, который гонит не в коммерческих масштабах, и время для него не критично. 

Дятел, я же написал эта тема задел на будущее
У меня сейчас уже есть несколько прикидок по контроллеру, насосы, регуляторы мощности, будет блок датчиков, блок исполнителей
Пока в процессе осмысления протокола обмена.
Так что необходимость уже есть. Но не хочу пилить только под свои задачи. Шире как-то хочется
Капитан_Немо, Нет. просто контроллер и исполнительные устройства, как в умном доме. пришло время - открылись шторы.
Человеку которому время не критично можно и ручками покрутить гофмана постоять в процессе.

mak, все придумано до нас!!!
Бери за основу протокол CAN.
Все пакеты, которые передает контроллер, имеют идентификатор.
Каждому параметру, вычисляемому в системе присваивается свой идентификатор.
Например температура куба - ID 100. Не важно где в системе она вычисляется, главное что в сети она всегда передается с этим адресом. Все узлы принимают ее и только те, которым она нужна ее берут и работают с ней, причем даже не зная о месте ее вычисления.
Давление - ID 101 и т.д.
Назначая приемные маски в контроллере можно на канальном уровне отсекать не нужные пакеты и принимать только нужные!

В CAN да. Только нужно идентификаторы с умом подобрать. Вроде там еще есть система приоритетов по захвату шины.
Хотя в нашем случае - это не так важно, не автомобиль чай.

Вроде там еще есть система приоритетов по захвату шины.ys1797, 15 Июля 15, 16:43

Есть, только она уже на канальном уровне реализована.
Поэтому и рекомендовал именно CAN применить - заморочек потом будет гораздо меньше, очень много реализовано в аппаратном драйвере!

Не везде к сожалению can можно вкорячить
Нужно и так и так иметь возможность работать.
Система будет все равно с одним мастером.

Не везде к сожалению can можно вкорячитьmak, 15 Июля 15, 17:19

Ну хоть ты не "наступай на грабли, которые уже били по лбу не одного проектировщика"!!!
Не экономь на микроконтроллере - это потом окупиться простотой реализации и временем написания кода!

С одним мастером не очень удобно например аварийные ситуации обрабатывать.

Ну хоть ты не "наступай на грабли, которые уже били по лбу не одного проектировщика"!!!
Не экономь на микроконтроллере - это потом окупиться простотой реализации и временем написания кода!V_B, 15 Июля 15, 19:30

Если самому все узлы делать - не вопрос, я уже CAN оценил
Но возьмем насос перистальтику на ардуино - его могут собрать те кто не особо дружит с пайкой.
Но CAN туда уже не влезет, все под завязку, только rs485
Аналогично с РМ на ардуино. CAN шилд очень недешевый.
Поэтому нужно проработать оба варианта.

mak, надо просто оставить идею самостоятельной сборки без пайки и все. если ее оставить, то нужно двигаться к stm32 + can, другой дороги нет просто.
с другой стороны если будет STM32, то он запросто справится со всеми нашими задачами один. включая отсылку данных на комп по вайфаю например

g100m, речь пока о протоколе, неважно какая физическая реализация
потихоньку накидываю варианты

я прото, что обеспечить качественный протокол CAN по вычислительной мощности сопостовимо с мощностью самой системы.
как-то это ненормально. я бы вообще все сделал по UART и не заморачивался. на приемнике 5 раз проверил контрольную сумму и делов-то.

g100m, can это нижний уровень, транспорт так сказать.
А нужно описать универсальную структуру данных для обмена между модулями, про это речь

mak с Днем Рождения!

can это нижний уровень, транспорт так сказать.mak, 01 Авг. 15, 13:31

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

Вот как раз все параметры которые нужно передать и получить описываю
Нужно учесть что не только can
Еще и обычный последовательный

А обычный и привычный ethernet не рассматривается в качестве сети?
И шильдики для ардуинок недорогие, и, так сказать, инфраструктура в зачаточном состоянии в наличии в каждом домохозяйстве -- модем/роутер.
Да и работать было бы удобно, широковещательными пакетиками, любой зоопарк разрулить можно, хоть локально, хоть удаленно через криптованные каналы...

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

mak, с днюхою!

Я не великий реализатор в железянном или программном аспектах
Однако как постановщик задач уже все зубы сьел.
Поэтому я понимаю точно, что В-Б прав на стопятьсот процентов.
И Г100м прав не меньше.
Только, и исключительно промышленный протокол обмена, и желательно так, как в современных автомобилях сделано. Чтобы вкорячить автосигнализацию раньше полмашины нужно было разобрать. Сегодня - пару часов, с несомненно высшим на порядок сервисом для пользователя.
Однако на практике вообще далеко не всегда есть нужда в какой то связи. наоборот, в 90% случаев она не нужна, поскольку системы у нас
достаточно примитивны, соттветственно и реализации - тоже.

В порядке же маниловщины могу высказать свои соображения.
Нужно, чтобы все устройства в сети имели два провода для соединения. Как минимум.
Ну то есть земля и питание 12Вольт (или 24В)
По которым бы и передавались все сигналы двустороннего обмена данными.
Все.

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

П.С. Впрочем, подозреваю: для этого нужен не проктолог протокол, а просто нормальный промышленный дизайнер)))

я говорю не только про протокол, вообще про все хозяйство. его получится больше, чем исполнительного кода

makh, Спасибо
Ethernet не рассматриваю в этом качестве. Дорого и избыточно.
Для построения многоузловой сети нужен коммутатор и соединение звездой
В stm32 can уже есть, а rs485 стоит копейки
игорь223, согласен полностью с тобой.
При возможности использования CAN - только его.
Обратная связь нужна для диагностики исполнителей. Ну и для передачи данных, таких например как данные тарирования у насоса, параметров сети от РМ и т.п.
Беспроводка - неоднозначно.
Да и навесить все модули на одну витую пару не так проблематично