Модульная Система Управления

[Lexi]

Или думаешь это все бесплатно?

Ну дисно для меня это бесплатно поскольку я сам пишу софт, а для других конечно придется паскашелиться.

Для вашей информации - розетка с встроеным трансформатором и конденсаторами и как бонус двумя светодиодами стоит чуть больше долара....

К сожелению у нас тут другие цены , не наравиться едте в Москву сами... Вот и приходиться покупать, что поделаешь.

Блок схему самого ПО трудно составить, поскольку уж очень много различных факторов имет место. Коченчо ночно набрасать структуру подключений. К примеру, в своей системе делали хост на контроллере и конечноже ряд переферии. К переферии относяться датчики различного типа, исполниели и прочее. при разработке чегото нового, мы вставляли модуль в ПО хоста, и особенности работы того или иного оборудования. Но система получается адресной. Вот к примеру сча вводим радиотрансиверы чипкона. Соотв делаем для него слот (т.е. чипкон как модуль расширения). А базовый интерфейс RS-485. Т.к. некоторые модули отвечающие под охрану я не хочу использовать радио, мало ли.

Что касается струтуры приведееной тут. Обзовите все, ничего не ясно что это...

[Реклама]

Реклама: ООО ТД Промэлектроника, ИНН: 6659197470, Тел: 8 (800) 1000-321

[Alexeyslav]

Да, у вас там все практически нахаляву поскольку конкуренция ... недавно хотел сделать пультик на 433Мгц, поинтересовался сколько модули стоят RX5000 - 20$ не меньше ... меня не устраивает ДУ который я соберу не меньше чем за 40$ ... есть конечно трансиверы за меньшую цену, однако ... для них нужен обвес и плата специального образца которую изготовить в домашних условиях трудновато. И еще ко всему нужно писать программу которая бы программировала эти трансиверы на нужную частоту и нужный режим - а это уже ненужные сложности в случае простого пульта.

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

Изменено 17 января, 2009 пользователем Alexeyslav

[Реклама]

20% скидка на весь каталог электронных компонентов в ТМ Электроникс!

Акция "Лето ближе - цены ниже", успей сделать выгодные покупки!

Плюс весь апрель действует скидка 10% по промокоду APREL24 + 15% кэшбэк и бесплатная доставка!

Перейти на страницу акции

Реклама: ООО ТМ ЭЛЕКТРОНИКС, ИНН: 7806548420, info@tmelectronics.ru, +7(812)4094849

[BIBOSS]

Вот чуть детализировал схему.

Суть такова: пакет данных приходит на мастер устройство где он по идентификатору типа данных или адресу выводится на один из 3 портов ввода/вывода (на счет количества портов не уверен может еще какой то тип модулей будет) дальше первый модуль проверяет по адресу ему предназначается пакет или нет. Если нет то передает по шине на другой модуль за ним где выполняется аналогичная обработка, если пакет для него то принимает его для обработки, где уже в зависимости от модуля выполняет те или иные действия.

Вроде все если что то не логично или не правильно, а может можно рационализировать укажите.

[Реклама]

Выбираем схему BMS для заряда литий-железофосфатных (LiFePO4) аккумуляторов

Обязательным условием долгой и стабильной работы Li-FePO4-аккумуляторов, в том числе и производства EVE Energy, является применение специализированных BMS-микросхем. Литий-железофосфатные АКБ отличаются такими характеристиками, как высокая многократность циклов заряда-разряда, безопасность, возможность быстрой зарядки, устойчивость к буферному режиму работы и приемлемая стоимость. Но для этих АКБ очень важен контроль процесса заряда и разряда для избегания воздействия внешнего зарядного напряжения после достижения 100% заряда. Инженеры КОМПЭЛ подготовили список таких решений от разных производителей. Подробнее>>

Реклама: АО КОМПЭЛ, ИНН: 7713005406, ОГРН: 1027700032161

[Alexeyslav]

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

Видео подсистему я бы вывел паралельной веткой, или это подразумевает сигналы управления камерами?

