avatar_ZYM

Контроллер Infineon

Автор ZYM, 24 Нояб. 2010 в 21:51

« назад - далее »

0 Пользователи и 1 гость просматривают эту тему.

DarthGray

Цитата: mevial от 06 Май 2011 в 11:19
Всё правильно, просто <phase current>=<rated current>/<pwm>

Не факт, pwm постоянно меняется, а токи в настройках с постоянным соотношением
Судя по даташиту на инфинеоновский микроконтроллер, время преобразования его АЦП = 1 мкс.
С такой скоростью он вполне успеет фазный ток померить напрямую, причём на каждой фазе отдельно
Различие между теорией и практикой на практике гораздо больше, чем в теории.

mevial

Цитата: DarthGray от 06 Май 2011 в 13:09
Не факт, pwm постоянно меняется, а токи в настройках с постоянным соотношением
Судя по даташиту на инфинеоновский микроконтроллер, время преобразования его АЦП = 1 мкс.
С такой скоростью он вполне успеет фазный ток померить напрямую, причём на каждой фазе отдельно
А теперь объясните как, используя 1 шунт, который с аккумулятора ко всем транзисторам сразу, да ещё и с электролитами.
А вот пересчитать относительно текущего pwm, почему бы нет, тем более, что значение меняется не само, его задаёт тот же микроконтроллер. Сколько надо времени, чтобы поделить данные с ацп на значение в регистре?

DarthGray

Цитата: mevial от 06 Май 2011 в 13:52
А теперь объясните как, используя 1 шунт, который с аккумулятора ко всем транзисторам сразу, да ещё и с электролитами.

Элементарно!
Что такое фазный ток?
Насколько я понимаю, это ток, протекающий по рабочей в данный момент фазе мотора
По этому через шунт в каждый конкретный момент времени будет протекать именно фазный ток
А общий ток потребления получится если проинтегрировать это значение за достаточно большое время  (по сравнению с периодом ШИМ)
электролиты стоят параллельно батарее и на измерение тока не влияют
Хоть шунт и один, но когда включена 1-ая фаза, через него будет течь ток 1-ой фазы, когда 2-ая, то 2-ой и т.д.
Так что не вижу никаких препятствий мерить все фазные токи на одном шунте, главное чтоб АЦП успевал
Различие между теорией и практикой на практике гораздо больше, чем в теории.

zap

[b-b]DarthGray[/b-b], нет, всё совсем не так. Фазный ток Вы правильно понимаете, но он легко превышает ток батареи потому что контроллер работает по сути как понижающий DC-DC преобразователь - имея на входе, к примеру, 40 вольт 10 ампер на выходе выдаёт 4 вольта и 100 ампер. И, кстати, необходимости в быстром АЦП нет - всё равно надо проинтегрировать фазный ток хотя бы на один-два-три период ШИМа, а это порядок цифр больше 100мкс.

[b-b]mevial[/b-b], понял что Вы хотели сказать - ток батареи получается умножением фазного тока на коэффициент заполнения ШИМ. Надо подумать, какая от этого практическая польза.
С уважением,
Андрей

Поражаю масштабностью некопмпетентность (ц) из лички

DarthGray

А я как сказал? Может не совсем ясно выразился...
Если фазный ток будет скажем 30А при заполнеии ШИМа 33%, то ток потребляемый от батареи будет 10А
А если мерить фазный ток делением общего на заполнение, то нифига его не ограничишь
Пока помереется ток потребления, фазный уже зашкалит
Различие между теорией и практикой на практике гораздо больше, чем в теории.

zap

Подумал, получается разумно.

На примере: предположим, батарея у нас даёт ток только до 10 ампер, соответственно ставим контроллеру такое ограничение. А выходные ключи у нас, к примеру, легко держат 40 ампер - ставим на фазный ток такое ограничение.

Теперь предположим, мы разгоняемся с места. Противо-ЭДС низкий, соответственно контроллер начинает с маленьких коэффициентов заполнения, например 0.1. Фазный ток ограничен 40 амперами, при этом ток батареи = 40*0.1 = 4 ампера, нормально.

