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

Кстати считаю, что такой способ записи в eeprom лучше. Здесь я привел пример. Заводим промежуточные целочисленные переменные и читаем их из памяти. А коэффициенты получаем домножением на множитель с плавающей точкой

Код (C++):

void setup() {
byte p,i,d;
p = EEPROM.read(10); Kp1=0.25 * p;
i = EEPROM.read(11); Ki1=0.01 * i;
d = EEPROM.read(12); Kd1=0.1 * d;
}

 

То о чем пишу касается тех, у кого дисплеи с I2c и версия IDE 1.6.x. У меня корректно отображаются показания только на этой и ранее поэтому ей и пользуюсь. Я библиотеку не менял, на 1.6.0 все работает

По сути - я раньше замечал ошибки с еепром в выложенных скетчах.
Ее причина в том что запись/чтение числа типов float, double (8 байт ) занимает 8 ячеек еепром, типа byte (1 байт ) занимает 1 ячейку. У snmar4enko допустим в версии 2.0.7( http://radioservice.at.ua/forum/23-27-3191-16-1525668605) заданы переменные

Код (C++):

double kp1;

double ki1;
double kd1;
double kp2;
double ki2;
double kd2;

Здесь ошибка

Код (C++):

  kp1 = EEPROM.read(480);
  ki1 = EEPROM.read(481);
  kd1 = EEPROM.read(482);
  kp2 = EEPROM.read(483);
  ki2 = EEPROM.read(484);
  kd2 = EEPROM.read(485);

Правильно будет

Код (C++):

  kp1 = EEPROM.read(480);
  ki1 = EEPROM.read(488);
  kd1 = EEPROM.read(496);
  kp2 = EEPROM.read(504);
  ki2 = EEPROM.read(512);
  kd2 = EEPROM.read(520);

В новых версиях есть функции EEPROM.put и EEPROM.get
Они благополучно запишут и прочитают любой тип данных

 

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


Стекло, конечно горяченное, но продувка чуть улучшает ситуацию.
Мне кажется лампы по 4 последовательно стоило ставить, а то дури многовато
В любом случае, такой аппарат для моих первых попыток пайки BGA будет лучше прожектора и утюга)

 

А зачем промежуточные? Пишите так

Код (C++):

Кp = EEPROM.read(10)*0.25;
 

и т.д

 

Не совсем так как вы думаете.

Нет там ошибки. А вот так как вы предлагаете будет не ошибкой, конечно, но без толку.
Смотрите. Дело в том что функция EEPROM.read сама по себе читает только один байт, а функция EEPROM.write пишет только 1 байт. Поэтому при записи или чтении double фактически пишется и читается только 1 байт.

Эти, да, пишут все как надо.
Вопрос в другом. А зачем писать double или float в eeprom? Подумайте над этим.

 

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

Видимо старший байт, отвечающий за целую часть.

Логично что не за чем. Если точности в несколько знаков хватает, проще записать целое число

 

Я бы посоветовал, если возможно, дробное число сохранять в виде целого. Например, Кi=0.01. Сохраняем число Ki*100, а при чтении просто делим на 100. В итоге, как правило, удается уложится в 1 байт.

 

Я везде байтом оперировал, а функции ПИДа отдавал разделив. Потом вообще ПИД на целые перевел.

 

Всем привет! Я приступил к работе над тем же скетчем, и вношу потихоньку исправления.
Касаемо работы ПИД.
Сделал вывод в порт отдельных составляющих, предварительно отделив их в библиотеке пида.
И вижу, что полнейший бред на выходе!
Я был ранее прав, что И составляющая за пару секунд выводи мощность на 100%.
Но я и не думал, что П составляющей там просто в сумме нет. Оказалось, что алгоритм работает в режиме P_ON_M, это совсем не классический ПИД. Переключил обратно.
Появилась П сост. В ПИД посылаю кР поделив его на 10.
kI посылаю деленную на 1000
С такими параметрами можно ПИД уже отстраивать.
Диф. сост. еще не смотрел.
Теперь нужно дописать регулятор так, что бы на ПИД переходить за несколько градусов до уставок.
И всегда за равное количество градусов.
Таким образом можно kI подобрать, что бы предельно точно попадало в цель.
Я так делал, результаты отличные.
Может это мне достался такой неправильный скетч, а у вас алгоритмы иные - не знаю, но это точно не дело.
Вобщем скоро до ума доведу.
Как часто производить вычисления еще не решил. Но уж точно не 100 раз в секунду или сколько там?) Достаточно 1 раза в секунду я думаю. Должна образовываться разница между расчётами для Д сост. Кстати тем кто хочет пользоваться P_ON_M эта разница тоже нужна, она на kP умножается.
На пальцах грубо и не точно о частоте: 100 раз по 1-2мл лить в стакан, а потом переливать в большой бутыль, и так до определённой отметки. Или же наливать жидкость в стакан и переливать его в бутыль. (стакан - 1% мощности). Результаты будут одинаковы, а рессурсы сэкономлены.

Вызывать просчет ПИД в идеале по прерыванию, не помню как в скетче... Прерывание подойдет от детектора 0. Поставить счетчик и раз в 100 прерываний считать ПИД.

 

Я думаю что пересчитать ПИД надо не чаще чем опрашивается датчик температуры (max6675 вродибы не более 4х раз в секунду), а то получается что температура ещё не измнилась (даже не измеряли), а ПИД поновой пересчитали. Думаю что пересчитывать надо 1-2 раза в секунду.

 

Совершенно верно, а то ПИД и к забору можно прилепить, мерить его скорость и дуть на него вентилятором)

 

У нас раз 10 максимум, больше не получается.

Маловато будет.

Результат будет разный по точности. Чем мельче тара тем точнее розлив.

Мах6675 может выдавать значения каждые 170-220мс. По теории каждому новому значению температуры должен соответствовать новый расчет ПИД. Но, как не парадоксально, при таком подходе из-за редкого получения температуры и задержки её на цифровом фильтре на выходе получаются заметные на глаз скачки мощности. Если считать ПИД 7-10 раз в секунду такого эффекта не наблюдается.

 

совсем не мало

Если вашим языком - сложатся до кучи все погрешности. но суть не в том, а в лишних движениях.

Потому что ПИД не работает, в таком виде, как в скетче.

 

А теперь о глюках... добавил в профиле третий шаг. И полезли странные переменные в значениях настроек. Поисправлял в скетче всякие int и double связанные с eeprom на byte. стало меньше кривых переменных но по-прежнему не сохраняются параметры третьего шага.

 

Нет, не так. Погрешность суммы есть сумма погрешностей её частей. Так что не будет там увеличения погрешности.

1 раз в секунду дает точность в 10 градусов при возможности регулировки мощности в 1%.

 

А какой скетч вы используете?

 

http://forum.amperka.ru/threads/ИК-...а-ars_v2_lilium_jsn.10176/page-29#post-155318

 

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

 

Это не моя теория, это теория расчета регуляторов. Вот цитата

Значит для времени 1 сек точность поддержания 10 градусов. Ну это в теории.
Вот ещё относительно расчетов.

 

Это совсем не теория... это по опыту(ПРАКТИКА), а он разный бывает, и системы разные, и заключения по опыту разные(правильные, не правильные).
А статей и книг читал я в свое время много, и даже такую вроде встречал.
Делить на (от 10 до 100) - правильно! Засеките, сколько времени у вас низ на уставку выходит(не набирает заданную температуру, а стабилизируется и не колеблется) в секундах. разделите на 10 ... 100.
А приписка

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