Как у нас с трихограммой?

<< < (13/47) > >>

реношник:
кстати тут  « Ответ #50 : 19.12.2018, 10:26:13 »

Тогда поправка будет (100-95) * 2 = 10.
Смотрим, какой был PWM в предыдущем цикле. Допустим, он равнялся 120. Новое значение будет 120 + 10 = 130.

Как у вас ШИМ больше 100% ?
или вы пользуетесь стандартной analogWrite()  ?
+++++++++++++++++++++++++++++++++++++++++++

" Я в свое время вдоволь "наигрался" с ПИДами, протестировал на реальных дозаторах... и сделал только параметрическое управление. "

Это я уже заметил, поэтому И,Д коэффициенты нулевые.
Подпрограмма ПИДрегулятора у меня компактная (несколько строчек), поэтому её оставляю полностью на всякий случай.


Perelesnik:
PWM это у меня такое рудиментарное имя переменной ( осталось с тех времён, когда в коде оперировал именно ШИМ ).  Потом перешёл на analogwrite,  а переменную не стал переименовывать, тем более, что смысл у неё остался примерно тем же.... только разрядность поменялась. Вернее, переменная у меня называется не PWM, а PWMout, но не важно.
Принцип вычисления от этого не меняется. Даже формула та же, только коэффициент к приращению отличается и ограничение предельного значения результата указывается разное  - в одном случае 100, а в другом 255 ( фактически у меня 250 указано по причине некоторых особенностей питания схемы... ну то такое... не принципиально). В реальных условиях работы программы переменная и не должна достигать своего предельного значения. Предел достигается либо при неверной первоначальной настройке дозатора ( когда дозатор физически оказывается не способным выдать необходимую дозировку на данной скорости полёта, и нужно  было поставить другое, соответстующее колесо дозатора), либо двигатель не вращается ( нет адекватных данных с энкодера).
А ПИД формула и у меня долгое время "жила" в коде с нулями на I и D , но потом при какой-то  очередной генеральной уборке в коде я её таки подчистил, чтобы просто не маячила перед глазами.

Perelesnik:
А, еще добавлю: сразу же подвяжите вычисление PWM к таймеру, а не просто позволяйте этому процессу происходить в цикле. Время, за которое происходит цикл, изменится, если что-то позже захотите добавить в код или убрать из кода. Да и вообще, при работе с периферией типа GPS время выполнения цикла становится величиной немного не постоянной.
А временная составляющая для нас важна - она определяет всю динамику управления двигателем.
Привязка к таймеру - это удобнее, чем менять коэффициент пропорциональности каждый раз после вставки в код каких-то дополнительных функций.

реношник:
Если честно, то не совсем понимаю - " подвяжите вычисление PWM к таймеру " о чем это...

А по поводу ШИМ, то я не использую analogwrite у меня идет прямое управление через регистры.
Идея в том, что бы пользователь мог изменить частоту ШИМ для оптимальной работы двигателя.
Навеяно это статьей : http://www.rcdesign.ru/articles/radio/esc_intro

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

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

У стандартной функции analogwrite частота ШИМ около 480 Гц.
В моем случае пользователь может задать частоту до 13000 Гц (просто большую частоту у меня не получилось наблюдать осциллографом).
По умолчанию я использую частоту ШИМ 1100 Гц.

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


Perelesnik:
О привязке к таймеру - в процессе регулировки оборотов двигателя программа вносит поправку в управляющий сигнал, увеличивая или уменьшая его на некое значение. К примеру, программа обнаружила, что скорость вращения ниже необходимой, поэтому, допустим, к предыдущему значению сигнала добавляет "1".  В следующем цикле опять добавляет, и в следующем... А сам двигатель, имеющий не мгновенное время отклика, достигнет требуемых оборотов, допустим, на сотом цикле. Но к этому моменту значение сигнала окажется избыточным. Поэтому после достижения требуемых оборотов двигатель уйдёт в разгон, и программе придётся уменьшать значение сигнала. Мы получим синусоиду.  Чтобы сгладить, а в идеале, исключить такие колебания, нам нужно синхронизировать динамку программного изменения управляющего сигнала с динамикой реакции двигателя.
Самый простой способ - подобрать значение, на которое мы в каждом цикле уменьшаем или увеличиваем сигнал, так, чтобы динамика примерно совпала. В нашем примере, допустим, синусоида сгладится, если мы будем в каждом цикле добавлять не "1",  а "0.001".  Но это будет работать только до тех пор, пока время выполнения каждого цикла программы будет неизменным. Если мы что-то изменим в коде, период также изменится. И снова получим синусоиду.
Поэтому я рекомендую производить такие вычисления не в каждом цикле программы, а создать искусственный, строго определённый цикл, не зависящий от того, каким окажется период между реальными циклами.
Классически это делается с помощью программного прерывания по таймеру. Но можно и без прерывания.

По частоте ШИМ теоретически все верно (ранее сам сильно " загонялся" вопросами максимального приближения ШИМ к  "постоянке" , хотя и не по теме двигателей). Практически же здесь разницы не заметил, хотя делал и так и так. Ни по мощности, ни по нагреву, ни по ресурсу двигателей. Возможно, если питать двигатель чисто от Ардуинки, и это очень маленький двигатель будет... Но мне с таким сталкиваться не приходилось. Так что частоты вполне хватает, и даже дополнительных мер по сглаживанию ШИМ применять не приходится. Только по питанию сглаживаю.
Как говорил один мой знакомый: "буде свербіть - будем чухатися". Будут симптомы - будем принимать меры. Тем более, что это очень простой вопрос, и решается тоже крайне просто.  Но за несколько лет такого вопроса так и не появилось в практике. Ни одного отказа или даже перегрева двигателей в полях пока не было (постучу по дереву на всякий случай, но факт).
Поэтому не уверен, что стоит такому уделять хоть какое-то  особое внимание.

А вот по количеству регулировок... это вопрос действительно интересный. Конечно, как разработчику, хочется буквально утыкать прибор переменными резисторами, чтобы и тот, и этот коэффициент можно было настраивать без влезания в код, и кучу тонких регулировок.... но у людей, которые на этой аппаратуре реально работают не ради научного любопытства, немного другой взгляд на вещи оказывается. В идеале им вообще нужна одна кнопка "вкл". И чтобы сразу деньги выдавало 😃. В общем, за избыток регуляторов я уже был и ругаем, и осуждаем. Поэтому пришлось исправляться в сторону минимально необходимого по настройкам. А минимально и реально необходим там только один регулятор, которым задается доза в миллилитрах на гектар.
Поэтому все настройки разных коэффицинтов - это сугубо моя работа и моя ответственность. Я делаю это До того, как устройство попадает в руки пользователя, и не загружаю человеку голову лишним - пилотам и кроме этого есть чем заниматься, и о чем думать.
А чисто для Себя можно и с десятком регуляторов сделать. Можно и без физических регуляторов, а через какое-то  приложение на ПК настраивать, сохраняя в энергонезависимой памяти устройства. Это уже дело вкуса. 
Просто если будете делать не только для себя, но и для других людей, учтите такой момент. Он довольно немаловажный. Все по максимуму должно быть преднастроено или иметь способность самонастраиваться в процессе работы (что ещё лучше).  Но вся эта наша " внутренняя кухня" не должна занимать внимание пользователя и работать без его участия.

Навигация

[0] Главная страница сообщений

[#] Следующая страница

[*] Предыдущая страница