Comments 20
"номинальное напряжение 1700 В; номинальный ток 2400А; пиковый ток 4800В "
Все-таки пиковый ток - тоже в амерах, а не в вольтах :) Поправьте.
Но бороться с паразитной ёмкостью элементов достаточно трудно, а вот уменьшить сопротивление можно, что даст эффект такой же, как и уменьшение ёмкости.
Обычно паразитная емкость высоковольтного делителя вылазит с противоположной стороны(отрицательным выбросом) и компенсируется добавлением емкости в нижнее плечо.
И как по мне то защита должна быть хардварной, без АЦП и МК
Тот самый случай, когда нужно использовать ПЛИС. Даже самая дешёвая на таких наносекундах будет работать стабильней, чем ARM (судя по "100 МГц"), особенно после того, как контроллеру драйвера допишут всю остальную программу управления и по программистской привычке добавят программных костылей.
Вот уж воистину, верна поговорка "У кого чего болит...". Прям показательный случай ))
"У вас чешется Гондурас? Ну так не чешите его" ))))
Надеюсь это какой-то метаироничный комментарий... :)
Что-то в этом есть. Я уже привык, например, что на хабре аббревиатурой ООП называют вовсе не "организацию освобождения Палестины")
Но из всех сокращений в статье я не понял только ПНИ. Например, у меня под окном такое заведение есть - "психо-неврологический интернат". Психушка в переводе с новояза.
И вроде тоже студентом был, но такой аббревиатуры не встречал.
Вы не боитесь, что на реальных изделиях ваш драйвер будет произвольно подвисать от различных выбросов ЭМ связанных с коммутацией огромных токов ? Микроконтроллеры весьма ненадежный элемент в этом деле. На мой взгляд схему драйвера стоило бы сделать даже не на ПЛИС, а на дискретных логических элементах.
Раз уж сделали на МК, позаботьтесь о фильтрации питания МК, об экранировании от ЭМИ, и о гальванической (оптронной) развязке управляющих сигналов.
Боялись. Поэтому каждый такт считали. Потом проверяли на стенде долго. Но сейчас драйвер прошел опытные испытания на реальный ключ с полным напряжением и на полную нагрузку. Показал себя хорошо.
Но тут надо еще добавить, что управляющие сигналы по оптике идут в этом решении, развязывать нечего.
Вы испытывали на полную нагрузку (максимальный ток) ? А нагрузка была резистивной или индуктивной ? Как правило такими ключами питают индуктивную нагрузку (электродвигатели) и там выбросы будут - дай боже. От наведенных ЭМ помех контроллеры мрут (останавливаются) на расстоянии нескольких метров. В общем, тестируйте тщательнее, ошибка в таких изделия может стоить жизни.
Но тут надо еще добавить, что управляющие сигналы по оптике идут в этом решении, развязывать нечего.
Я имел в виду развязать оптронами сигналы от МК к транзисторам, чтобы по ним обратно в МК ничего не прилетало.
"в функцию прерывания, где реализована основная логика работы" - что? Что вы там употребляете, товарищи? В прерывание зашёл, битик установил и выскочил, в этом вся суть прерываний, никто в прерывания логику не помещает. Два раза прочитал статью, так и не смог понять, какая задача решалась. Драйвер управления igbt - это транзисторная сборка, которая должна очень быстро изменить ток базы, чтобы полевой транзистор открылся, и так же быстро изменить ток базы таким образом, чтобы затвор полевого транзистора разрядился, то есть задача драйвера сделать так, чтобы транзистор находился как можно меньше времени в линейном режиме. Кто и как додумался сюда воткнуть микроконтроллер - ума не приложу, это же бред. Никто так не делает, оно даст сбой в неподходящий момент, все такие вещи решаются только в железе.
Интересно, как же вы предлагаете делать строго тактированные по времени расчеты системы управления? Или тактированные по триггеру. Вы видимо не до конца представляете специфику работы софта под микроконтроллер без операционной системы. Только в прерываниях и делают основные расчеты системы управления, требующие строгой дискретизации.
По поводу самого драйвера, вы забываете, чтт функция современного драйвера не только в том, что закрыть-открыть ключ. А ещë логика контроля аварий, выставления сигналов обратной связи и прочее.
Добрый день, уважаемый (ые) автор (ы). Спасибо за интересный материал! Хотел бы поинтересоваться:
1) Почему выбор пал на TI c2000 серию, с учётом того, что изначально статья вроде позиционировалась как "ипортозамещение". А далее, применялся ли Simulink, как инструмент разработки оптимизированного кода? Рассматривали ли как альтернативу STM F4, G4 и т.д. и его китайских "братьев". И аналогичный пакет Simulink пол STM?
2) 17 класс, в принципе, с моей точки зрения, допускает к применению соответствующие специализированные микросхемы, начиная с ACPL, ISO58.., NSI и т.д. с изоляцией до 5,7 кВ, которые обычно и применяют при проектировании данного типа устройств. Безусловно, помехи и т.д. от чего спасает оптика, но, например, применение открытого коллектора и различных схем позволяет делать токовую петлю от 10mA сигнал, что по опыту, правда сотен кВ, достаточно. Рассматривали ли данную концепцию? Наверное, применение МК, обусловленно спецификой работы защиты в многоуровневых инверторах (сам не сталкивался).
3) Хотелось бы поподробнее узнать о реализации и возможности управлять уровнями (м.б. и двухуровневым) снижением напряжения затвора при срабатывании desat.
4) Реализованы ли функции изменения тока затвора в разработанном драйвере?
Прошу прощения, если допустил ошибки или неточности в вопросах. Благодарю за ответ!
Соглашусь с одним из комментаторов: защита по мгновенному току должна быть строго аппаратной. Если не на ПЛИС, то на рассыпухе, благо она относительно несложная.
По уходу в прерывание: я бы на Вашем месте начал с переноса всего «быстрого» кода, а то и таблицы векторов прерываний в ОЗУ. Судя по описанию, код весьма компактный. А первое «бутылочное горлышко» при уходе в прерывание, которое приходит на ум - это быстродействие flash, которое совсем НЕ 100МГц. Ну и следом если вы пишете на c, а не ассемблере - то сделать обработчики прерываний niked и самостоятельно писать сохранение/восстановление контекста. В принципе можно вообще обойтись без стека.
Конечно, идея запрячь периферию чтобы она сама работала - нравится мне гораздо больше, это правильно и так и должно быть. Но прерывание, срабатывающее у Вас «вдогонку» - тоже навскидку должно быть довольно быстрым.
Как мы проектировали свой отечественный драйвер IGBT