Теперь мы разогнались до, предположим, половинной скорости. Коэффициент заполнения у нас уже 0.5, фазный ток предположим по-прежнему упирается в 40 ампер, значит ток батареи = 40*0.5 = 20 ампер. Фигово, превышен лимит, значит контроллер начинает сбрасывать коэффициент заполнения, пока не доходит до 0.25, тогда при токе 40 ампер ток батареи получается искомые 10 ампер. При этом тяга, естественно, падает.

То есть по сути, наличие этих двух лимитов означает, что элвел стартует резво, а дальше чем больше скорость, тем меньше динамика разгона.

[b-b]DarthGray[/b-b], Вы правы, я Вас неверно понял. Только общий ток никто не меряет, как мы уже выяснили, только фазный :)
С уважением,
Андрей

Поражаю масштабностью некопмпетентность (ц) из лички

DarthGray

Совершенно верно  :ay:
Именно это я и хотел сказать
Различие между теорией и практикой на практике гораздо больше, чем в теории.

mevial

Цитата: DarthGray от 06 Май 2011 в 15:23
Совершенно верно  :ay:
Именно это я и хотел сказать
Т.е. вы хотите сказать, что электролитические конденсаторы, стоящие до и главное после шунта ни на что не влияют?

DarthGray

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

i

Цитата: mevial от 06 Май 2011 в 15:34
Т.е. вы хотите сказать, что электролитические конденсаторы, стоящие до и главное после шунта ни на что не влияют?
Два года езжу без электролитов в силовой части контроллера (тех, что стоят параллельно аккумулятору). Заметил только, что "показометр" заряда дольше показывает "full", то есть врёт больше обычного.  А в остальном проблем нет.

zap

Цитата: DarthGray от 06 Май 2011 в 15:41
А как они могут влиять? Они же не параллельно шунту стоят
А обычные контроллеры потому и не могут ограничивать фазный ток, что у них скорости АЦП не хватает
Поэтому там фазный ток зашкаливает и мотор рычит при старте
Если посмотреть на схему, срисованную с EB206, пусть она и корявая, можно увидеть, что сигнал шунта проходит через RC цепочку. Ёмкость конденсатора, правда, не указана, но если предположить ёмкость, к примеру, 10 нанофарад, то постоянная времени будет 10k*10нф = 100 микросекунд, это около 10 килогерц. Так что никакого особого сверхбыстрого ЦАП тут не нужно. Просто контроллер не выдаёт сразу всю мощность, он постепенно от нуля начинает увеличивать коэф. заполнения, постоянно контролируя результат, пока не достигает нужного значения. Даже если он выйдет на нужную мощность за 10-20 итераций, ничего страшного - человек всё равно такие короткие интервалы просто не успевает замечать.

А электролиты нужны только для выравнивания тока батареи, чтобы вместо импульсов 20-5-20-5 ампер там были более-менее постоянные 10 ампер. По идее, это уменьшает потери на внутреннее сопротивление аккумулятора.
С уважением,
Андрей

Поражаю масштабностью некопмпетентность (ц) из лички

DarthGray

А схему сами срисовывали? Там может и 100пФ быть, а это как раз 1мкс.
Тем более, что в другой схеме, которую вы выкладывали, в усилителе на опере вообще нет никакой фильтрации
(я правда не смотрел хар-ки этого опера, может его собственная тормознутость и является фильтром)
Хотя описанный алгоритм тоже имеет право на существование

У меня вначале была мысль сделать контроллер вообще без шунта (когда я ещё хотел сам его делать)
А ток ограничивать исходя из скорости вращения мотора
Чем меньше оборотов, тем меньше разрешённая максимальная длительность импульсов ШИМа
Различие между теорией и практикой на практике гораздо больше, чем в теории.

zap

Схемку когда-то нашёл на endless-sphere, а сейчас просто дал поиск по имени pdf и нашёл у кого-то где-то в глубинах интернета :) только уже с какими-то дополнительными коментариями.

100пф там вряд ли, ну да ладно, спорить не буду. А LM358 это дешёвый тормозной ОУ, он сглаживает сам по себе. Ещё интересно, что в схемке приведённой выше напряжение шунта напрямую подаётся на микроконтроллер? У него что, встроенный усилитель есть?
С уважением,
Андрей

Поражаю масштабностью некопмпетентность (ц) из лички

zap

Ну что, 8 скачиваний и ни одного отзыва. То ли не работает, то ли всё работает просто шоколадно :D

