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

Если посмотреть классическую схему ПИД регулятора

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

 

Так оно именно там и есть. Выход с ПИД платы регулирует Туст нагревателей. Нарисую схему минут через 30

 

Неправильно. выход ПИД это сигнал Y по картинке, а в нашем варианте это мощность нагрева в процентах.

 

Ребята! Уплыл мой вопрос про детектор нуля. Сильно не пинайте. В общем вопрос в том, что при проверке, в мониторинге Ардуино бегут цифры 49 и 50. А автор скетча проверки ДН, говорит, что там должно быть 9 и 10. Будет этот детектор работать или нет?

 

Должно быть 9 или 10, эти цифры соответствуют длине полупериода по времени в миллисекундах.

 

нашол глюк в версии 1.3.4 при выставлении температуры от 260 до 300(300 включительно) низ не включаеться от слова совсем ставиш 310 включает и ниже 250 тоже

 

Объект управления для ПИД платы - Температура ВИ и НИ
Объект управления для ПИД ВИ и НИ - мощность ВИ и НИ





Объект управления для ПИД платы - Температура ВИ и НИ -
эксперимент поясняющий это:
У нас одна и та-же плата, один и тот-же нижний нагреватель, делаем несколько тестов.
Ставим плату на уже НИ. Начальная температура платы всегда 20 градусов.

1. Температура НИ 100 градусов. Плата нагревается до 70 за 5 минут.
2. Температура НИ 200 градусов. Плата нагревается до 150 за 5 минут.
3. Температура НИ 300 градусов. Плата нагревается до 230 за 5 минут.
После 5 минут температура на плате стабильна. Возможно время нагрева платы будет отличаться, но это не критично. нам важен факт -> Чем сильнее нагрет НИ - тем быстрее греется плата.

Соответственно мы заранее экспериментально построили графики нагрева для ВИ и НИ такие, которые нашу стандартную плату всегда проводят по Термопрофилю. От ПИД платы не требуется полностью управлять температурой Нагревателей. Он только вносит коррективы при отклонении температуры платы от её термопрофиля.

При смене платы на другую неизбежно появляются отклонения в нагреве. Тогда коррекция вносимая ПИД платы будет больше.

Экспериментально получить графики температур для ВИ и НИ просто - пишем Лог температур ВИ и НИ при выполнении профиля по любому алгоритму, который вас устраивает. После прогона корректируем там где температура плату недогревало \ перегревало.

Зачем тогда прикручивать третью термопару, если есть алгоритм, который и по 2м профиль выполнит?
График температур позволит вручную внести корректировки на инерционность нагревателей. Уменьшить влияние на управление фактора "теплоемкость платы" при смене платы.

 

Хорошо, а если вам нужно нагреть до 150 со скоростью 1.5 градуса в секунду, какую температуру низа вы поставите?

 

Надеюсь у вас получится воплотить ваши мысли в скетче.
пысы: два предложения противоречащие друг другу.

 

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

Спойлер: График Синий - температура нагревателя, красный - платы

Проблемы с выражением мыслей присуствуют, согласен. Имелось ввиду что пид Верха не может изменять мощность ВИ и НИ от 0 до 100%, он вносит небольшую итоговую корректировку приблизительно от -10 до +10% мощности.

 

Небольшой эксперимент

 

Для низкоинерционных нагревателей профиль мощности вообще не нужен, а графики я бы поменял местами, так реальнее будет

 

Вопрос к @Dmitrysh по реализации ПИД

Код (C++):

byte Pid1(double temp, byte ust, byte kP, byte kI, byte kd)
{
        byte out = 0;
        static float ed = 0;
        e1 = (ust - temp); //ошибка регулирования
        p1 =  (kP * e1); //П составляющая
        integra = (integra < i_min) ? i_min : (integra > i_max) ? i_max : integra + (kI * e1)/1000.0; //И составляющая
        d1 = kd * (temp - ed); //Д составляющая
        ed = temp;
        out = (p1 + integra - d1 < profile.min_pwr_TOPStep[currentStep - 1]) ? profile.min_pwr_TOPStep[currentStep - 1] : (p1 + integra - d1 > profile.max_pwr_TOPStep[currentStep - 1]) ? profile.max_pwr_TOPStep[currentStep - 1] : p1 + integra - d1;
        return out;
}

Почему ed = temp; а не ed = e1 писали ранее: чтобы не было выброса мощности, при смене уставки, это я понял.
Но вот почему out = (p1 + integra - d1 ... ? (минус Д составляющая)

 

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

А чего вы здесь ждали? d1 это дифференциальная составляющая, которая компенсирует выброс выходного значения ПИД при скачке температуры. Входит со знаком минус, всё правильно, всё по теории.

 

Вот немного графиков с участием термопары К-типа и термосопротивления PT100.
Собственно РТ100:

РТ100 и термопара на одном графике(синяя линия термопара)

время считывания 250мс. Видим, что термопара заметно шумнее термосопротивления. Но это сравнение не совсем верное, ибо считывание термопары происходит на максимальной скорости а термосопротивления значительно медленнее его максимальной скорости. Поэтому следующий график сравнивает участников на максимальных их скоростях, а именно PT100 - 21мс, термопара - около 220мс.

вот сейчас видно реальную ситуацию. Теперь "подфильтруем" термопару

уже лучше, фильтр 0,75-0,25
Теперь нагреем немного

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

Обратите внимание, что термопара набрала большую температуру, чем РТ100. Это говорит о том, что теплоёмкость у термосопротивления значительно выше чем у термопары.
Также стоит отметить, что даже с патченной мной библиотекой, время получения температуры от РТ100 - 3мс, а от термопары около 250мкс.

 

У меня не совсем состыковалось. Т.е. время обновления показаний термопары - 220мс, но считывание 250мКс?

 

А нет возможности написать apk для планшета или телефона и не использовать дисплей Ардуино. Останется только 5 кнопок на корпусе станции и всё. Или это ни к чему? Просто мысли вслух

 

Это время за которое мах6675 делает преобразование напряжения с термопары в код.

Да, это время необходимое микроконтроллеру для чтения результата из мах6675 и преобразования полученного кода в температуру.

 

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

 

В чем медленность (куда торопимся? Сверхбыстродействие здесь ни к чему. Не та система). И в чем неэффективность? (Экономия в дисплее. Покупка только bluetooth модуля. Зато можно смотреть графики хоть на 5, хоть на 10 дюймах - у кого что под рукой. Ну и управление с планшета)