ИК паяльная станция на Arduino Mega 2560. Доработка скетча "ARS_v2_Lilium_JSN"

Большой разницы нет с какими числами работать. Точности в 5-6 знаков вполне хватит. А вот процессору легче.

 

Если есть у кого целочисленная библиотека ПИД, продублируйте, пожалуйста.

 

Стандартная библиотека PID_v1 может работать и с числами с плавающей точкой(double ) и с целыми числами(int). Проверьте, все компилируется без ошибок

Ваш ответ мне не понятен. Все целочисленные типы byte,int, long потому так и называются что не принимают значения после запятой(0,9999). Есть коэффициенты (допустим И-интегральный и Д - дифференциальный), которые могут быть малыми и поэтому меньше 1. Что вы хотели сказать этим "в 5-6 знаков"?

 

Нет, просто уставка температуры нижнего нагревателя

 

Дело не в ошибках, а в размере кода. Когда используются переменные double и иже с ними размер кода, а соответственно и размер занимаемого ОЗУ увеличивается. А у некоторых из нас arduino uno или pro или другие с mega328 на борту, то там ресурсы ограничены и их надо экономить. С другой стороны чем меньше и оптимальнее код тем быстрее работает программа. Не надо забывать что процессор у нас 8бит и работать с большими числами, даже целыми, ему трудно, поэтому надо по возможности избавляться от типов больших чем byte, int, char...

 

При разговоре о малых величинах говорят о точности в знаке после запятой. Если нам достаточна точность в 0.00001, то для перехода в целые числа достаточно результат умножить на 100 000. А если максимальное значение коэффициента не бывает больше 30.0, то получаем диапазон в целых числах 0-3000000. Типа long вполне хватает для этого. Процессор гораздо быстрее справляется с целыми числами, программа будет выполняться значительно быстрее. Но мы привыкли воспринимать коэффициенты в дробях. Например, 154389 нас ужаснет, а 1.54389 воспримется правильно. Потому на экран потребуется выводить десятичную точку в нужном месте. Это же относится и к показаниям напряжения, мощности и т.п.

 

Если в функции определены вещественные типы, то входное целое значение будет преобразовано к вещественному типу, обработано как вещественное и при возврате снова преобразовано в целое.

 

Я автоматику для пивоварения с целымии строил сразу. Правда алгоритм пид сам прописал, не было готовых библиотек под МК atmega... И я во всей не малой программе дроби нигде не использовал. Как только хоть одну дробную переменную объявлял - место в контролере (atmega8) сразу не хватало. Подтягивалась какая-то библиотека (в cvavr) И не столько из-за скорости это делал, сколько для экономии места.

 

Да, относительно нагруженности процессора. Какой период расчета у ПИД задан? Его не имеет смысла делать чаще чем будет заметно изменение с датчика температуры.

 

Стандартная скорость нарастания температуры 1 градус в секунду. Потому думаю, что достаточно 3х вычислений в секунду. При правильно подобранных коэффициентах ПИД на первичном нагреве до 80% можно и раз в 3 секунды принимать решение. Т.к. большая точность в этот момент не сильно требуется. Вот 40 градусов оставшихся требуется набирать точно, плавно и без выбросов в конце профиля.

 

revolover, кинь ссылку на темку сюда. Я конечно попытаюсь ее самостоятельно найти...

 

bambik, какую темку? Если по контроллеру, то это был коммерческий проект. Устройство от и до, без внешних обсуждений.
А вот относительно периода, тут даже не от градуса отталкиваться нужно, а от дискретности температуры, какая она у нас на входе в алгоритм с датчика 0,1 градус? Точный контроль будет, если приблизительно за 1 период мы получим изменение температуры на один такой шаг, но при этом работать он сможет только как ПИ контроллер. Для Д составляющей, нужно изменение на несколько шагов за один цикл расчета. Я в своей программе выносил настройку этого периода в меню.

 

Д составляющая отталкивается от "ускорения" ошибки. Как правило помогает сгладить график роста (что-то вроде фильтра шумов) , но с керамикой отзывчивость низкая, и Д я бы не применял, а вот с лампами лучше должно быть.

 

bambik, выбросы в конце зависят от точности подбора коэффициентов, и внешних факторов. Что-бы их избежать, нужно выходить на температуру плавнее, уменьшая И коэффициент. И не превышать нормальный П, но выход последних градусов может сильно затянуться(

 

http://we.easyelectronics.ru/Theory/pid-regulyatory--dlya-chaynikov-praktikov.html
Я не знал, что это у тебя коммерческий проект был. А библиотека ПИД регулятора так же составляет коммерческую тайну? Может будет у тебя добрейшая воля поделиться этим произведением?

 

Оказывается, что целочисленная библиотека ПИД регулятора давно выложена фирмой Atmel и не является коммерческой тайной. Вот она:

 

Часть параметров int, часть long. Будьте внимательны.

 

bamik, Секрета нет никакого, в коде правда разбросано. Там некоторые изменения логики в зависимости от режима были.
Код выполнялся по прерыванию таймера.
Вот попробую выцарапать ккусочек. Всё просто до жути, зачем вообще библиотеку лепить)))
Кстати это моя первая программа была. На правильность не претендую, но работало безукоризненно, значительно лучше проектов "из тырнета", и в отличие от них устройство было упрощено и удешевлено при этом функционал выше, управление проще, настройки более гибкие. Для продажи было самое ОНО)

set_temp - уставка
temp - текущая температура
set_pwm - значение мощности

Код (C++):

void pid(void)
{
error=set_temp-temp;
I+=error;
set_pwm=(kp*error/10+ki*I/1000-kd*(pre_error-error)/10);

pre_error=error;
}

Деление на 10 и на 1000 - точно не помню, подстраивал еще и для удобства работы в интерфейсе. Суть в том, чтобы после деления оставалось число, которое для регулирования имеет решающее значение.

Дальше еще ограничения параметров где-то в коде
И делал такую фишку: для разных температур 40 и 80 градусов испарение воды было разным и система работала вся на этих температурах по-разному.
У меня было два коэффициента kI. И для каждого градуса линейно вычислялся свой. Так на разные температурные паузы выходил одинаково чётко.

Честно, не знаю, чем это поможет, тут ничего нового...(((

 

revolver, в Вашем случае параметры среды менялись, потому коэффициенты менялись. В случае паяльной станции можно тоже говорить о нелинейной потере тепла, но оно не значительно. Достаточно одних коэффициентов. Основным недостатком всех программ для нагревателей считаю то, что уставку делают одну и ждут, когда температура к ней подберется. Для ооочень инерционных систем это не вредит. В нашем же случае включенный на полную мощность нагреватель способен сжечь быстро нагреваемые части. Потому придумывают разбитие профиля на части, полки, ограничение максимальной мощности и т.д. А происходит это из-за ПИД, который, видя огромную разницу температур, говорит включить полную мощность. Я считаю, что термопрофиль нужно задавать не кучей шагов с различными уставками и временами, а одной конечной уставкой и коэффициентами некоего уравнения зависимости температуры от времени. Уравнение, например, квадратичное. Длительность процедуры в секундах равна уставке в градусах. Тогда средняя скорость набора температуры будет равна 1 градус в секунду. Но сначала она будет расти быстрее, а в конце нагрева медленнее. В ПИД же каждую секунду должна отправляться новая уставка температуры согласно графику. Тогда ПИД будет выдавать ту мощность, которая требуется именно в данный момент, а вылеты за пределы профиля будут минимальны.