Ладно, продолжаем разговор. Поговорим теперь о безбашенных экспериментах :)

Когда я снимал и анализировал формат данных контроллера, то обратил внимание, что для некоторых параметров не используется полный диапазон возможных значений. Каждый параметр задаётся одним байтом, байт может принимать любое значение от 0 до 255. Однако, например, параметр BlockTime оригинальный Parameter Designer позволяет задавать только в диапазоне 0-100 (от 0 до 10 секунд в единицах по 0.1с), а значение по протоколу можно засандалить аж до 255, т.е. 25.5 секунд. Если предположить, что он работает так, как описано, например, вот здесь, то этот параметр задаёт время, на которое контроллер позволяет фазовому току превышать заданное значение (на сколько? непонятно). Если же верить коллеге DarthGray, то данный параметр имеет отношение к функции защиты от угона (?). В любом случае, предположим, мы хотим попробовать увеличить диапазон задаваемых значений для этого параметра до физического ограничения контроллера. Как это сделать?

Открываем в текстовом редакторе файл xpdm/infineon.py. Находим описание искомого параметра, в данном случае BlockTime:

    "BlockTime" :
    {   
        "Type"        : "f",
        "Name"        : _("Overcurrent detection delay"),
        "Description" : _("""\
The amount of time before the phase current limit takes effect  \
Rising this parameter will help you start quicker from a dead stop, \
but don't set this too high as you risk blowing out your motor - \
at high currents it will quickly heat up.\
"""),
        "Default"     : 1.0,
        "Units"       : _("s"),
        "Widget"      : PWT_SPINBUTTON,
        "Range"       : (10, 100),
        "GetDisplay"  : lambda prof, v: v / 10,
        "SetDisplay"  : lambda prof, v: round (v * 10),
    },


Строка "Type" описывает тип параметра - число с плавающей запятой (float), ведь у нас параметр задаётся в секундах с точностью 0.1. Параметры Name и Description задают имя и описание параметра в интерфейсе, их пока не трогаем. Поле "Default" задаёт значение по умолчанию для этого параметра (используется при создании нового профиля). Поле "Units" задаёт единицы измерения параметра, в данном случае это секунды ("s"). Поле "Widget" задаёт тип поля для редактирования параметра - их может быть два: PWT_COMBOBOX (выпадающий список значений) и PWT_SPINBUTTON (прокручивалка чисел в определённом диапазоне). В данном случае видим, что BlockTime редактируется числокруткой.

Теперь самое интересное - поле "Range". Он задаёт диапазон значений параметра. В данном случае, диапазон стоит от 10 до 100. Если мы жаждем экспериментов, просто берём и увеличиваем диапазон возможных значений: например, пишем (10, 255). (значения ниже 10, наверное, не имеют особого смысла, тем более непонятно что должно произойти при нуле). В общем-то всё, мы достигли своей цели.

Ну и до кучи, поле GetDisplay задаёт функцию, которая преобразует параметр из числа в отображаемое значение (т.е. в нашем случае делит на 10, чтобы получить значения типа 2.5 секунд из значения 25). И, наконец, поле SetDisplay задаёт обратное преобразование - оно используется в случае, если пользователь решит ввести количество секунд вручную, например при вводе 6.3 параметр должен получить значение 63.

Наконец сохраняем файл, запускаем xpd и замечаем, что BlockTime можно задавать аж до 25.5.




Теперь про интересный параметр EBSLevel. При снятии протокола общения между Parameter Designer и контроллером, я заметил, что этот параметр всегда устанавливается в одно из значений 0 (нет рекуперации), 4 (средняя рекуперация) и 8 (сильная). Естественно, сразу возникает вопрос - а что будет, если задать нестандартное значение. К сожалению, до полевых испытаний у меня руки не дошли (сломалась каретка, жду пока привезут из Финляндии каретку нужной мне длины (131мм) с итальянской резьбой). Однако, если кто-то хочет поэкспериментировать, опишу как изменить программу для того, чтобы можно было задать любое значение.

