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

хорошие и дружелюбные китайцы!!! пропаял под микроскопом контроллер и тотально все компоненты на плате ардуино и максы стали работать и проблемы с графикой ушли теперь цвета в норме

 

Странно, но в описании к лоту нет ни слова о том что этот дисплей имеет тачскрин. "KEYES 3.5 In. TFT L C D Shield for arduino"
Единственный намёк на это в технических характеристиках: "Touch Control Board" или в русскоязычном варианте "Сенсорный экран Управление доска"

 

Я ориентировался по изображению, на нем виден шлейф от тача. Описание вообще никакое.

 

всем привет ребята подскажите какая схема детектора ноля сейчас проверенная и рабочая?

 

спасибо времени совсем нет вот только начал заниматься станцией

 

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

 

Вы наверное к своему телефону 4 кнопки подключили. На тетрис хватит))

 

Очередная доработка нашего скетча.
Суть в следующем. При работе ПИДа с использованием рампы(а рампа у нас и сверху и снизу) возникает ситуация ,что при изменении значения рампы(т.е приращения температуры) происходит мгновенный выброс мощности на нагреватели. Это явление выглядит как моргание ламп с периодичностью пропорциональной скорости роста температуры. Такое поведение регулятора не есть хорошо. Watashi предлагал для решения этой проблемы передавать приращение температуры не за один раз а за 4, т.е дробление приращения. Это решение рабочее, но оно не убирает саму причину возникновения такой ситуации и требует некоторого увеличения кода, что в критической секции не очень хорошо. К тому же, чем менее инерционный нагреватель, тем на большее количество частей надо разбивать приращение(сами догадаетесь почему).
Я предлагаю для искоренения такого явления поменять логику работы ПИД. А именно работать не по конечному значению ошибки, а по измерению температуры. Такая логика не нова, но в наших скетчах ещё не использовалась, хотя в изначальной библиотеке она была, но у меня не заработала.
Суть заключается в том, что мы отвязываем компоненту D от уставки и привязываем её к изменению температуры, а именно, изначально у нас было D = kD*(текущая ошибка - предыдущая ошибка), а соответственно ошибка = (уставка - текущая температура). Отсюда видно, что D зависит от уставки.
Теперь же мы D считаем как D = kD*(текущая температура - предыдущая температура), т.е D уже не зависит от уставки и при её изменении выбросов мощности не будет или ини будут гораздо меньше, потому как будут компенсироваться D-компонентой, зависящей только от температуры.
С теорией всё или около того.
Ещё добавил в скетч инициализацию некоторого "стандартного", а правильней сказать предустановленного профиля. При удержании cancel в течении 5 сек в режиме IDLE, текущий профиль перезаписывается на предустановленный. Это будет полезно тем, кто только собрал станцию или заменил контроллер, а EEPROM у него пустой, т.е все значения 255. Параметры этого предустановленного профиля можно заменить в скетче, они там идут в той последовательности как и в структуре профиля.

 

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

Что касается моргания ламп, у меня есть своя теория. Я думаю что в этом виноват несовершенный механизм обработки прерывания, например:

Код (C++):

void OutPWR_TOP(){
       reg1 = Output1 + er1; //pwr- задание выходной мощности в %,в текущем шаге профиля, er- ошибка округления
        if (reg1 < 50){
          out1 = LOW;
          er1 = reg1; // reg- переменная для расчетов
          }
        else {
          out1 = HIGH;
          er1 = reg1-100;
        }
       digitalWrite(RelayPin1,out1);//пин через который осуществляется дискретное управление
       }
 

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

 

Поздравляю! Идея предустановленного профиля приживается! ))

Остались технические мелочи:
- почему только один профиль? и данные нужно выкидывать в "верхнюю" память и не хранить в озу
- в подпрограмме SaveProfile() используется EEPROM.put , а надо бы EEPROM.update

 

Это не совсем так. Смотрите. Да, температуру мы получаем 4 раза за секунду, но и ПИД пересчитывает мощность на нагреватели тоже 4 раза за секунду и этот процесс не зависит от параметра скорости роста температуры. От скорости роста температуры зависит, через какое время на рампе увеличится значение, т.е, например, при скорости роста температуры 0,5 на рампе значение увеличивается каждые 2 секунды на 1 градус.

Это и есть один и тот же процесс, одно измерение температуры -> один пересчёт ПИД. Может вы что-то другое хотели сказать, да я не понял?