Изменено 17 января, 2009 пользователем Alexeyslav

[BIBOSS]

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

[Alexeyslav]

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

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

[ss85]

...

Так лучше уж ПК опрашивает все устройства

...

Мне так не кажется, от мастер-устройства отказываться нельзя... Лучше чтоб мастер устройство записывало все события в свой локальный журнал и при запросе ПК, просто передавали ему всё скопившееся и очищало журнал. Журнал лучше всего делать на ферромагнитных NV RAM например FM31256 или FM32256. Обмен данными происходит по I2C и есть встроенный RTC.

Если под "видое" подразумевается просмотр изображения с камеры, то вот статейка, на тему преобразования видео сигнала на PIC контроллере(Текст на английском).

[Alexeyslav]

Хахах... преобразование видеосигнала ... ну насмешил ... PIC для этого подходят мало, а статейка эта относится не к преобразованию а к наложению так называемых OSD на видеоизображение, например часы в уголке чтобы светились и подобное. А видео, даже АРМ-ы и то еле еле осиливают в цифровом виде. Да что там говорить, для того чтобы даже ввести Аналоговый сигнал в контроллер нужен высокоскоростной АЦП не менее 5млн выборок/сек. а это само по себе дорогое удовольствие .

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

Но можно пойти с другой стороны, съекономив себе кучу времени и нервов - передавая видеосигнал по кабелям в аналоговом режиме (в теории с этим даже справится витая пара, ту что используют для прокладки сети - 4 канала в одном проводе) и используя мультиплексор подавать сигнал на вход платы видеозахвата. Поскольку софт для нее уже написан и идет в комплекте - проблем с выводом не будет, надо лишь научить программу запускать этот софт в нужное время. При необходимости вывода 4 изображений на одном экране - использовать аппаратный квадратор ...

Это, поверь, съекономит тебе средств на разработку всей системы и в особенности - драгоценное время и нервы.

[ss85]

Хахах... преобразование видеосигнала ... ну насмешил ... PIC для этого подходят мало

Ну во-первых, вы как всегда, сделав поверхностный осмотр сделали окончательный вывод. В том примере, много важного, например: анализ аналогового видео потока на одной микросхеме.

Не подходит PIC можно попробовать AVR! Вот пример. Этот пример мне понравился больше, так как там еще и JPEG. Вообще, там есть что почитать.

...

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

...

А ну перевидите мне это: This closed-caption decoder does NOT overlay captions on video (OSD, on-screen display). Языки нужно учить! Или дочитывать до конца

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

Вот есть пример(На немецком правда, но там как по мне всё просто). Тут взята типовая камера-приставка к телефону и подключили к AVR, который в свою очередь подключен в сеть. Всё передается по сети и даже мега прога написана на Perl:)

Но можно пойти с другой стороны, съекономив себе кучу времени и нервов - передавая видеосигнал по кабелям в аналоговом режиме (в теории с этим даже справится витая пара, ту что используют для прокладки сети - 4 канала в одном проводе) и используя мультиплексор подавать сигнал на вход платы видеозахвата. Поскольку софт для нее уже написан и идет в комплекте - проблем с выводом не будет, надо лишь научить программу запускать этот софт в нужное время. При необходимости вывода 4 изображений на одном экране - использовать аппаратный квадратор ...

Это, поверь, съекономит тебе средств на разработку всей системы и в особенности - драгоценное время и нервы.

Мне кажется или Вы ищите повод не делать этот проект? Вас ни кто не заставляет принимать в нем активное участие.

На счет софта и квадраторов. Это вы конечно круто придумали! Но если пересчитать это всё на реальные деньги, как вы это любите. То стоить это будет прилично. Даже по самым скромным оценка квадратор+виодезахват+софт=$250-$350. Это по старым ценам. Если уж делать передачу видео аналоговыми путями, то тогда управлять каналами можно средствами удаленных модулей, например релюшками! И видео передавать на вход TV тюнера. А программно разделить моменты переключения не сложно, даже если ты не владеешь ни чем кроме VB.

