Сомнения: доверять или не доверять AVR управление H-bridge, Без внешней аппаратной защиты на логике или на спец. микросхеме Опции

[haker_fox]

Здравствуйте!
Основная тема здесь. Там шло обсуждение простого H-bridge. Упор с моей стороны делался на то, чтобы не ставить внешнюю защиту в виде логики или той же IR2104, а поручить все управление (dead-time, реверс, шим, защиту от КЗ моста одновременным включением пары транзисторов по одну сторону моста) МК. Был выбран ATmega168. В общем начиная с 20 поста вопрос о конструктиве моста более менее решился, и мы пришли к выводу, что такая идея вполне жизнеспособна. Конечно нужно предпринять ряд защит - аппаратных защит, но не очень дорогих и которые сработают наверняка, причем выполнят только функцию защиты в экстренном случае - КЗ.
В общем на данный момент я хочу реализовать управление всеми 4 транзисторами моста - напрямую. Требования не высокие: ШИМ 900 - 4000 Гц, движок будет плавно разгоняться (всегда) -> пускового тока большого не будет, номинальный ток макс. 600 ма.
Чтобы повысить надежность устройства и свести к минимуму возможные сбои МК, хочу выполнить следующее:
1. По питанию всего моста поставить электролит 100 или 3000 мкф + керам. 0.1 мк + керам. 100н.
2. Обязательно включить BOD на 4.5 В.
3. Всю раздачу питания на МК, на мост и тд выполнять звездой. Т.е. из одной общ. точки. Цепи кварца и сброса выполнить согласно правилам из известной статьи на сахаре.
4. Корп. кварца заземлить. Не уверен, надо ли?
5. Установить бит CKOPT.
6. К схеме будут подключены датчики (оптические концевики и энкодеры) прводом длиной не более 5 м. Их хочу подключить через витую пару. На плате сигнальные провода будут заводиться через RC фильтр + возможно феррит. колечки.
7. Питание на схему будет подаваться через плавкий предохранитель. Пока не знаю, какой номинал выбрать.

Все эти требования были получены после изучения статьи на сахаре + изучение веток в этом форуме о сбоях, помехоустойчивости МК.

Вся схема: силовая и цифровая будут гальванически связаны. Силовая будет питаться от этого БП (S-320-27: 27В, 11А), а цифровая - от обычного компьютерного AT. Всего таких схемы управления двигателями нужно 3 + главный МК, который будет управлять этими движками и другими исполнительными механизмами. Но все это продолжение этой темы.
Собственно говоря хочу здесь спросить, т.к. это уже не касается напрямую электропривода, можно ли при таком подходе надеяться на устойчивую работу приводов?
У меня есть сомнения по поводу разделения МК и силовых ключей оптопарами: надо ли? + может быть нужно оставить защиту на буферах 74hc02 (схема в топике по первой ссылке) от КЗ моста?
По поводу dead-time я не беспокоюсь: реверс двигателя или его экстренное торможению буду делать только при выключенном ШИМе.
Прошу прощения, если выразил несколько сумбурно свои мысли.
Также надеюсь, что модераторы не сочтут это за кросспостинг: дело в том, что темы хоть и три по разным веткам и они решают один вопрос, но они все таки разные.
Всем заранее большое спасибо за ответы и хорошую критику!
P.S. все несколько омрачняет то, что печатки не будет, весь монтаж на макетке проводом МГТФ(

[slog]

Использовать мега168 в мостовом инверторе не совсем правильно. Этот вариант конечно может существовать, и по нему многие уже ходили, и я в том числе. Но вобще-то это не правильный путь. Не создавайте себе проблем на ровном месте, для этого надо использовать специально заточенный проц. Если уж совсем нет сил изучить что-то кроме AVR можно пользоваться AT90PWM3. При правильной разводке с внешним кварцем проблем не должно быть. А вот правильная разводка моста, да еще без опторазвязки как тут предлагалось - это не очень простая задача, даже без печатной платы.
И еще я так понял планируется программно обрабатывать сигналы с оптических энкодеров? Если энкодеры используются в братной связи по положению и если хотите приключений - то флаг вам в руки.
Вообще-то тема управления двигателями достаточно консервативна. В ней есть стандартные решения на все случаи жизни. И изобретение своих велосипедов это в будущем просто бег по заранее разложенным самим собой граблям.
Удачи

[SasaVitebsk]

Использовать мега168 в мостовом инверторе не совсем правильно. Этот вариант конечно может существовать, и по нему многие уже ходили, и я в том числе. Но вобще-то это не правильный путь. Не создавайте себе проблем на ровном месте, для этого надо использовать специально заточенный проц. Если уж совсем нет сил изучить что-то кроме AVR можно пользоваться AT90PWM3.

Двигателями управляли во все времена. Даже когда проц 8080 с его 0.5 мипса был высочайшим достижением. А ШИМ формировался на операционниках. Применение данного МК, я, к примеру, считаю оправданным. В том числе и с точки зрения надёжности. А также по причине удобной его разводки. Успешно применяю данные МК в качестве "интелектуальной переферии". Очень мне нравится.

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

Опять таки непонятно. Для решения данной задачи потребуются единицы процента от вычислительной мощности данного МК. Можно нагородить всё мыслимое и обработать все исключительные. Всё будет зависеть только от программиста.

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

Все решения когда-то были стандартными. Я бы привёл вам вариант стандартной схемы года так 1990. Работала как часы. Все заимствовали и никто не решался менять. Ну ерунда, что там было десятка три корпусов. Одно моё изделие начиналось с 8951 и 30 корпусов, потом 1200+4414 и 11 корпусов, потом 8515 и 2 корпуса, а сейчас atmega8+2 корпуса и не единой настройки. Весь аналог в цифре. Надёжность увеличилась в разы. Размер уменьшился раза в 4-5. Если быстродействие проца поднять ещё в 2-4 раза, а также 13-14 разрядов ADC был бы, то можно было бы полностью впихнуть в проц. А вы говорите "стандартные решения".

Стандартным, на мой взгляд, в ближайшее время будет следующее:
Изделие будет состоять, как из кирпичиков, из нескольких МК каждый из которых будет выполнять законченную часть работы. Соединены будут м/у собой последовательным, высокоскоростным, защищённым интерфейсом.

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

1) Проц очень дешёвый.
2) Малые размеры и хорошая разводка обеспечат надёжную работу.
3) Однотипная несложная задача обеспечит быстрое написание, хорошую отлаживаемость
независимость от проги управляющей программы, возможность заимствования и развития.
4) наличие интерфейса обеспечит связь При грамотном написании, обеспечит дополнительную надёжность, а также удалённость от основного контроллера и, возможную оптическую развязку.

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

