Jump to content

Recommended Posts

Вот здесь http://www.insyte.ru/powerdriveabout/ можно подсмотреть концепцию построения для тех, кто хочет делать без центрального хоста.

Неплохая мысль: хост используется только чтобы запрограммировать все оконечные устройства. Причем каждое обладает минимальным интеллектом, но с возможностью настройки типа "включиться, если [условие1] или [условие2] или ..."

Вот ещё интересно почитать (на русском) их инструкции http://insyte.ru/downloads/Manual_LanDrive_Config.pdf

и формат команд http://insyte.ru/downloads/Modbus_formats_LanDrive.pdf на вариант по витой паре (Modbus)

Да, а в варианте по витой паре они всё-таки применяют главный контроллер...

Edited by YurkaM

Share this post


Link to post
Share on other sites
Прохладненько, однако у вас в комнате :D

Там на фото видно что к плате идёт два провода, просто датчики температуры не подключены вот контроллер и выдаёт "-0.0" Кстати это уже давно исправлено, теперь он пишет 'error'.

Share this post


Link to post
Share on other sites

Литиевые батарейки Fanso для систем телеметрии и дистанционного контроля

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

Подробнее

Народ, давай те что собирать.

К примеру связь через 220В, хост и 1 выключатель. Хост естественно мастер, исполнители (или терминалы, пусть так назавем - слэйв). Лично для меня сча задача, как слэв подпитать от 220, габариты имеют место

Share this post


Link to post
Share on other sites
                     

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

Компэл совместно с Texas Instruments 23 октября 2019 приглашают на вебинар, посвященный системам-на-кристалле для построения ультразвуковых расходомеров жидкостей и газов на базе ядра MSP430. Вебинар проводит Йоханн Ципперер – эксперт по ультразвуковым технологиям, непосредственно участвовавший в создании данного решения. На вебинаре компания Texas Instruments представит однокристальное решение, позволяющее создавать точные недорогие счетчики жидкостей и газов.

Подробнее...

2Lexi: давай начнем с малого - спроектируй и разведи устройство по управлению светом. Заложись на возможность добавить туда какой-нибудь интерфейс для связи. Лучше, если можно будет доабвить произвольно выбранный через переходную схему может даже. Таже фигня и для питания, если такое возможно.

Вот потом можно будет и собрать девайс.

Может кто возьмет на себя ответственность по другим устройствам?

Edited by pivasik

Share this post


Link to post
Share on other sites

Я тут вкратце набросал что умеет мой девайс (см пост #104). Если кому интересно можно и обсудить это. Архив прилагается:

system.rar

Share this post


Link to post
Share on other sites

Я начинаю разработку системы, но это коммерческий проект. Кто тут займеться хостом. И еще проблемма, все говорят дай, а кто сам что даст?? Сделайте хост, а я под него и заделаю девайс. По тем протоколам которые бедут заложены там. А идею стырить дело не хитрое.

Share this post


Link to post
Share on other sites

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

Вот тока я не знаю, у кого хватит возможностей его сделать... Дбровольцы есть? :)

Share this post


Link to post
Share on other sites

Для этого разработчики объеденяют усилия и договариваться. Давайте арвщики, делайте хост. Я на пике слелаю исполняющее устройсто, управление освещением на 3 "зоны". Управление люстрой )). Адрес 0x00h, опрос-0x00h или задача 0x01h, номера зон:1-ая зона 0x00h, 2-0x01h и третья 0x02h. команды: 0x00h - тушим, 0x01h - включаем. Вот синтаксис запрос [адрес][опрос][зона], ждем ответа [адрес][зона][состояние]. Вот синтаксис камнда [адрес][зона][состояние], ждем ответа [адрес][зона][состояние]. У меня будет 2 реле 1 кнопка. Хост должен опрашивать постоянно все адреса, особенно всякие датчики и кнопки, т.е. элементы управления. По их изменеию давать команду на реле включить или выключить - это в моём случае. Как понимаете все наращиваеться по адресам. Только придумывай как и что это дело описать. Какое правило общения будет в сети (по 220, по 380, по 10кВ шутка). Суть в том что сдесь не важно как подавать сигнал, а важно то, что в нем идет.

