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

Доброго времени суток всем,ребята есть большая просьба есть нагреватели кварц верх 600 ватт низ кварц 5 шт по 450 ватт кассеты, две твердотелки 40 ампер с зеро кросс ардуинка мега 2560 + tft 3,5" ну и плата ноля.какой архив со скетчем можно применить для этого всего?

 

Идем назад на 53 страницу и читаем #1059 3 абзац... И пост #1073. Опять обсуждаем одно и то же.

Таймер аппаратный и не имеет отношения к усложнению кода, в setup объявляется длительность аппаратного таймера одной строкой, так же как мы объявляем аппаратное прерывание, а в вызываемую им функцию вписывается исполняемый код, тот же что и в нашем аппаратном прерывании DIMMER. Все... Точность аппаратного таймера не зависит от кода основной программы, лишь бы им вызываемая функция успевала обработаться за выставленное время. Но так как у нас объект инерционный то этим временем можно играться от 5 до 200мС без особого ущерба для качества регулирования. С millis() аппаратный таймер не конкурирует, он оказывает на него такое же влияние как и аппаратное прерывание от датчика ZERO. Датчик 0 применяют для фазо-импульсного управления. Хотим ловить блох, нет проблем, строим фазо-импульсное управление, а потом боремся с помехами им создаваемым в тех же МАХ6675.... Но это то же уже обсуждалось ранее.... Я не против контроля 0 . Я против заблуждений в этом вопросе. А то я так понимаю многие построили контроль нуля над контролем 0. (Схему контроля нуля которая управляет симисторным модулем с контролем 0.) Контроль нуля в нашем случае всего лишь импульсы для подсчета полупериодов в алгоритме Брезенхема.

 

С сетью синхронизируется симисторный модуль с детектором 0, и при не совпадении таймера с 0 синусоиды выпадет максимум один полупериод. Контролируя объект МАХсами мы можем иметь минимальный интервал 200мС (хотя в скетче 1 сек). 10мС полупериода от 200мС - 0,5% подводимой к нагревателям мощности. а от 1 сек вообще 0,1% - ловля блох. Сквозняк в квартире окажет гораздо большее влияние... Более-менее качественно налаженный ПИД регулятор все эти возмущения отработает без проблем.

Разновидностей TFT 3,5" очень много (у них разные контроллеры внутри) т.е. под него нужна корректная библиотека и возможно придется править код т.к. есть особенности вывода данных на экран у разных библиотек. Внимательно смотрите куда подключаете контроль 0 т.к. в интернете много не правильных даташитов по распиновке прерываний у МЕГИ. Просто залив скетч работоспособного устройства не получится т.к. надо как минимум настроить ПИД регуляторы под свои нагреватели. Читайте последние страницы темы там есть скетчи в названии которых TFT. Пробуйте их. Но в них может быть много ненужного или не работающего т.к. тут все еще в поиске идеальной "шашлычницы" и у каждого идеал свой.... Так что читайте тему, осваивайте программирование и напильник.

 

На офсайте https://www.arduino.cc/reference/en/language/functions/external-interrupts/attachinterrupt/
есть примечание

что означает что во время обработки прерывания можно получить время, вызвав millis, однако оно не будет увеличиваться, поскольку использует первый таймер и тоже через прерывания, а при обработке текущего прерывания все остальные запрещены. Как работает millis с таймером при пропусках я не знаю и предполагаю что задержка может быть, хотя это и не логично.

 

Во первых двумя строками(там ещё старт таймера), а во вторых код становится больше. Смотрите.
Вот код с таймером

Код (C++):

#include <MsTimer2.h>

void setup() {
  // put your setup code here, to run once:
  MsTimer2::set(10, dimming); // 10ms period
  MsTimer2::start();
}

void loop() {
  // put your main code here, to run repeatedly:

}

void dimming()
{
PORTB |= 0b00100000;
}

Вот итог

Код (C++):

Скетч использует 3962 байт (13%) памяти устройства. Всего доступно 28672 байт.
Глобальные переменные используют 162 байт (6%) динамической памяти, оставляя 2398 байт для локальных переменных.

Вот код с прерыванием по детектору

Код (C++):

ISR(INT0_vect)
{
  dimming();
}
void setup() {
  //включим прерывания INT0 по нисходящему фронту

  EICRA |= (1<<ISC01);

  //разрешим внешние прерывания INT0

  EIMSK |= (1<<INT0);
  sei();
 
}