Я в двух словах объясню, как это работает. Тот код, что вы привели, это реализация алгоритма Брезенхема по равномерному распределению импульсов по периоду. В нашем случае период равен 100 полуволнам сетевого напряжения, что при 50Гц в сети равно 1 секунде. Такой период для нас удобный, потому как 1% мощности соответствует 1 полупериоду сетевого напряжения и регулируя количество переданных в нагреватель полупериодов мы регулируем мощность. Алгоритм Брезенхема позволяет равномерно распределить импульсы управления силовыми элементами по периоду, для того, чтобы не было ощутимых "провалов" в подаче энергии на нагреватель. Например, нам нужно включить нагреватель на 35%, это значит, что мы должны 35 полупериодов на нагреватель подать, а 65 полупериодов пропустить. На очень инерционных нагревателя можно делать и так, но на менее инерционных нагревателях проявляется эффект остывания нагревателя в периоды простоя, что негативно сказывается на качестве нагрева, а в случае галогенок или ламп ещё и заметно "на глаз" значительное мерцание на низкой частоте. Алгоритм Брезенхема позволяет распределить подачу энергии на нагреватель по всему периоду равномерно, т.е импульсы управления перемежаются со временем когда их нет. В интернете есть описание этого алгоритма с картинками. Работа алгоритма Брезенхема чем-то похожа на импульсно-кодовую модуляцию, скважность здесь не меняется, меняется количество импульсов в периоде.
Вы говорите о периоде включения и выключения нагревателей в 1 сек, но это не так. Хоть алгоритм Брезенхема и рассчитан на период в 1 секунду, он пересчитывает выдаваемую последовательность 4 раза в секунду.

Изменить период, конечно, можно, но его можно только увеличить. Объясню. Допустим мы хотим уменьшить период распределения до 250мс(сравнять его со временем расчёта ПИД и замеров температуры). Тогда у нас получается 25 полупериодов на 100% мощности, т.е 0,25 полупериода на 1%. Но мы не можем открыть SSR на 0,25 полупериода, потому как SSR открывается только на целое число полупериодов. Поэтому у нас получатся мощности кратные 4%, т.е мы терям в "разрешении" по мощности, а ошибки скажутся на качестве регулирования. Можно повысить точность регулирования только методом фазового управления, я такой скетч выкладывал, даже в двух вариантах.

А прерывание причём? У нас всё нормально в нём. Там только самое необходимое, и ничего лишнего.

А почему нет? По времени мы укладываемся. Я раньше объяснял, что в прерывании у нас около 500мкс, связь с компом занимает около сотни микросекунд, остальное - управление нагревателями и ещё остаётся время немножко "поиграть на баяне". Дело в том, что для работы программы на компе нам желательно иметь точные периоды передачи данных. Это нужно для синхронизации графиков по времени и в дальнейшем для некоторых дополнительных функций. Конструкция millis() не предоставляет достаточной точности в отсчёте времени, об этом я тоже раньше писал.

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

Я думал об этом, но здесь есть свой "прикол". EEPROM.update не переваривает структуры, она тип byte хочет, а это цикл побайтная передача и тд. А потом я в документации на EEPROM.put наткнулся на такую строчку:

Код (C++):

Note
This function uses EEPROM.update() to perform the write, so does not rewrites the value if it didn't change.

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

 

Вы правы в части того что ПИД вызывается 4 раза в сек, но изменение "целевой" температуры происходит, как в вашем примере раз в 2 сек, что по сути провоцирует волнообразный рост температуры (это больше касается мало инерционных нагревателей). Я имел ввиду процесс формирования "целевой" температуры совместить с измерением текущей температуры, т.е. 4 раза в сек.

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

Можно сказать повезло )))

 

всем привет подскажите кто то пробовал в детекторе ноля по входу 220 вольт сопротивление резисторов с 47 ком ставить до 51 ком?

 

90% всех схем не теряют работоспособность при изменении номиналов в диапазоне +-10%

 

Такой вопрос поступил в личку. Это, я бы назвал коммутационная плата, чтобы не подпаиваться к Меге. Я только разьемы с длинными ножками перепаял на Мегу, иначе эта платка была между Мегой и дисплеем и как туда подлезать с проводами?
покупал тут

 

Вот это интерфейс!!! Это ж сколько труда!
Чтобы запустить с одним энкодером, чуть доработал - было как бы нажата ButUp()

 

Я рад что вам понравилась программка.

По поводу доработок. У меня в планах есть пунктик сделать настройки по выбору: энкодер, клавиатура или сенсор. Не бойтесь предлагать какие то свои идеи(можно в личку), лучше сначала обсудить, а потом делать, все равно будет какая то новая версия и ваши усилия пропадут зря.

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

 

Я раннюю версию переписывал под UNO + енкодер, было много повторяющегося кода.
В основном по обработке кнопок.
Вынес кнопки и др. в отдельные файлы.
И модуль опроса кнопок и/или энкодера возвращал значение нажатой кнопки - true.
Неплохо было бы так сделать.
Как пример :

 

Я посмотрел вашу программу под UNO. У нее одни корни с программой от Dmitrishа. Главный недостаток - линейный сценарий. В моей программе другая логика построения программы.

Для начала, чтобы код программы выглядел читабельно нужно сделать следующее: В настройках Arduino IDE нужно активировать пункт "Включить сворачивание кода", тогда после загрузки скетча кликнув правой кнопкой мыши по тексту получаем менюшку в ней пункт "Сворачивание" далее "Свернуть все блоки" и смотрим код. Появятся в начале строки + или - в квадратике, кликая по которым можно сворачивать или разворачивать код.

Теперь пример обработки кнопки энкодера:
1. опрос кнопки

Код (C++):

  Btn_ok.run(&press_ok, &longPress_ok);

2. подпрограммы обработки нажатия


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