Сомнения: доверять или не доверять 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. При верном подходе и так и так работать будет устойчиво.

[haker_fox]

Имеет право на жизнь. Реализация на RS485 мультимастера достаточно сложно, хотя и возможно.

Хорошо. Здесь наши мысли почти сходятся.

Я бы не стал МК от ключей развязывать (чисто мой взгляд). Какая защита портов. Что там защищать?

Был на моей памяти случай, когда были пробиты ключи на базе ULN2803, которыми МК управлял. Так вот почти весь порт был угроблен. Я просто боюсь повторения подобной ситуации в моем случае.

Получился бы законченный блок управления двигуном с опторазвязанным интерфейсом.

Звучит заманичиво, но пока терзают сомнения, написанные в предыдущей цитате.

По поводу кварцев. Ребята из Spectrum Digital и Luminary Micro не обламываются и ставят в своих китах на процы кварцы. Все вроде у них работает.

Тут как раз подобная ситуация.

Снимать ток с помощью шунта ИМХО заиметь большой гемор с разводкой аналоговой части платы. На макетке снять сигнал с шунта, усилить его, пустить на АЦП и получить нормальные значения почти нереально.

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

Тем более вы сначала купите этот шунт.

Я почему-то подумал, что возьму кусох нихрома...

Проще всего использовать датчики тока(на эффекте Холла) от Allegro или магниторезистивные от Bell. Заодно и развязку получите, т.к измерение тока "бесконтактное".

Скорее всего это задел на будущее. Бюджет текущей разработки очень сильно ограничен.

Вот эта штука крутит киловаттный движок (типа стенда). Однотактнник с обратным диодом, правда. Работает на индуктивность двигателя. Частота аппаратного ШИМ - 1,22кГц. Звон от движка - ещё тот. Нижняя плата - ШИМ+АЦП (те, что в нижнем правом углу) для датчиков тока и напряжения. Верхняя - логика управления. Между платами развязка на 6N137 (шина SPI). "Верхний ключ" - IRGPC50KD2 + IR4426 с развязкой на 6N137. Аппартной защиты нет. Контроллер ШИМ, правда, вырубается при потере связи с контроллером управления. БП вырабатывает +12В, -12В для ОУ +20В для драйвера ключа, два по 10В для контроллеров, и +13В для RS232-преобразователя уровней (тоже развязан на 6N137). Контроллеры работают от кварцев. "Аппарат" вёл себя стабильно, при работающем рядом частотнике без фильтров и токе через двигатель - 6А.

Впечатляет!!!
Это вселяет в меня надежду и еще раз доказывает, что при аккуратном подходе почти все возможно!

[Dars]

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

Ну если вам нужен Faul detection то именно так и делают. На спец процах(напр tms320) есть даже специальная ножка FAULT, к которой подключаете выход компаратора. В моей задаче мне нужно управление по току и задачу отключения двигателя в случае перегрузки по току, напряжению и т.д и я делаю программно.

Скорее всего это задел на будущее. Бюджет текущей разработки очень сильно ограничен.

Ну на будущее, предлагаю посмотреть на мое решение для управления бесколлекторым(можно и коллекторным) двигателем.Есть возможность крутить движком с датчиками холла(аналог/цифр),оптическим квадратурным энкодером, sensorless mode. Ток измеряется с помощью внешнего ацп.Динамическое торможение присутствует. Раздельная цифровая и силовая земля.

Сообщение отредактировал Dars - Aug 14 2008, 07:54

Прикрепленные файлы

 motor_drive.pdf ( 108.65 килобайт ) Кол-во скачиваний: 307

 

[haker_fox]

Ну если вам нужен Faul detection то именно так и делают. На спец процах(напр tms320) есть даже специальная ножка FAULT, к которой подключаете выход компаратора.

Хорошо, значит это решение работает.

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

Если я не ошибаюсь, то в схеме, приведенной Вами, нет аппаратного отключения моста при перегрузки. Нет опасений, что сбойнет МК? С другой стороны МК у Вас ARM, значит автоматом перейдет на внутренний RC если будут проблемы со внешним кварцом. Верно?