void loop() {
  // put your main code here, to run repeatedly:

}

void dimming()
{
PORTB |= 0b00100000;
}

Вот результат

Код (C++):

Скетч использует 3656 байт (12%) памяти устройства. Всего доступно 28672 байт.
Глобальные переменные используют 149 байт (5%) динамической памяти, оставляя 2411 байт для локальных переменных.

Точность самого таймера не зависит от программы, а вот точность отсчёта времени этим таймером ещё как зависит. Это разные вещи. Процессор тоже работает на фиксированной частоте, но при этом одну и ту же задачу при разных реализациях он выполняет за разное время.

Не вижу связи между временем выполнения программы и выставленным таймеру временем.

А у всех объекты разной инерционности, у меня, допустим, галоген, там инерции почти нет и мне чем быстрее тем лучше и точнее.

Ещё как конкурирует, millis "крутится" на таймере0. Таймер0 и таймер2 по-любому пересекаются. Вектор прерывания таймера2 выше по таблице прерываний чем таймера0, поэтому и обрабатываться он будет первым, плюс время выполнения кода в прерывании таймера2. В это время(когда обрабатывается прерывание по таймеру2) таймер0 "нервно курит в сторонке", но продолжает считать, а время(millis) - стоит.
По факту получается медленное отставание millis от реальности и соответственно увеличение реальных задержек в программе. Не надо вводить людей в заблуждение.
Справедливости ради необходимо заметить, что в выражении

вы абсолютно правы, тут вопросов нет.

Нельзя так категорично. Фазо-импульсное управление(оно же низкочастотный ШИМ) это только одна из возможных опций. У меня допустим прерывание от zcc используется для расчёта критической секции. И я делал ФИУ, не было у меня помех на мах6675. Давайте вспомнив ваше давнешнее выражение

я таки сделал это. Но есть одно условие - сигнал с датчика нуля должен приходить раньше нуля хотя-бы на 500мкс.

У меня нет SSR с контролем нуля и я думаю, что я такой не один.

Правильно сказать один полупериод за период расчёта воздействия. У нас воздействие считается 1-4 раза за секунду. В худшем случае пропадёт 4 полупериода, а в самом худшем 5(за счёт отставания millis из-за прерывания таймера2 при определённых обстоятельствах).

По даташиту 170-220, правильно брать максимальное значение, а лучше 250мс. Я пробовал читать 5 раз за секунду - результат отвратительный.

Сомневаюсь в правильности расчётов. Но должен сказать что даже минимальная ошибка в управлении нагревателями добавляется к общей ошибке работы системы. А зачем оно нам? Проще реализация? Тогда как же вот это

 

да нет там никакого старта... я же давал ссылку на свой пост #1059 где и ссылка на библиотеку #include"timer-api.h" и статья на эту тему... на счет код больше или меньше, мне все равно у меня МЕГА и начинался этот проект с МЕГИ и работать со сдвигами под силу 5% участников темы углубленным в программирование...

Согласен, такое высказывание более точное.

Не совсем понял Вашу мысль... В моем представлении аппаратный таймер получает синхроимпульсы напрямую от встроенного в процессор кварцевого генератора и счетчик подсчета импульсов это отдельная аппаратная схема не входящая в ядро процессора и эта схема программно предварительно настраивается на то количество импульсов которое надо подсчитать, а на выходе у нее аппаратное прерывание которое "тормозит" выполнение основной программы. Структура 328го ниже на рисунке. Встроенный таймер не может ошибаться в вычислении времени т.к. он тактируется от кварцевого генератора. Проблемы с подсчетом времени в самой программе это уже другая история связанная с корректностью ее написания.

Я в курсе, это я взял крайний случай... а лучше 300-500...

Почему то все тупо копируют работу с ЕЕПРОМ вытаскивая ее из разных скетчей предназначенных для разных аппаратных платформ и разных навернутых функций. 9 или 6 там надо ставить исходя из математики 3 класса... посчитав количество профилей используемых в программе и количество используемых в программе записываемых в ЕЕПРОМ переменных. Главное что бы в итоге адреса записываемых переменных не налезали друг на друга и не выходили за дозволенное поле адресов конкретной платформы. Вот пример адресации для 5 профилей.

