Конечно, там много нюансов…
Но вот вчера я отписался по факту:
Проработала система примерно 3,5 часа. При этом я прогрел воздух в нужной комнате до заданного значения (+21,5 град. С). Соответственно - запулил в комнату 3,5 * 3,69=12,9 кВт тепла. Электричества потратил 3,5 * 1,13=4 кВт * ч.
Если бы не работал этот тепловой насос у меня - то я бы соответственно потратил бы 12,9 кВт*ч электричества на прогрев комнаты (у меня - электрическими ТЭНами греется, если без этого теплового насоса). Вот и разница за вчера 12,9-4=8,9 кВт * ч. Примерно по 6 руб за кВт * ч. То есть за счёт того, что погонял тепловой насос вместо штатных ТЭН-ов, сэкономил 6 * 8,9=53 руб. А обогреваться сжигая дизельное топливо - ещё дороже, нежели электро ТЭНами греться.
Оно, конечно, того возможно не стоит - 53 руб. Сколько я уже потратил на всякое оборудование, материалы… сколько времени потратил на Ардуину… наверное, что не заставляет тупо плюнуть и бросить всё это - интерес, приятные эмоции, когда удаётся сделать так, чтобы оно работало.
Прошу прощения за создание новой темы, но в старой мне вывалилось такое сообщение:
Про ТН я знаю очень давно. Дело не в этом. Здесь не то место, чтобы такие вещи строить. Можно и ветряк поставить и солнечную батарею и прочее… Но - соседи пожалуются и скажут, что ты “еретик” или агент сша или шпиен и пипец. Я давно занимался спутниковым телевидением и были у меня тарелки на крыше - соседи пальцем тыкали - это от него помехи и телевизоры ломаются!!! Шайтан карачун. )))
Почитал чуть-чуть про WDT - я так понял, там назначение - сделать reset, когда “завис” контроллер. Как им отследить причину зависания - с наскока не понял.
Это - вроде, чуть понятнее. Понимаю, что могу назначить каждой функции некий “флаг” true/false (1/0). Понимаю - что могу считать количество - типа, сколько раз успешно процедура дошла до конца и на каком разе был “ноль” - но опять же - где гарантия что именно момент “нуля” по данной процедуре замрёт на экране?
Ну и счётчик - понятно. Типа, на 10258-ой раз прохождения процедуры, наступил “капут”. Как выделить местечко на экране для того чтобы вывести название процедуры и например, после какого количества её прохождения наступил “капут” - представляю.
Но - у меня сомнение, что дисплей зафиксирует и замрёт именно с отображением процедуры, в которой пришло “false”.
Но если я всё корректно уяснил - то попробовать можно…
Есть ноутбук. Могу его оставить рядом.
Это что - я проводом подключаюсь от МК к USB ноутбука и постоянно транслирую через “Serial.println”?
Ну, показания (с датчиков температуры) - я умудрюсь таким макаром передавать. А что ещё (какие именно параметры) туда передавать?
Не знаю, не вырубится ли ноут за это время. Он уходит в спящий режим, но вроде - должен при открытии крышки отобразить “серийный порт”.
Можно попробовать. Посмотреть, что последнее прилетит перед глюком. Важно понимать - что именно транслировать в этот порт. Чтобы с вашей помощью позже - понять, где что крутить в скетче.
Нет. Это не так. Какой смысл ресетить контроллер постоянно? Там все несколько иначе. Ну вот нажал ты на кнопку ресет или питание скакануло или глюк какой. В любом avr можно узнать как ты стартанул. Тут есть два пути - первый и классический = не успел сбросить WDT → сбросился проц. Второй сложнее - сделать типа супервайзера, который следит за выполнением функций по алгоритму. Например - у кого “подушка” - тот и разговаривает. Надеюсь понял. Тебе бы гденить подсмотреть все это. Там не сложно, нужно только понимание.
Ты пытаешься использовать дисплей, как логгер, просто потому, что графики помещаются на экран и хранятся в памяти экрана.
Но лучше и гораздо информативнее вывести это всё в обычный текстовый лог, а экран свой подключать уже потом, когда разберешься с проблемами.
Сейчас ты просто запутаешься в задаче. Нужно же убрать все необязательное для работы контроллера твоей системы
значит в логе останутся данные перед этим. И значит нужно больше выводить в лог: “вошел в функцию” “вышел из функции”.
Ты, дорогой друг, пишешь, будто код не отлаживал.
Кроме того, на картинках у ТС его экран сохраняет графики за весь промежуток времени, включая сбой, что говорит нам о том, что МК не перезапускался.
То есть мы решаем не про “сферического коня в вакууме” и про конкретного конЫка - вот этого. И это не дохнет (в смысле не виснет)… а просто болеет. Значит нужно получить максимальное количество данных - кто, где и как дал неправильную темперетуру.
и отдельно про дурацкие тепловые насосы. Если автоматику сплит системы сильно не трахали, то там есть защита и от обмерзания и от превышения давления, так что само ничего не сломается. Если же все защиты сняты и компрессором и четырехходовым клапаном управляет Мега (я код не читал, уж простите мою лень), то… в принципе фреон не ядовит и стоит недорого! Да и компрессор, если не инвертор, тоже копейки…
Запустил скетч который вчера предложил BABOS. Сразу на работающее оборудование. Рискнул.
Единственное отличие, которое пока что заметил - подсветка некорректного значения расхода воды. У меня было так:
if (FlagWater == true)
tft.setTextColor(CYAN, MAGENTA); // Указываем цвет текста
else
tft.setTextColor(MAGENTA); // Указываем цвет текста
при этом - пока реальные данные не получены - цифры выводились CYAN на фоне MAGENTA.
А в откорректированном коде
tft.setTextColor(FlagWater ? CYAN : MAGENTA);
при этом - до получения корректного значения цифры выводятся просто CYAN, без подсветки MAGENTA.
Когда я попытался изменить код на
Самое главное - я вместо воздушного внутреннего блока прицепил водяной теплообменник.
Первое время - я присобачил штатную автоматику сплит-системы и тупо - наблюдал графики. Процессом - управляла штатная плата со штатными реле и со штатным алгоритмом.
Так вот: штатная автоматика с большой вероятностью могла повредить льдом мне теплообменник. Для воздушного внутреннего блока такие отрицательные температуры не страшны. Для теплообменника фреон/вода - страшны. Там были и другие причины, по которым штатная автоматика была для меня невыгодна. Например - оттайка раз в 40 минут. При любой погоде, независимо от температуры на улице. Продолжительная. Горячий воздух при этом тупо выбрасывался на улицу.
вам правильно советовали что не стоит так проверять на готовом, да и я думал вы тестить будите медленно на отладочной плате, и смотреть… хотя я и сам на ней не люблю собирать так, лучше если что сжечь и купить новое… время самый дорогой ресурс!)))
так что если че сгорит, это исключительно ваша инициатива))) а на ночь точно не оставляйте!)))
Если до отбоя не заглючит - оставлю на ночь. Иначе - как я вообще смогу выяснить заглючит/не заглючит.
Но я понимаю о чём идёт речь - нужно задумываться над тем, каким образом отследить причину сбоя. Наверное, легче всего оставить ноутбук и выводить в “серийный порт” или как там называется эта движущаяся лента. Главная проблема - понять, что именно выводить. Второй момент - мне кажется, что сами эти процессы “Serial.println” будут давать нагрузку на МК. Ну и вдобавок - вопрос, как ещё перенесёт ноутбук долгое включение. Будет ли, как положено, часами стоять и фиксировать и запоминать всё что приходит в “серийный порт”.
Пока что я себе лишь представляю, как соорудить что-то типа “вошёл в процедуру”, “вышел из процедуры”. Теоретически - я таким макаром смогу выяснить, в какой процедуре “споткнулся” МК. Может, это что-то даст для дальнейших размышлений…
Ну что ты ка ребенок рассуждаешь. Возьми листок бумаги, карандаш и нарисуй блок-схему своей программы. Пронумеруй входы и выходы процедур, в 255 (байт) думаю уложишся. И счетчики на процедуры 32бит=4миллиарда тебе хватит. Выше же писал, как делать.
Думаю. Не понимаю - какая мне разница, какой раз по счёту МК попал в ту процедуру, на которой споткнулся?
Как я понимаю на данный момент - важно лишь узнать, в какой именно процедуре я МК споткнулся.
Всё что выше - читал и не пропускаю.
Вот ещё думаю. Когда я пытался вывести в “сериал порт” значение каждую миллисекунду - то были пропуски. У меня в коде есть отсылка на процедуру в “loop”. МК лазает в эту процедуру очень часто и очень быстро. Успеет ли “сериал принт” зафиксировать сбой, если этот сбой произойдёт в такой процедуре?
Отработала штатно. Выдала останов по причине отсутствия света. Это хорошо. Но пришлось перезагрузить контроллер, чтобы снова ввести его в работу (автоматическое возобновление работы по появлению электричества - не предусмотрено).
Ещё “но”: прилетели какие-то залётные значения “G water”. Невероятно большие значения. Но это не страшные показатели, критического от них ничего не зависит. Тем не менее - тоже проблема, тоже надо будет решать (по-хорошему).
Пока, можно считать, что отработало 2,5 часа штатно (с оговорками).
больше всего это похоже - что чуть более 2-ух часов назад произошла перезагрузка микроконтроллера.
Признаться - в глубине души я надеялся, что загружу код, который предложил BABOS, и у меня чудесным образом всё наладится.
По факту же - я обратился на форум за помощью, считая что у меня присутствуют проблемы с датчиками температуры. После моего обращения, за прошедшие два дня произошло (как минимум) два сбоя. Причём - первый выглядел как “зависание”, второй - как перезагрузка. Останова по причине датчиков температуры за это время - не произошло.
Я понял - что большинство говорят о том, что в моей ситуации следует как-то организовать поиск того места в программном коде, где “спотыкается” МК.
Я читаю что советуют. Но не понимаю.
Единственное что пока сложилось по моему мнению - что процесс отладки (поиска места “спотыка”) мне легче всего попробовать организовать с помощью ноутбука и провода между ним и МК (IDE, монитор порта).
Но я не понимаю - что именно и каим образом выводить в этот монитор порта. Прошу, кто может, - разжевать на пальцах.
Все верно. Этому учат несколько лет, но, не всем это понятно даже после обучения.
Повторю еще раз = дуня - это игрушка для ДЕТЕЙ для изучения основ программирования!!!
Есть такой принцип программирования: = try exception. Это тогда, когда на любой “чих” или “спотыкание” у МК есть вариант обхода проблемы. На ардуине try exception сделать конечно можно, но проще все переписать на С или ++ .
Иными словами твоя программа должна “не впасть в ступор” даже если ты вырвешь экран с корнем, замкнешь или откусиш свои даччики, взорвешь петарду в теплообменнике или кучка тараконов насрет между ног XTAL - по№№уй должно все быть в твоей программе!!!
Вот когда вот так вот научишься программировать - уотт тагда уже можно пейсать кодЫ к таким девайсам. А пока советую научиться моргать светодиодами в разнобой. На меге ПЯТЬ таймеров === лепота!!!
Да и компрессор, если не инвертор, тоже копейки…