Итак, ищем описание параметра EBSLevel. Вот он:

    "EBSLevel" :
    {
        "Type"        : "i",
        "Name"        : _("EBS level"),
        "Description" : _("""\
Electronic braking level. Choose 'Moderate' for smaller wheel diameters, \
and 'Strong' for 26" and up. The larger is the level, the more effective \
is braking.\
"""),
        "Default"     : EBS_DISABLED,
        "Widget"      : PWT_COMBOBOX,
        "Range"       : (0, 2),
        "GetDisplay"  : lambda prof, v: EBSLevelDesc [v],
        # This member, if defined, tells how to translate setting to raw value
        "ToRaw"       : lambda prof, v: v * 4,
    },

Итак, тут нам всё уже знакомо, за исключением того, что данный параметр редактируется через выпадающий список значений, а не числокруткой. Для экспериментов проще всего преобразовать данный параметр в числокрутку, чтобы можно было задавать любое значение. Итак, меняем "Widget" на PWT_SPINBUTTON, далее меняем "Range" на (0, 255), также добавим поле "Precision" и установим его в ноль (это количество знаков после запятой, нам без надобности дробные числа). Ну и, наконец, задаём две "проходные" функции SetDisplay и GetDisplay, без модификации параметра. Конечный вариант описания параметра будет вот такой:

    "EBSLevel" :
    {
        "Type"        : "i",
        "Name"        : _("EBS level"),
        "Description" : _("""\
Electronic braking level. Choose 'Moderate' for smaller wheel diameters, \
and 'Strong' for 26" and up. The larger is the level, the more effective \
is braking.\
"""),
        "Default"     : EBS_DISABLED,
        "Widget"      : PWT_SPINBUTTON,
        "Range"       : (0, 255),
        "Precision"   : 0,
        "GetDisplay"  : lambda prof, v: v,
        "SetDisplay"  : lambda prof, v: v,
    },


После этого запускаем xpd, и можем менять параметр рекуперативного торможения в диапазоне от 0 до 255. Надеюсь, контроллер от таких значений не сгорит :) Кстати, после каждого торможения с "повышенными" параметрами хорошо бы пощупать контроллер - вдруг выходные ключи начнут сильно греться. Фиг знает чем руководствовались китайцы, когда делали такие ограничения на этот параметр.

В общем, надеюсь понятно написал.
С уважением,
Андрей

Поражаю масштабностью некопмпетентность (ц) из лички

zap

Кстати, посмотрел в Parameter Designer'е - BlockTime и GuardLevel находятся прямо на одной строчке, один слева, другой справа. Возможно, действительно BlockTime относится к блокировке колеса :)

Хм, врут что-ли буржуи... Вот здесь даже целая ветка про то, как круто этот параметр увеличивает тягу на низах :D. Вот будет круто, если это окажется эффектом "голого короля"  :bj:
С уважением,
Андрей

Поражаю масштабностью некопмпетентность (ц) из лички

илс

Уважаемый zap!
Конечно Вы написали вполне понятным русским языком, но далеко не все способны понимать его уверенно:)
Осилить бы установку xpd с интерпретатором Питона и то достижение :bw:

Для людей далеких от модификации параметров путем исправления кода, было бы здорово сделать super extended PD, т.е. сразу забить в прогу расширенные параметры :)

Как я писал ранее, лично мне интересна (только) модификация EBS level. Конечно я попробую проследовать инструкциям выше, но если Вы  вложите  расширенный EBS level в архив xpd  - был бы очень признателен! :bq:

DarthGray

Цитата: zap от 07 Май 2011 в 17:03
Кстати, посмотрел в Parameter Designer'е - BlockTime и GuardLevel находятся прямо на одной строчке, один слева, другой справа. Возможно, действительно BlockTime относится к блокировке колеса :)

Хм, врут что-ли буржуи... Вот здесь даже целая ветка про то, как круто этот параметр увеличивает тягу на низах :D. Вот будет круто, если это окажется эффектом "голого короля"  :bj:


Андрей, ещё раз выражаю респект Вашим изыскам!
Виртуальный плюс Вам! (реальный поставить не могу пока, болтливостью не вышел...)
А насчёт параметра BlockTime  могу прям щас проверить свою версию, вел рядом с компом стоит
Минут через 15 сообщу результат
Различие между теорией и практикой на практике гораздо больше, чем в теории.

i

Цитата: DarthGray от 07 Май 2011 в 17:28
..Виртуальный плюс Вам! (реальный поставить не могу пока, болтливостью не вышел...)
Теперь реальный плюс (я уже достаточно наболтал).