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

Немного нового видео ))

 

текстолитовый маньяк ))

 

Смотрю я видео с галогеном и мне все больше нравиться его работа, пид и скорость прогрева просто ошеломляют.

на кварце со стеклокерамикой все более инертно, но работоспособно.

снятие без_свинец, долго нижний нагреватель выходит на уровень ...

 

а где у вас термопара низа стоит? На фото вижу только одну возле чипа

 

за головой ее не видно (на заднем краю платы)

 

Немного теории. Речь касается последней версии sketch_TFT-320x480_dimer_PC_revolver_Dmitrysh_v4 и моей версии пост #2560
Целевая температура, к которой стремится ПИД, формируется так:

Код (C++):

        if ((currentMillis - previousMillis) > 1000 / (profile.rampRateStep[currentStep - 1] * 0.1))  {  //скорость роста температуры от 0.1с. до 3с.  
          previousMillis = currentMillis;
          counter = counter + 1;
          setpointRamp = counter + startTemp;
 

т.е. вычисляется время когда надо увеличить на 1 температуру, которую потом передаем ПИДу в качестве целевой. Это время может быть и меньше секунды и больше в зависимости от параметра "скорость роста температуры ". При этом расчет реальной температуры осуществляется 4 раза в секунду.
В своей программе решил поместить расчет целевой температуры рядом с расчетом ПИДа.
Получилось так:

Код (C++):

      if (millis() > nextRead1)     {          // график температуры nextRead1
         nextRead1 = millis() + SENSOR_SAMPLING_TIME;
         Count1++;
         TempRead();    //  считываем температуру
         if (chast < (Температура низа)) {  // это условие работы низа
           bottomTemp =<стартовая температура> + <Скорость роста температуры>*Count1/4;
         }
           else bottomTemp = <температура низа>;
           Output2 = Pid2(Input2,bottomTemp,kp2,ki2,kd2);
 

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

 

Идея хорошая, но "палка" всегда о двух концах. Сколько это нам будет "стоять" по вычислительным затратам?

 

Практически один в один, в одном месте убирается, в другое переносится.
У меня есть продолжение кода, где есть идея как сэкономить ресурсы МК:

Код (C++):

  int chast = Count1/4;    // получаем секунды, нужно для вывода графиков
  int kluch =  Count1 % 4;  // принимает значения от 0 до 3
// по этой переменной разделяется по времени вывод графиков раз в секунду и передача данных на комп
// и еще 2 состояния свободны пока))
         if (kluch ==1) {
           TimeLine(chast+X_graf);               // линия времени
           myGLCD.setColor(VGA_RED);    
           M_dr_point(chast-2, bottomTemp);      // рисуем ожидаемый график низа
       
           myGLCD.setColor(VGA_LIME);
           M_dr_point (chast-1, tc2);             // рисуем график низ
           myGLCD.setColor(VGA_AQUA);
           M_dr_point (chast-1, tc1);             // рисуем график верх      
           myGLCD.setFont(SevenSegNumFont);
           myGLCD.setColor(VGA_SILVER);
           myGLCD.printNumI(tc1,50, 45,3,'0');    // выводим температуру верха
           myGLCD.printNumI(tc2,350, 220,3,'0');  // выводим температуру низа
         }
  #ifdef SetConnectPC
        if (kluch ==2) {
          sprintf (buf, "OK%03d%03d%03d%03d%03d\r\n", int(Output1), int(Output2), tc1, tc2,int(profileName)); // график ПК
          Serial.print(buf);
          }
  #endif
 

 

Приветствую. Немного ресурсов МК, а точнее ОЗУ, можно сэкономить, если вместо функции sprintf пользоваться sprintf_P. В вашем примере
sprintf (buf, "OK%03d%03d%03d%03d%03d\r\n", int(Output1), int(Output2), tc1, tc2,int(profileName));
попробуйте заменить на
sprintf_P (buf, PSTR("OK%03d%03d%03d%03d%03d\r\n"), int(Output1), int(Output2), tc1, tc2,int(profileName));

http://mainloop.ru/avr-atmega/avr-progmem-strings.html

 

А смысл? Ну есть у меня мысли по этому поводу, но мне кажется здесь потянем, там развяжется.

Чтобы это работало, надо иметь float <скорость роста> и float bottomTemp, а у нас они целые.

 

Сделал чертежик для китайских резистивных кнопочек, может кому пригодится

 

такие как на фото

 

Действительно <скорость роста> у нас имеет тип byte, но этот параметр в 10 раз увеличен и мы его все равно делением преобразуем в float или double. В посте #2566 <Скорость роста температуры> это операнд написанный для наглядности, в реальной программе он вычисляется заранее и по сути является константой (кстати и деление на 4 надо отсюда убрать).
Что касается bottomTemp, то ничего не мешает ему стать float или double, тем более что в подпрограммах дла расчета ПИДа этот параметр для верха тип byte, а для низа double.

 

Спасибо, возьму на заметку.

 

Это не совсем так, там для наглядности умножение на 0,1. А в реальности строчка

Код (C++):

if ((currentMillis - previousMillis) > 1000 /(rampRateStep[currentStep - 1] * 0.1))

преобразуется компилятором в такую

Код (C++):

if ((currentMillis - previousMillis) > 10000 /(rampRateStep[currentStep - 1] ))

Это косячок, там и верх и низ должен быть byte.

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

 

А как эта конструкция во флеш переменные загонит? И вообще от sprintf надо избавляться, очень медленная функция.

 

Во флеш она переменные не загонит, зато строчка "OK%03d%03d%03d%03d%03d\r\n" не будет висеть в оперативе. Действие макроса PSTR аналогично макросу F.

Медленная, зато удобно пользоваться, когда например число 87 надо отобразить как 0087.
Прародитель функции sprintf появился в конце 60-х годов, тогда компьютеры были врядли сложнее или быстрее контроллера AVR, и ничего, люди работали на таких машинах.