Ну на будущее, предлагаю посмотреть на мое решение для управления бесколлекторым(можно и коллекторным) двигателем.Есть возможность крутить движком с датчиками холла(аналог/цифр),оптическим квадратурным энкодером, sensorless mode. Ток измеряется с помощью внешнего ацп.Динамическое торможение присутствует. Раздельная цифровая и силовая земля.

Да, посмотрел Спасибо! Кое-что интересное уже сейчас увидел)

[SasaVitebsk]

Хорошо, значит это решение работает.

Как то делал более 20А с пусковым током ~100 или более. Так что 6A - детский лепет.
Особенно сказывается если напряжение высокое. Ток сам по себе - ерунда. Подсмотрите силовую часть в стандартном приводе и постарайтесь ничего не выбрасывать. Например дросель.

Я бы прислушился к мнению Dars. Считаю высказанное им очень справедливым. Я проходил когда-то нихромовую проволоку с компаратором. В конечном итоге конечно всё заработало...

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

Конечно это всё зависит от конкретного схемного решения.

PS: Разделение цифровой и силовой земли - тоже очень хороший тон. На всех этапах.

[haker_fox]

Как то делал более 20А с пусковым током ~100 или более. Так что 6A - детский лепет.
Особенно сказывается если напряжение высокое. Ток сам по себе - ерунда. Подсмотрите силовую часть в стандартном приводе и постарайтесь ничего не выбрасывать. Например дросель.

Хорошо. Я постараюсь найти и посмотреть схемы фирменных приводов.

Я бы прислушился к мнению Dars. Считаю высказанное им очень справедливым. Я проходил когда-то нихромовую проволоку с компаратором. В конечном итоге конечно всё заработало...

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

Если пойдёте по этому пути, то имейте ввиду следующие моменты.
1) Необходимо учесть скорость нарастания тока и время реакции вашей системы.

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

2) Необходимо ввести постоянную времени регулирования. Она должна соответствовать частотным характеристикам ваших ключей.

Можно чуть чуть подробнее. Не совсем понял о чем идет речь?

PS: Разделение цифровой и силовой земли - тоже очень хороший тон. На всех этапах.

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

Аппаратного нет. есть программное. аппартаное здесь можно сделать только путем добавления шунта, который я ставить не хочу. на датчике тока от аллегро сделать аппаратную защиту не получиться, т.к rise time = 5мкс. а у меня там еще стоит фильтр на 2kHz( то есть rise time еще больше) для того чтобы с ацп снимать среднее значение тока и по нему управлять двигателем. МК не сбойнет. на схеме цифровое и силовое питания раздельны, помех никто не генерит.

Т.е. в Вашем случае имеется в виду, что от аппаратной защиты также и будет толку по причине высокого Rise Time? Аппаратная защита должна работать быстрее?

[Dars]

Т.е. в Вашем случае имеется в виду, что от аппаратной защиты также и будет толку по причине высокого Rise Time? Аппаратная защита должна работать быстрее?

Конечно. Смысл аппартной защиты в том, что она срабатывет мгновенно. Повысился ток, она сработала.Программная будет работать значительное дольше. Но прежде чем ставить аппаратную защиту стоит определиться а нужна ли она?Дело в том, что любой двигатель можно форсировать прогоняя через него повышенный ток. На какое время его можно форсировать, вопрос сложный. Мне ребята из Maxon на одну из интересовавших меня моделей назвали время форсирования 1минута при перегрузке по току в два раза. И несколько секунд при перегрузке по напряжению в 2-3 раза и при зажатом вале! То есть в любом случае, моя программа успеет отключить двигатель до того как он сгорит!! Именно поэтому в моей схеме отсутствует аппаратная защита. Я точно знаю, что в самом худшем режиме мой двигатель проживет достаточно времени, для того чтобы успела сработать программная защита.

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

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

Сообщение отредактировал Dars - Aug 15 2008, 07:26