Кстати привода ведущих производителей, при их стоимости сотни евро, и "суперстандартности решений" тоже регулярно выходят из строя. Нет 100% защиты.

[_Pasha]

+1 Под каждым предложением.
Вопрос: на каком же последовательном интерфейсе лучше остановиться сейчас? Пока что, с учетом необходимой гальваноразвязки, катит UART

[haker_fox]

To SasaVitebsk

+1 Под каждым предложением.
Вопрос: на каком же последовательном интерфейсе лучше остановиться сейчас? Пока что, с учетом необходимой гальваноразвязки, катит UART

Хм. Здесь мне следует чуть чуть пояснить. Каждый привод хочу обеспечить двумя последовательными шинами: I2C и UART. I2C будет предназначен для соединений внутри работающей системы. Т.е. по этому интерфейсу привода будут договариваться и принимать команды от главного (управляющего) МК. Интерфейс UART будет предназначен для подключения к компу с целью что-то настроить, отладить, проверить. Короче говоря будет выступать в роли своеобразного технологического канала для сервисного обслуживания.
По крайней мере, такая реализация была задумана давно и существует до настоящего времени. Но пост уважаемого Павла (_Pasha) натолкнул меня на мысль: а может быть оставить только один UART? А уже программное обеспечение привода будет определять к чему он подключен и, в зависимости от этого, общение будет удобным для человека (вывод текстовых сообщений, командная строка и тп) или - удобным для другого МК (какой-либо протокол).
На счет развязки: если МК привода развязать с силовыми ключами оптронами, то это даст:
1. Дополнительную защиту МК от сбоев.
2. Защиту от пробоя портов МК при выходе из строя силовой части.
3. Интерфейс можно будет использовать любой, т.к. на нем не при каких условиях не появится высокое напряжение, которое повредит комп или плату управляющего МК.

Также следует сказать, что вся система управления, в которой будет находится три контроллера привода (который мы сейчас обсуждаем), плата главного МК, БП будет помещаться в одном корпусе от старого компа. корпус типа "пицца" (лежачий).

[SasaVitebsk]

To SasaVitebsk
Хм. Здесь мне следует чуть чуть пояснить. Каждый привод хочу обеспечить двумя последовательными шинами: I2C и UART. I2C будет предназначен для соединений внутри работающей системы. Т.е. по этому интерфейсу привода будут договариваться и принимать команды от главного (управляющего) МК. Интерфейс UART будет предназначен для подключения к компу с целью что-то настроить, отладить, проверить. Короче говоря будет выступать в роли своеобразного технологического канала для сервисного обслуживания.

Имеет право на жизнь. Реализация на RS485 мультимастера достаточно сложно, хотя и возможно.
Я бы предпочёл одну шину с несколькими группами команд. А технологические комманды транслировал бы ч/з главный контроллер.

По крайней мере, такая реализация была задумана давно и существует до настоящего времени. Но пост уважаемого Павла (_Pasha) натолкнул меня на мысль: а может быть оставить только один UART? А уже программное обеспечение привода будет определять к чему он подключен и, в зависимости от этого, общение будет удобным для человека (вывод текстовых сообщений, командная строка и тп) или - удобным для другого МК (какой-либо протокол).

Есть и другой способ. Очень интересный. У сименса подсмотрел.

На счет развязки: если МК привода развязать с силовыми ключами оптронами, то это даст:
1. Дополнительную защиту МК от сбоев.
2. Защиту от пробоя портов МК при выходе из строя силовой части.
3. Интерфейс можно будет использовать любой, т.к. на нем не при каких условиях не появится высокое напряжение, которое повредит комп или плату управляющего МК.

Также следует сказать, что вся система управления, в которой будет находится три контроллера привода (который мы сейчас обсуждаем), плата главного МК, БП будет помещаться в одном корпусе от старого компа. корпус типа "пицца" (лежачий).

Я бы не стал МК от ключей развязывать (чисто мой взгляд). Какая защита портов. Что там защищать? Разводку грамотную, питание развязанное. Максимально близко всё на одной плате. Максимально внимания уделил самой схеме приводов и разводке платы и конструкции. Там всё очень важно. А развязку бы сделал на интерфейс. Получился бы законченный блок управления двигуном с опторазвязанным интерфейсом. А может действительно развязать и просто RS485. При верном подходе и так и так работать будет устойчиво.