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

PavelSaratov, у меня есть исполнитель - насос
Я получаю с него данные тарирования
Читаю код ошибки
Читаю текущий пробег трубки
Читаю текущую конфигурацию
Отдаю ему старт/стоп
Направление вращения
Скорость вращения
И еще по мелочи

Вот вам спецификация по полю температура. Продолжать будем?PavelSaratov, 09 Янв. 17, 16:48

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

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

PavelSaratov, у меня есть исполнитель - насосmak, 09 Янв. 17, 16:48

многие функции будет исполнять само устройство и не нужно читать его состояние постоянно. Пример с форточкой: нужно открыть форточку зачем мне писать подхожу к форточке, тянусь к шпингалету, поворачиваю шпингалет когда команда может быть простой открыть форточку на 30 % и все, а контроллер форточки уже сам открывает шпингалет, смотрит открыта ли форточка нужно ли ее вообще открывать если она на 30% уже открыта.

В общем сдаюсь. Посмотрю что у вас выйдет.PavelSaratov, 09 Янв. 17, 17:23

Мне не сдача нужна, а помощь. Есть некие тонкости которых я могу не знать. Я бы уже давно написал этот протокол но.... Чем больше общаюсь с умными людьми тем больше идет отточка. Что мне нужно от Вас. Какие датчики и исполнительные устройства могут быть. Термометр,датчик влажности,и.т.д. Нужно таблицу. Потом определиться какие параметры от этих датчиков нужно получать.Какие исполнительные устройства могут быть и соответственно какие параметры они могут получать. Чем точнее будут описания тем лучше, можно в форме диалога а я уже буду конспектировать. Пример: допустим датчик температуры назначим ему код 01. Теперь параметры которые ему можно отослать ? здесь нужно думать что можно, а вот какие параметры с него можно получать понятно это температура, формат этих данных можно взять за основу формат данных от датчика температуры DS18B20 два байта последняя тетрада дробная часть, так получим температуру в пределах +-2047 градусов с точностью 1/16 градуса. Если будет датчик температуры другой то формат данных все ровно как у DS18B20 должен быть. 

terminal, зачем доводить все до абсурда? Удорожить DS18B20 в несколько раз только чтобы запихнуть его показания в некий "универсальный" протокол? Чем 1wire вдруг стал плох?

Ваш насос далек от универсальности, их бывает тьма разнаяPavelSaratov, 09 Янв. 17, 16:53

угу, это я к тому что нижеприведенная супер универсальная структура данных не катит
регулятор мощности у меня отдает активную, реактивную и полную мощность, ток, напряжение текущие и пиковые, позволяет устанавливать мощность в ваттах, в %..

Вот вам супер универсальная структура данных, пользуйтесь:
Температура
Давление
Положение по шкале 0-100%
Состояние
Расход
Напряжение
Ток
Время
Текстовое сообщение для пользовательской (какой угодно вспомогательной) информации.PavelSaratov, 09 Янв. 17, 16:41

короче понятно ))

структура данных не катит
регулятор мощности у меня отдаетmak, 09 Янв. 17, 20:16

Ну и рассматривай свой регулятор мощности как несколько датчиков

зачем доводить все до абсурда? Удорожить DS18B20 в несколько раз только чтобы запихнуть его показания в некий "универсальный" протокол? Чем 1wire вдруг стал плох?sevpro, 09 Янв. 17, 19:11

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

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

Ну и рассматривай свой регулятор мощности как несколько датчиковNewocelot, 09 Янв. 17, 21:00

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

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

А если кто к этому блоку захочет еще свой блок приделать то нет необходимости писать все с начала достаточно будет сделать запрос и получить все параметры или в случае исполнительного блока параметры отправить.

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

И получится что к примеру расчет ПИД лучше запустить на малинке а регулятор мощности сделать на AVRке.Малинке резать синус не с руки а AVRке расчетами заниматься.

Ну и рассматривай свой регулятор мощности как несколько датчиковNewocelot, 09 Янв. 17, 21:00

а зачем?

А зачем вообще обьединять оборудование разных производителей? И где это делать? Допустим у винокура есть РМ, есть пивной контроллер с градусником, который управляет нагревом по паузам и пищит когда сыпать, есть контроллер клапана отбора или фракционника для ректа и диста, есть контроллер управления насосом НБК.
Есть контроллер безопасности и удаленного мониторинга. И что он будет это от разных производителей брать?
Ну ладно, пускай. Ему для увязывания всего вместе в рамках какой-то активности все равно потребуется центральный контроллер, который будет всем этим барахлом дирижировать по тому алгоритму, который нужен винокуру. Ну а в контроллере верхнего уровня можно что угодно наворотить - один, два или сто разных протоколов, а потом заявить список поддерживаемого оборудования. Главное, чтобы у оборудования наружу интерфейс торчал. Любой, закрывающий функциональость данного устройства. Рассказать о себе и получить команду. Так как по функциональности устройства не навороченные - и протоколы у них не навороченные - дольше унифицировать, чем реализовать задуманный автором проприетарный протокол.
Взять ту же малинку: ног у нее порядочно. Сэмулировать 232 порты для связи точка-точка с каждым (из двух-четырех) используемых в активности устройств и общаться с ними на их языках. Коллеги, могу ошибаться, но смысла не вижу в затее. Прошу прощения.
Да и было бы с кем общаться - на рынке практически ничего нет. А раз сам делаешь - делаешь для себя. Если есть желание и время - рассказываешь как сделать то же самое другим.