[Alexeyslav]

Даже по самым скромным оценка квадратор+виодезахват+софт=$250-$350

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

управлять каналами можно средствами удаленных модулей, например релюшками!

Именно это я и имел в виду, мультиплексор из релюшек.

Мне кажется или Вы ищите повод не делать этот проект?

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

NOT overlay captions on video

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

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

Что-то вроде телетекста, но точно не телетекст!

[ss85]

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

Можете даже не сомневаться! Стоимость производства с деталями 50$. Недавно пришли платы А софт писать там простой, ну если вы конечно хотите писать простой софт. Если вам нужно кросс платформенное или оч. красивое, тогда сложнее.

UPD:

Стоитмость квадратора не учтена.... так как он не нужен.

Изменено 19 января, 2009 пользователем ss85

[BIBOSS]

Мне кажется на данном этапе не рационально обсуждать передачу и прием аудио/видео сигналов. Кто то предлагал составить структурную схему для начала, а дальше помочь выбрать протокол - по моему правильный путь. Но пока мы не куда не продвинулись ни с схемой ни с протоколом (лично мне симпатизирует ТСР/ІР, и скорость приличная и тип данных передать возможно любой, но я могу заблуждаться). Помогите хоть кто нибудь, я в разработке устройств данного типа не силен поэтому и обратился сюда за помощью.

[Alexeyslav]

Структурная схема уже есть. А протокол выбирать в отрыве от линий связи не получится. Прежде всего, нужно определится с пропускной способностью канала, потом выбирать подходящие протоколы/скорости ведь не секрет что есть специализированные протоколы вроде I2C по которым передавать видео чересчур накладно(если повысить частоту). Во вторых, существуют типовые решения, от которых и надо опираться.

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

Рассматривать всегда стоит несколько вариантов, никогда не знаешь что окажется сделать проще или дешевле.

Если за основу брать стандартную распространенную TCP/IP сеть - тогда прийдется конечные устройства делать совместимыми считать стоимость разработки каждого конечного устройства и т.п. а потом сравнить несколько проектов по стоимости и сложности работ и выбрать естественно наилучший.

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

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

[ss85]

Поправочка. TCP/IP не подходит, для передачи звука и видео используется UDP. Рекомендую, прочесть доку.

[wowa]

UDP - это самый простой тип пакета... Так что он подходит для передачи потоков.. TCP/IP - хорош своей охраной данных ну и стандартной поддержкой бровзеров... Я вот читаю тему и смеюсь Ничего у вас таким темпом не получится... То что вы составили - это не схема - это ваша начальная идея.. До схемы вам ещё далеко.. И подкину вам ещё одну мою идею - я её уже давно использую в железе - у меня всё сделано на TP кабеле и через стандартные маршрутизаторы... Но провода ведут в шкаф и перед маршрутизатором стоит ещё MATRIX переключатель... Он умеет просто через реле подключить любой вход из 64 на любой выход из 32... И следит чтобы небыло конфликтов.. Таким образом у меня подключен МП3 проигрыватель и колонки у меня в каждой комнате просто через MATRIX подключены к усилителю через TP кабель... Так же можно подключить и видео да и вообще что угодно.. Всё это можно передать через TP.... Правда у аудио при не большой длине не надо с звуком ничего делать а вот в видео надо будет сделать усилитель дла посылки через TP кабель...

[BIBOSS]

Alexeyslav мне понравилась ваша схема, на мой взгляд то что нужно в данной ситуации. По поводу физического уровня передачи данных думаю очень замарачиваться не станем и используем проводное соединение. На счет пропускной способности думаю реализовать по максиму реально доступную, для стабильной роботы системы. А вот с протоколом даж и не знаю UDP, ModBus, I2C, TCP/IP прямь теряюсь но склоняюсь больше к UDP и ModBus.

[Alexeyslav]

С протоколом можно не заморачиваться - вплоть до того что придумать свой.

