Проект контроллера монтировки RUMOUNT

[Aslamov Ilya]

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

Это понятно, вот только какое отношение это имеет к текущей разработке? 

[Rusik]

я практикую выездную сьемку и наблюдения (другой возможности пока нет), поэтому проект больше нацеливаю на мобильность. Можно иметь несколько труб со своим базовым контролером подключил и вперед.
+ Есть задумка насчет автономного гида в общей шине, комп будет нужен только для предвварительной настроки а дальше его можно выключить.

Для стационара наверно соглашусь на один блок.

Это понятно, вот только какое отношение это имеет к текущей разработке? 

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

[andreichk]

Если здесь вы все определили с концепцией, то удачи!

вы , часом , не обидились?

[Rusik]

вы , часом , не обидились?

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

[andreichk]

мы тут все практиканты, но конечную концепцию определять будет топикстартер

[Денис Никитин]

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

И в настоящее время мы имеем две конкурирующие архитектуры:

1)Единый контроллер к которому подключены датчики и исполнительные устройства.

2)Несколько законченных устройств (мозг, датчики, контроллеры двигателей) объединенных в сеть шиной CAN.

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


Несколько слов о достоинствах и недостатках второй архитектуры.

Достоинства:
1. Мало проводов.
2. Относительно скоростная помехоустойчивая шина CAN - до 1 Мбит/сек.
3. Возможность использовать в качестве протокола промышленный стандарт - CANOpen.
4. Широкие возможности для расширения. Имея на руках базовый стандартный протокол любой желающий сможет разработать датчик (термометр, GPS и т.д.) или контроллер (шаговый двигатель, серво двигатель, пульт управления и т.д.) для данной архитектуры.

Недостатки:
1. Много контроллеров. Каждое устройство = микроконтроллер + CAN физика. (На самом деле не считаю это недостатком, микросхемы нынче очень дешевы!!)

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






 



 

[andreichk]

второй вариант будет однозначно дороже первого,причём существенно, а не на пару-тройку рублей.

[Денис Никитин]

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

[Максим M]

Не понимаю почему все всегда хотя спорить. Давайте делать одновременно оба варианта. Поясню:
мозг (он же главный контроллер). Хотите вешайте микрухи на него. Хотите вешайте все микрухи на ЕГО шину CAN. Принципиальной разницы 0.0%. Только в конфигурации будете указывать адреса ваших устройств на этой шине.

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

[Максим M]

Этим самым мы удовлетворим как претензии к дешевизне. Так и претензии к промышленности.

Как угодно, так и конфигури, ограничивать творчество нехорошо.

[andreichk]

Не понимаю почему все всегда хотя спорить.

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

[Максим M]

Пульты будут! еще как. И ТФТ уже ждет своего часа.

Да! Пульты... это тоже железо

[Aslamov Ilya]

2)Несколько законченных устройств (мозг, датчики, контроллеры двигателей) объединенных в сеть шиной CAN.

А я полностью согласен с Максимом. Разрабатывая контроллер "почти все в одном" никак не отрицается возможность подключения дополнительных устройств.
Со своей стороны еще добавлю, что всетаки абсолютно нецелесообразно использовать CAN шину для коммутаци я с доп. блоками. Во первых, хоть физика и дешевая, но всетаки она стоит каких-то денег,  во вторых, шина CAN - довольно редко включена в перефирию контроллеров,  она идет в составе уже как правило дорогих мощных контроллеро которые далеко не всегда являются необходимыми. Есть конечно ковертеры, например SPI-CAN но они также стоят денег. Поэтому если и использовать внешнюю шину - то помоему наиболее целесообразно RS485. Физика - вообще копейки. А мегабит на таких расстояниях - элементарно она потянет. Хотя зачем вам мегабит? мне не понятно.

[andreichk]

Хотя зачем вам мегабит? мне не понятно.

а это непобедимое стремление к максимализму во всём.....

[Максим M]

  щастья. всем (с) Стругацкие.

CAN есть не везде. Только в немладших моделях. В обычных моделях упор на UART SPI I2C.
Для затравки предложу вот что:

1) Контроллеры вывода WH1602, WH0802 и совместимые.

2) Контроллер привода ULN2803 и его аналоги. А на деле - 4 битная шина для вывода в шаговик. С датчиком и без положения. Микрошаговые микуршки мне придут во вторник. ТОгда и скажу.

3) термодатичики целая эпопея. у меня есть TMP102 (шина I2C)

Это то что я смогу легко отработать и попробовать.
Высказывайтесь.

[Rusik]

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

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

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

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

Второй вариант я уже начал потихоньку реализовывать, как Максим первый

[Максим M]

А вот оно как. Тогда буду рад если мой протокол Вам поможет. Хотя я даже не предполагал что Вы ТАК его будете использовать.

[Rusik]

я еще глубоко в него не вникся, сказал что два проекта(две реализации) моглибы пересечся и первое что это протокол, который бы устроил ВСЕХ

[Максим M]

Не бывать двум Китаям. Либо я Вас съем либо одно из двух. Впрочем я шучу.

А действительно, что должно быть такого в протоколе, чтобы его понимали несколько устройств одновременно?

[Максим M]

Я только ЗА такой. Ведь это .. то самое щастье. Протокол который не требует документации по его пониманию.
Человечный, простой, повторимый.