Share this post


Link to post
Share on other sites
Вот синтаксис запрос [адрес][опрос][зона]

Вот синтаксис камнда [адрес][зона][состояние]

допустим принята посылка : [0x01][0x01][0x01].

Что это:

- устройству с адресом 0x01 в зоне 0x01 сделать команду 0x01

или устройству с адресом 0x01 запрос зоны 0x01 ???

Как-то надо наверно тщательнее продумпать это дело....

Share this post


Link to post
Share on other sites

может вот так сделать. Чуть длиннее, зато универсальней. Пусть в пакете будет всегда 5 байтов:

[адрес кому][адрес от кого][запрос/команда/ответ/...][зона][параметр]

Здесь зона может не только указывать реально зону, а быть просто внутренним адресом, регистром. Параметр может означать разное в зависимости от конкретного назначения устройства и данной зоны, т.е это может быть просто 1-вкл/0-выкл. или 0...255 если это яркость или время зажигания и т.д.

"Адрес кому" = 0x00 пусть означает "всем". 0x01 - Хость. 0x02...0xFF конечные устройства. И кстати остаётся лазейка для работы без хоста...

Третий байт оставляем как было, т.е 0x00-запрос, 0x01- команда. Дальше может ещё чего понадобиться, допустим 0x02 - ответ, 0xAA - инициализация и т.п.

Edited by YurkaM

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Температура, смотря с какой точностью, но тоже в байт может не поместиться.

Да малоличем еще оперировать придется.

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

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

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

В таком случае, если заголовок-окончание для всех пакетов одинаковые, любое устройство читает заголовок, смотрит мое/чужое. Мое - берет, чужое - отсчитывает нужное число байт.

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

Сейчас рассмотреть все системы "умного дома" до мелочей мы не в состоянии, переругаемся и все.

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

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

Персоналка или что другое - опять "гайка М3".

Мы с общим видом не разобрались, еще что у нас в доме стоять будет не знаем, а уже думаем о реализации.

Share this post


Link to post
Share on other sites
Персоналка или что другое - опять "гайка М3".

Мы с общим видом не разобрались, еще что у нас в доме стоять будет не знаем, а уже думаем о реализации.

Да причем здесь гайка? Я говорю не о реализации, а о способе достичь её! Именно не заморачиваясь чего там будет в конце концов в качестве хоста. Комп удобен на этапе наладки и настройки.

Share this post


Link to post
Share on other sites

1. В сети с несколькими каскадами как будет адресоваться узел? Например, это может быть 00.01.04.01.FF, где FF - маркер широковещательного пакета.

2. После подключения нового узла как контроллер зоны будет узнавать о новичке? Возможно это будет рассылка на адрес FF - широковещательная внутри текущей подзоны, с параметрами подключившегося устройства или запросом на выделение адреса. Соответственно, контроллер уведомляет верхний уровень о подключившемся и т.д.

3. Будет ли конечное устройство предоставлять сведения о себе по запросу? Например, после подключения корневой контроллер может запросить Human readable имя устройства ("Управлятор люстры на 5 секций") или назначить ему новое.

4. Будет ли, и если будет то как уведомляться контроллер верхнего уровня уведомляться об ошибках? Например, при посылке контроллером подсети 00.01 в подсеть 04.01 узлу 05, обнаружилось, что подсеть 01 недоступна - как уведомлять об ошибке?

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

Share this post


Link to post
Share on other sites

Узел виден для хоста в виде набора регистров, все регистры могут работать как на запись так и на чтение. 1 - код устройства. 2 - включено или выключено. 3 - яркость (если она регулируется). 4 - освещённость (если она измеряется этим устройством). 5,6 - значение с первого датчика температуры. 6,7 - значение со второго датчика температуры. 8,9 - принятый код по RC5. 10 - код нажатой кнопки (если это клавиатура). 11 - регистр состояния, в этом регистре выставляются биты в зависимости от произошедших событий и сбрасываются только центральным хостом после прочтения нужных регистров.

Share this post


Link to post
Share on other sites