Код (C++):

 profileSteps =         EEPROM.read((currentProfile - 1) * 27);                       //adress   0              27                54                81               108
  Setpoint2 =            EEPROM.read((currentProfile - 1) * 27 + 1);                   //adress   1              28                55                82               109
  for (int i = 0; i < 5; i + 1)
  {
    rampRateStep[i] =    EEPROM.read((currentProfile - 1) * 27 + i + 2);               //adress   2,3,4,5,6      29,30,31,32,33    56,57,58,59,60    83,84,85,86,87   110,111,112,113,114
    i++;
  }
  for (int i = 0; i < 5; i + 1)
  {
    dwellTimerStep[i] =  EEPROM.read((currentProfile - 1) * 27 + i + 7) * 5;           //adress   7,8,9,10,11    34,35,36,37,38    61,62,63,64,65    88,89,90,91,92   115,116,117,118,119
    i++;
  }
  for (int i = 0; i < 5; i + 1)
  {
    temperatureStep[i] = EEPROM.read((currentProfile - 1) * 27 + i + 12);              //adress   12,13,14,15,16    39,40,41,42,43    66,67,68,69,70   93,94,95,96,97   120,121,122,123,124
    i++;
  }
  for (int i = 0; i < 5; i + 1)
  {
    min_pwr_TOPStep[i] = EEPROM.read((currentProfile - 1) * 27 + i + 17);             //adress   17,18,19,20,21    44,45,46,47,48    71,72,73,74,75   98,99,100,101,102   125,126,127,128,129
    i++;
  }
  for (int i = 0; i < 5; i + 1)
  {
    max_pwr_TOPStep[i] = EEPROM.read((currentProfile - 1) * 27 + i + 22);             //adress   22,23,24,25,26    49,50,51,52,53    76,77,78,79,80   103,104,105,106,107   130,131,132,133,134
    i++;
  }
  kp1 =                  EEPROM.read((currentProfile - 1) * 9 + 172);                 //adress    172              181                190             199                    208            
  ki1 =                  EEPROM.read((currentProfile - 1) * 9 + 173);                 //adress    173              182                191             200                    209
  kd1 =                  EEPROM.read((currentProfile - 1) * 9 + 174);                 //adress    174              183                192             201                    210
  kp2 =                  EEPROM.read((currentProfile - 1) * 9 + 175);                 //adress    175              184                193             202                    211
  ki2 =                  EEPROM.read((currentProfile - 1) * 9 + 176);                 //adress    176              185                194             203                    212
  kd2 =                  EEPROM.read((currentProfile - 1) * 9 + 177);                 //adress    177              186                195             204                    213
  tableSize =            EEPROM.read((currentProfile - 1) * 9 + 178);                 //adress    178              187                196             205                    214
  min_pwr_BOTTOM =       EEPROM.read((currentProfile - 1) * 9 + 179);                 //adress    179              188                197             206                    215
  max_pwr_BOTTOM =       EEPROM.read((currentProfile - 1) * 9 + 180);                 //adress    180              189                198             207                    216  

 

Таймер работает не так просто, как вы представляете. Попробую объяснить.
Все таймера, какими бы они не были и где бы не стояли работают по одному и тому же принципу. Есть некоторая счётная схема, называемая таймером. Она тактируется от того же источника, что я ядро контроллера и считает до числа соответствующего его битности, затем происходит прерывание и таймер обнуляется и так по кругу. Восьми битный таймер считает до 256, а 16-и битный до 65535. Т.е на частоте нашей меги 16МГц 8-и битный таймер переполнится за 1сек 16000000/256=62500раз(период 16мкс), а 16-ти битный 16000000/65535 ~ 244раза(период около 4мс) с небольшой добавочкой. Т.к для практического применения такие скорости счёта слишком большие в таймерах есть т.н прескаллеры, они же предделители или делители сигнала тактирования. Делители бывают 8, 16, ,,,1024 в зависимости от типа контроллера.
Теперь рассмотрим задачу. Пусть нам нужно отсчитывать период 10мс на 16-битном таймере. Изначально таймер переполняется за 4мс или 244раза в секунду, это слишком быстро, нам нужно 100раз за секунду. Устанавливаем предделитель 8. Теперь таймер переполняется около 31 раз/сек. Этого нам мало. Нам надо в 3 раза быстрее. Вспоминаем, что таймер считает от 0 до 65535. У таймера есть счётный регистр. А если мы заставим таймер считать не 65536 чисел, а допустим только треть их, тогда мы получим нужные нам 100 переполнений за секунду. Как это сделать? А просто. В прерывании по переполнению мы записываем в счётный регистр число 65535*2/3 = 43690. Тогда таймер будет считать от 43690 до 65535 и переполнятся 100 раз в секунду, т.е нужные нам 10мс период.
Вот как-то так. Здесь расчёты естественно приблизительные. По хорошему нужно считать по тактам, но суть одна - с таймерами не всё так просто и код с использованием таймера в любом случае больше чем по прерыванию от детектора нуля.
Поэтому относительно вот этого