UDP - это протокол хоть и более низкого уровня, все же довольно сложен чтобы использовать его в небольших контролерах с памятью не больше 128 а то и 32-х байт. Именно такие и нужно использовать для ввода/вывода простых логических сигналов. Самый лучший для этого протокол - RS232 но и он требует от контроллера конкретной скорости реакции. Например, я как-то реализовывал RS232 протокол для использования в системе с Z80 процессором... при частоте в 4Мгц удалось надежно реализовать лишь скорость 4800 бит/с. Конечно, сейчас есть контроллеры со встроенным RS232 модулем.

[ss85]

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

Вообще-то сейчас контроллеры с 32-128 байт ОЗУ стоят дороже, чем аналогичные, но с большим объемом Это вызвано тем,что первые закуплены по старым ценам, того времени, а новые по более дешевым.

Например, я как-то реализовывал RS232 протокол для использования в системе с Z80 процессором... при частоте в 4Мгц удалось надежно реализовать лишь скорость 4800 бит/с. Конечно, сейчас есть контроллеры со встроенным RS232 модулем.

Z80, это конечно хороший процессор, но для своего времени.

[Alexeyslav]

Увы, из тех что есть например PIC10F202 - самый простой и соответственно самый дешевый контроллер.

при частоте в 4Мгц удалось надежно реализовать лишь скорость 4800 бит/с.

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

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

[BIBOSS]

Что то мне RS232 не нравится, может лучше другой какой то альтернативный использовать. К примеру Ethernet или USB на худой конец.

[Alexeyslav]

И чем же он не нравится? с эзернетом и USB будет гораздо больше проблем при написании программ. Производители и те не с первого разу пишут нормальные драйвера, а вы собираетесь в одиночку написать лучше чем сейчас есть ) не смешно даже... И отлаживать его будет очень просто, и писать программы гораздо проще - а это залог нормальной работы. Тем более что скорость передачи даже в стандартном варианте скорей всего позволит уже нормально работать.

Например, скорость на линии 115кбит/с если принять размер передаваемого пакета около 16 байт, и количество устройств - 128 мы сможем их опрашивать примерно 5 раз/сек. А если принять алгоритм работы - опрос по запросу или событию, то время реакции можно сократить.

[BIBOSS]

Вообще то я не категорично против, пускай будет RS232, но у него пропускная способность маловата, хотя в некоторых решениях встречается около 500кбит/с, а нам то поменьше надо, хотя такая была бы круто . Но ближе к делу, а то болтовня уже поднадоела, что мы имеем? Практически ничего, но все же:

1.интерфейс связи с ПК RS232;

2.скорость передачи данных около 150 кбит/с (при возможности больше не помешает);

3.протокол наверное прийдется разработать свой;

4.частота передачи данных - пока под вопросом

Так что упустили?

[BIBOSS]

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

[wowa]

Именно эту схемку я и брал за основу моей.. У меня с неё осталась схема.. Програма целиком переписана... Очень легко переписывалась и не надо слушать Alexeyslav'a о сложности.. Я тут пытался писать - но меня не слушают..

Как же нет - ТУТ ВОТ ЛЕЖИТ ВСЁ ЧТО НАДО

[ss85]

Может сделать так?

Server - это какой-то ПК, выполняющий роль DHCP, опрашивает Main Controller`ы записывает что-то в базу данных, если это конечно нужно, так же он может принимать изображения с камер и писать их файлы.... Вообщем напихать задач можно немеряно.

Main Controller - устройство управляющее датчиками по всем требуемым/возможным интерфейсам. При необходимости ведёт обмен данными с сервером. Если использовать более производительный процессор, то можно возложить задачу конвертации видео и передачу по сети.

Sensor #1 - это удаленный датчик с интерфейсом RS485, самый дешевый вариант подключения;

Sensor #2 - это удаленный датчик с интерфейсом ZigBee, дорогой вариант подключения, но имеет преимущество, не привязан проводами, по крайней мере интерфейсом;