pivasik, Да вы с ума сошли! Нахрена такие сложности?? Какие каскады? Какие подсети? Вы такого монстра до ума не скоро доведёте, если вообще доведёте!!

2 После подключения нового устройства ручками прописываем его в хосте и всё!

3 Ненадо никакого имени. Просто предусмотреть возможность установки адреса на каждом девайсе. Ну как максимум можно прописывать жестко ID в каждый девайс на этапе прошивки мозгов. Если хочется красивые имена типа "Управлятор люстры на 5 секций", это можн вбивать уже в хосте, например так:

post-31916-1191931708_thumb.jpg

Edited by YurkaM

Share this post


Link to post
Share on other sites
Поэтому я и предлагал плавающий пакет, с указанием размера блока данных. По крайней мере каждому стройству будет пересылаться именно то, что ему надо.

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

В таком случае, если заголовок-окончание для всех пакетов одинаковые, любое устройство читает заголовок, смотрит мое/чужое. Мое - берет, чужое - отсчитывает нужное число байт.

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

Согласен. Тогда нужно уточнить. Мысль такая. В каждом пакете обязательными будут первые три байта, а за ними блок данных:

Вопрос: в какое место поставить [длина пакета]? Или это будет только длина блока данных?

Варианты:

1) [кому][от кого][длина пакета]<блок данных>

2) [кому][от кого][длина блока данных]<блок данных>

3) [длина пакета][кому][от кого]<блок данных>

Вариант, когда первым идет адрес назначения удобнее для обработки приемником (ИМХО). Когда чужое, то просто пропускаем этот пакет и ждём следующий.

Edited by YurkaM

Share this post


Link to post
Share on other sites

Извините за вклин.

Считаю, что конт. сумма - обязательна. И еще не помешает ответ слейва мастеру об успешном принятии/выполнении команды (если комманда адресована одному).

Share this post


Link to post
Share on other sites
Согласен. Тогда нужно уточнить. Мысль такая. В каждом пакете обязательными будут первые три байта, а за ними блок данных:

Вопрос: в какое место поставить [длина пакета]? Или это будет только длина блока данных?

Варианты:

1) [кому][от кого][длина пакета]<блок данных>

2) [кому][от кого][длина блока данных]<блок данных>

3) [длина пакета][кому][от кого]<блок данных>

Вариант, когда первым идет адрес назначения удобнее для обработки приемником (ИМХО). Когда чужое, то просто пропускаем этот пакет и ждём следующий.

[кому][от кого][длина оставшегося пакета]<блок данных>[контрольная сумма]

длина оставшегося пакета - это блок данных и контрольной суммы

Такое число удобно для простых и медленных процов.

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

Извините за вклин.

Считаю, что конт. сумма - обязательна. И еще не помешает ответ слейва мастеру об успешном принятии/выполнении команды (если комманда адресована одному).

Да все нормально, тем более по делу.

Без контрольной суммы я и сам не привык работать.

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

Но обратная квитанция не всегда обязательна, и обговариваться наверно будет для каждого устройства отдельно.

Edited by Migray

Share this post


Link to post
Share on other sites

А зачем вообще считать прерывания, если блок чужой? Просто выходим из обработчика и ждем начало нового пакета. Ведь начало по-любому надо как-то вылавливать. ...кстати тоже вопрос!

Share this post


Link to post
Share on other sites
Я на пике слелаю исполняющее устройсто, управление освещением на 3 "зоны". Управление люстрой )). Адрес 0x00h, опрос-0x00h или задача 0x01h, номера зон:1-ая зона 0x00h, 2-0x01h и третья 0x02h. команды: 0x00h - тушим, 0x01h - включаем. Вот синтаксис запрос [адрес][опрос][зона], ждем ответа [адрес][зона][состояние]. Вот синтаксис камнда [адрес][зона][состояние], ждем ответа [адрес][зона][состояние]. У меня будет 2 реле 1 кнопка. Хост должен опрашивать постоянно все адреса, особенно всякие датчики и кнопки, т.е. элементы управления. По их изменеию давать команду на реле включить или выключить - это в моём случае. Как понимаете все наращиваеться по адресам. Только придумывай как и что это дело описать. Какое правило общения будет в сети (по 220, по 380, по 10кВ шутка). Суть в том что сдесь не важно как подавать сигнал, а важно то, что в нем идет.