Запомните, таймер не считает ВРЕМЯ, таймер считает импульсы от тактового генератора, не более того. Время считается программно. Поясню на примере millis в упрощённом виде, в реальности всё немного сложнее.
Millis у нас считается в прерывании таймера настроенного на период 1мс. Т.е при переполнении таймера мы попадаем в прерывание по переполнению и выполняется команда millis=millis+1; далее перегружается таймер и всё повторяется снова и снова.Таким образом в millis мы имеем время в миллисекундах прошедшее с момента старта контроллера. Всё бы хорошо, если бы не другие прерывания, допустим от таймера2 или таймера1 или от детектора нуля. Дело в том что при попадании в другое прерывание таймер millis продолжает считать и переполнятся, но он не может попасть в своё прерывание по переполнению и выполнить команду millis=millis+1 для увеличения времени, потому что невозможно вызвать прерывание из прерывания. Конечно, после выхода из текущего прерывания мы попадём в прерывание таймера millis, но это уже произойдёт с задержкой и время отстанет на эту задержку. И так будет происходить постоянно, постоянно будет расти задержка.
Для проверки попробуйте написать простые часы на millis и моргание светодиода на таймере. Через некоторое время вы заметите, что часы отстанут. А если вы напишите часы с тактированием от детектора нуля они как танк идти будут(все равно конечно "уплывут" за счёт плавания частоты, но медленней чем на millis). С таймерами всё.

Это не для пяти профилей, а для пяти шагов в профилях.
Этот код работать не будет, ладно будет но с глюками. История такая. Я правил графику, что-то убирал, что-то перемещал. И в один прекрасный момент перестали читаться из EEPROM параметры 3-го шага профиля, причём во всех профилях. Не записать, не прочитать. Если выставить вручную с клавиатуры то работает до выключения или до смены профиля. Почти неделю искал в чём дело. Оказалось дело в циклах for.
У вас написано вот так

Код (C++):

for (int i = 0; i < 5; i + 1)

Компилятору это не нравиться и в один прекрасный момент он добавляет в цикл строчку

Код (C++):

i++;

Все, финиш. Цикл работает не правильно.
Надо писать так

Код (C++):

for (int i = 0; i < 5; i ++)

А ваш код можно немного оптимизировать и переписать так

Код (C++):

  profileSteps = EEPROM.read((currentProfile - 1) * 27);                       //adress   0              27                54                81               108
  Setpoint2 =   EEPROM.read((currentProfile - 1) * 27 + 1);                   //adress   1              28                55                82               109
  for (byte i = 0; i < 5; i++)
  {
    rampRateStep[i] =    EEPROM.read((currentProfile - 1) * 27 + i + 2);               //adress   2,3,4,5,6      29,30,31,32,33    56,57,58,59,60    83,84,85,86,87   110,111,112,113,114
    dwellTimerStep[i] =  EEPROM.read((currentProfile - 1) * 27 + i + 7) * 7;           //adress   7,8,9,10,11    34,35,36,37,38    61,62,63,64,65    88,89,90,91,92   115,116,117,118,119
    temperatureStep[i] = EEPROM.read((currentProfile - 1) * 27 + i + 12);              //adress   12,13,14,15,16    39,40,41,42,43    66,67,68,69,70   93,94,95,96,97   120,121,122,123,124
    min_pwr_TOPStep[i] = EEPROM.read((currentProfile - 1) * 27 + i + 17);             //adress   17,18,19,20,21    44,45,46,47,48    71,72,73,74,75   98,99,100,101,102   125,126,127,128,129
    max_pwr_TOPStep[i] = EEPROM.read((currentProfile - 1) * 27 + i + 22);             //adress   22,23,24,25,26    49,50,51,52,53    76,77,78,79,80   103,104,105,106,107   130,131,132,133,134
  }
  kp1 =                  EEPROM.read((currentProfile - 1) * 9 + 172);                 //adress    172              181                190             199                    208            
  ki1 =                  EEPROM.read((currentProfile - 1) * 9 + 173);                 //adress    173              182                191             200                    209
  kd1 =                  EEPROM.read((currentProfile - 1) * 9 + 174);                 //adress    174              183                192             201                    210
  kp2 =                  EEPROM.read((currentProfile - 1) * 9 + 175);                 //adress    175              184                193             202                    211
  ki2 =                  EEPROM.read((currentProfile - 1) * 9 + 176);                 //adress    176              185                194             203                    212
  kd2 =                  EEPROM.read((currentProfile - 1) * 9 + 177);                 //adress    177              186                195             204                    213
  tableSize =            EEPROM.read((currentProfile - 1) * 9 + 178);                 //adress    178              187                196             205                    214
  min_pwr_BOTTOM =       EEPROM.read((currentProfile - 1) * 9 + 179);                 //adress    179              188                197             206                    215
  max_pwr_BOTTOM =       EEPROM.read((currentProfile - 1) * 9 + 180);                 //adress    180              189                198             207                    216  

 