когда датчиков 10 то на их обработку уйдет все процессорное времяterminal, 09 Янв. 17, 21:23

нафига 10 датчиков температуры колоне?

нафига 10 датчиков температуры колоне?sevpro, 09 Янв. 17, 23:16

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

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

Теперь зачем все это. Для меня это совершенно другой уровень системы. Вот как пример ситуация с датчиками. В такой системе могут применяться как датчики DS18B20 так и собственнх разработак на термо паре. Причем для замены датчика с одного на другой не надо тратить кучу времени на переписывание всей программы. Достаточно заменить блок датчиков.

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

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

Если у тебя есть время и желание - че ты сразу не купишь промышленный ПЛК? Во я никак не могу понять.

И совет всем кто заморачивается по протоколу: Посмотрите что такое OSI модель. И когда вы чето начинаете обсуждать - обсуждайте один уровень этой модели а не прыгайте как кому заблагорассудится: один универсальную таблицу обмена хочет создать, другой считает потерянные пакеты, третий вообще оценивает мощность протокола по количеству бит в пакете (это вообще финиш). http://infocisco.ru/network_model_osi.html

PavelSaratov, универсальную таблицу обмена? що это?

допустим не 10 а два, один основной второй дублирующий. Допустим основной датчик выходит из строя контроллер управления понимает что датчик вышел из строя и переключается на дублирующий делает пометку в статусе что нужно поменять датчик 1 но процесс работы при этом не останавливается.terminal, 10 Янв. 17, 04:06

Ого! Вот уже до горячего резервирования и дублирования систем добрались. Вы точно автоматику для спиртоварки делаете, а не для систему управления МКС?
Я же говорю, что идея доходит до абсурда - навесить на каждый датчик, каждое исполнительное устройство свой МК при этом они все равно будут заваливать ненужным мусором ЦП: кто-то хочет весь обмен с DS1820 продублировать в сеть более высокого уровня, кто-то сообщать ЦП реактивную мощность и пиковое напряжение, при этом не прозвучало ответа на главный вопрос, который задают уже несколько человек: кому этот протокол нужен? Ведь у каждого задачи свои. terminal, насколько я понял, хочет подтянуть все это к "умному дому" с туевой кучей датчиков и исполнителей, makу нужно логирование удаленного процесса, кому-то интересна коммерциализация ("вот разработают протокол и буду я на форуме под него MPX5010 продавать..."). Все тянут одеяло на себя.
Задачи у всех настолько разные (а тем более разные знания), что проект этот изначально мертворожденный.
Мне видится единственный путь: это если кто-то сделает опенсорсное действительно достойное внимания универсальное центральное устройство управления, которое действительно многие захотят подтянуть к своему оборудованию, только тогда возникнет необходимость обсуждать и физический протокол, и необходимый и достаточный объем данных, и пр., а до тех пор будет сплошное "хочу"

PavelSaratov,
лог это не таблица обмена, это просто список событий
для обработки лог должен иметь определенный формат

который задают уже несколько человек: кому этот протокол нужен?sevpro, 10 Янв. 17, 07:15

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

mak, ОК. Сколько у нас на форуме Пупкиных и Васькиных, которые не могут подружить свое оборудование?
Первоначально должен возникнуть продукт о котором большинство скажет: "Вот это да, вот это круто, хочу свои имеющиеся насосы, клапана и пр. подключить к этому чуду" А пока лошадь впереди телеги, абстрактные пупкины, абстрактные устройства.
Вон возникла у человека нужда к автоматике msg31 подключить насос Игоря223, дописал несколько строк к коду и по ШИМу подключил, не стал приделывать туда и туда 485, CAN и иже с ним, Задачи нужно решать по мере поступления и решения должны быть адекватными. А пока предлагается разработать универсальное решение для задач, которые еще не посталены

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

Задачи нужно решать по мере поступленияsevpro, 10 Янв. 17, 07:51

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

А пока предлагается разработать универсальное решение для задач, которые еще не посталеныsevpro, 10 Янв. 17, 07:51

я пока просто предлагаю подумать о разнообразии объектов с которыми работаем, о структуре данных и о журнале событий контроллеров

А пока лошадь впереди телеги, абстрактные пупкины, абстрактные устройства.sevpro, 10 Янв. 17, 07:51

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

я пока просто предлагаю подумать о разнообразии объектов с которыми работаем, о структуре данных и о журнале событий контроллеровmak, 10 Янв. 17, 08:16

Согласен.

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

Вот в соседней ветке обсуждают датчик спиртонутости, на каком бы принципе он не был основан на выходе нам нужно содержание спирта в градусах. Если это электрические величины то ток-Амперы, напряжение-Вольты, Градусы,проценты и.т.д. на самом деле не так много.