Я чтотоне въехал, если свет будет включать/выключать хост то есть главный то зачем тогда твоё устр-во ? ИМХО надо вот так:

Твоя схемка контролирует кол-во людей в комнате. если в комнате 1 чел то в зависимости от освещённости оно должно включить свет. Если изначально в комнате было более-менее светло, то свет должен включитьса на 50%. так же надо контролировать время. Если это ночь то свет должен включитьса на процентов 10, напрмер чел в сортир пошол... Надо решить проблему со спальной, и сделать несколько режимов работы. например если эта зоня яв-ся спальной, то позже 12 часов свет должен выключитьса. Потомучто в спальне по любому будет один или более человек... Так же былобы неплохо предусмотреть ручное вкл\выкл света, например одиночным\двойным хлопком в ладоши.

Задачи хоста:

Отображать на сколько проыентов включён свет. передавать уст-ву режим его работы (спальная, лоджия, кухня...) Ну и ещё можно чёнить потом добавить... Главное то что он НЕ должен вмешиватьса в работу слэйв устр-ва, он должен только задавать параметры, ну и отображать даные.

PS чтобы тут не мусолить эту тему, я тебе в асю напишу, обсудим, а потом выложим сдесь, то до чего мы дошли, для критики, и только потом начнём собирать...

Share this post


Link to post
Share on other sites

Не то! Не то вы делаете!!! Вся прелесть хоста в том, что можно легко и быстро реализовать и перестроить любую логику работы. Причем можно делать зависимость от сколько угодно параметров, будь то сигнал с датчика (со многих датчиков!!), время суток, время года, настроение и воля божья...

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Similar Content

    • By кип-сервис
      Продам новые комплектующие пневматического оборудования для систем автоматизации. Недорого. Цены по запросу.












    • By кип-сервис
      В связи с закрытием склада, распродаю новые комплектующие для автоматизации: пневматика, реле, датчики, контроллеры и другое (Danfoss, Omron, Ifm, Esbe, Festo, SMC, Camozzi и др.)  Недорого! Подробности в ЛС. Цены по запросу.








    • Guest persej
      By Guest persej
      Нужна электрическая схема  платы управления CONTROL BOARD ZBK. именно электрическая принципиальная, а не  куда какие провода подсоединять как нарисовано в инструкции по монтажу.
      Плата не работает, а как её ремонтировать не зная электрической схемы?

    • By mazzi
      Друзья, я выложил в своём блоге конструкцию симисторного регулятора мощности с микроконтроллерным управлением. Интересно услышать ваше мнение по этому поводу.
      http://forum.cxem.net/index.php?/blogs/entry/547-регулятор-мощности-для-тёплого-пола-или-тэна/
       
    • By serg-foxic
      Линия разлива жидкости. Имеется два шаговых двигателя, один драйвер управления ШД, (второй вышел из строя) и контроллер Siemens, дающий задание на драйвер. Озадачился вопросом: можно ли одним драйвером управлять двумя ШД по отдельности? Идея такая: с помощью простенького программируемого реле отключаем питание с драйвера (на 10 сек), по прошествии 7 сек производим переключение управляющих сигналов от контроллера к драйверу и от драйвера к ШД, еще через 3 сек включаем питание драйвера. Для этого ставится контактор на питание драйвера и пара релюшек на выходе из драйвера к ШД.
      Ничего сложного, программку состряпал, но есть сомнения следующего плана. Никто не ставит "сухие контакты" в цепи силового управления двигателями, потому как эти контакты имеют свойство "микронеконтачить", в результате чего при подаче напряжения и начальном протекании тока может образовываться избыточное напряжение на обмотках ШД. С последующим выходом из строя либо драйвера, либо ШД.
      Кто-нибудь что-нибудь знает по этой теме из практики?
      Тему ремонта первого драйвера  или его приобретения пока не затрагиваю.
×
×
  • Create New...