Исправьте еще строчку dwellTimerStep= EEPROM.read((currentProfile -1)*27+ i +7)*5; умножить не на 7 а на 5 в торопях правил и исправил и адрес и множитель. Еще советую запись в ЕЕPROM делать командой не EEPROM.write а EEPROM.update целей будет EEPROM. Например: EEPROM.update(((currentProfile - 1) * 29 + i + 7), dwellTimerStep / 5); Запись в ЕЕПРОМ будет происходить только тех значений которые были изменены.

 

Да, оговорился..
По поводу работы таймеров счетчиков все это мне известно, но мы тут не часы делаем и спутники не запускаем, с точки зрения теории автоматического управления мы имеем дело с очень медленными тепловыми процессами, и как я уже говорил, ловля микросекунд или даже нескольких десятков миллисекунд погоды тут не делает, особенно с выбранными алгоритмами примененными в скетче. Здесь нужна точная настройка ПИД регулятора и все... И эта настройка у каждого своя, т.к. теплоемкость примененных материалов, тип, мощность и расположение нагревателей у каждого свое, применяемые термопары разные по постоянной времени отклика и т.д. и т.п. Не говоря уже о разнообразии ПО и багах в нем. Точность поддержания заданных параметров напрямую зависит от обратной связи т.е. от точности измерения температуры, но сотые и тысячные градуса ловить нет необходимости. Имея цикл расчета ПИД регулятора 500мС +/-10-50мС с учетом не совершенства подсчета времени таймерами можно вполне адекватно управлять тепловыми процессами..

 

Да, но с этими тепловыми процессами нужно работать очень быстро. Немного замешкался и перелёт, а это смерть чипу.

На счёт миллисекунд это вы загнули, а что не так с алгоритмами?

Ну тогда расскажите, как заставить ПИД греть с заданной скоростью роста температуры. На сколько я знаю, у ПИД две основные задачи - максимально быстро нагреть до нужной температуры и удержать задание.

О багах поподробнее.

Вот, правильное слово. Да, точность зависит от обратной связи по температуре. И я вам скажу больше, она как раз зависит от тех сотых, которыми вы хотите пренебречь. Смотрите, задание 150, ПИД его удерживает. А вы думаете он за счёт целых градусов его держит? Нет, он держит за счёт сотых. Температура удерживается в диапазоне 150 +/- несколько десятков сотых и в режиме удержания эти сотые играют огромную роль.
Ещё точность зависит от точности отсчёта самого ПИДа. Вызовы вычислений должны происходить через полностью одинаковые промежутки времени, и чем больше точность этих промежутков, тем точнее рассчитывается выходное воздействие.

Ну вот мы и подошли к сути наших прений. Покажите народу адекватное управление тепловыми процессами. У меня, допустим, получается вот так:

А у вас?

 

Добрый день,народ поделитесь печатками силовой части станции на симисторе BTA 41 600

 

Добрый день ,ребята поделитесь печатками если не жалко?

 

Спасибо!!!!