"Народный контроллер" для теплового насоса

РЕКЛАМА НА ФОРУМХАУС

@Elprog, есть несколько способов управлять перегревом, для этого надо знать температуру выхлопа, температуру до и после испарителя и при наличии РТО до РТО.
ЭРВ должен поддерживать перегрев (уставку) т. е. кипение + уставка = всас. Но в тоже время температура выхлопа не должна превышать критическую величину, а также в РТО не должен кипеть фреон, там полезный перегрев получается...

 

Ок, это уже что-то. Попробую перевести.
Имеем на входе T1, T2 - температуры на входе и выходе испарителя.
Если эти температуры, находятся в заданном диапазоне (каком?) и их разность не более, чем T3 (константа перегрева), то включаем компрессор на максимальную мощность. (правильно?).
Если температура T4 (обратки?) меньше заданной T5 (целевая), не больше, чем на T6 (дельта гистерезиса), то начинаем снижать мощность компрессора.
(по мне так примерно это называется разработкой алгоритма. После того, как алгоритм выстроен, определены границы допустимых значений, необходимые временные интервалы, понятны точки выявления ошибок системы, - можно начинать собственно кодирование, превращение этого алгоритма в строчки кода на любом, удобном языке и любом подходящем железе).

 

Я конечно нестроен решительно но хочу реализовать минимальную гибкость. По этому я думаю будет и старт-стоп (реле) и частотник (выход ЦАП). ЭРВ у меня кажись есть, по этому он будет. По тому что после блока дальние планы управление компрессором (но у меня сложно 3кВт одна фаза), возможно замена компрессора. Более того у меня вообще не стандартная ситуация у меня еще теплоаккумлятор есть на ТП 300 литров - нужно еще один датчик ставить. Так что гибкость будет.

Я пока не увидел законченного списка датчиков и исполнительных устройств. Перекрепляю таблички для заполнения.
Параллельно я занимаюсь подбором железа.

Это приимущесто дуе по сравнению с мегой но зато у меги есть флеш данных а у дуе нет (сохранение настроек)

Специально вчера вечером не лазил на форум не отвлекался и смотрел железо. Что нарыл:
1. stm32 есть возможность (есть библиотека для ардуино) для отведения части флеша программы под данные (настройки). Под это есть даже рекомендации производителя, т. е все штатно.
2. Что не говори но 120 кбайт памяти на 32 разрядах это мало. Вчера еще раз перекомпилировал простой примерчик дисплей (одна страница) веб сервер (одна страница) + работа nrf24 (радиоканал нам пока не надо но это 4-5 кб кода не более) так вот это весит 74 кб из 120 доступных. Уже вижу проблему. Я понимаю что все библиотеки уже подлинкованы но еще нужно sd карту прикрутить. мало остается на алгоритмы работы. Т. е. скорее всего минималка влезет но в притык.
3. Народ работает - вышло обновление sdk для ардуино на stm32. Поиграл с примерами на дисплей spi - скорость впечатляет (прикрутили доступ через ДМА). Скорость это свободное время на обработку основного алгоритма.
4. В дальнейшем надо обязательно Blynk прикруить - управление с андройд без белого IP.
5. Нашел очень интересный дисплей - Nextion (http://wiki.iteadstudio.com/Nextion_HMI_Solution). Думаю об его использовании. Это целая линейка дисплеев (разные диагонали и разрешение). На компе рисуешь экран (есть по типа визуального конструктора). Экранов может быть несколько (реализация простейшей логики и обработки событий). На экране могут быть разные примитивы (кнопки, ползунки картинки и т.). Компилишь в программе проект и запихиваешь в дисплей (через СД карту). Дисплей цепляется по ПОСЛЕДОВАТЕЛЬНОМУ порту к контроллеру и шлет коды нажатых кнопок, а контроллер шлет данные которые надо выводить в поля.
Решение дороже например 4.3 дюйма стоит 3200 рублей.
Плюсы использования
1. Результат (качество меню и картинок) будет гораздо лучше чем писать на контроллере, наверное можно сравнить с профессиональными решениями.
2. Повышается скорость разработки.
3. Есть возможность параллельной разработки. Если в команде будет человек который рисует то он может самостоятельно вести эту тему и получить качественный результат. Надо будет только согласовать переменные и экраны.
4. Последовательный интерфейс обмена. Экономия устройств на SPI. Можно наверное дисплей вынести на 3-6 метров (надо пробовать). Последовательных интерфейсов на "больших" платах обычно много. Наверное можно прикрутить 485 конвертер тогда длина провода десятки метров легко (идея выносного управления). Наверное можно прикрутить пару на два порта с дублированием инфы.
5. Экономия места программ в контроллере. Как минимум минус шрифты это 5-15 кб кода и либа графики дисплея.
6. Достаточно новая разработка - середина 2015 года. Продукт развивается. Есть приличный форум, выходят обновления софта.
7. Вроде есть русификация.
8. Развитие идеи блочного устройства -)
9. Не надо заморачиваться с устройствами ввода.
Недостатки
1. Большая цена. Дисплей 2.8 дюйма на ili9341 стоит 400-рублей такой же Nextion 1500 рублей. Для меня разница не принципиальна.
2. Не понятен жизненный цикл изделия и можно его будет купить через год (по хорошему один надо в зип покупать).
3. Используется мой не любимый резистивный точь экран. Надежность сомнительна.
4. Используется дешевая матрица - малые углы обзора.

Сейчас вот сижу и думаю что использовать. Как говорил мой научный руководитель "Вещь должна полежать"
Жду заполнение табличек

 

Я бы рад обсудить зависимости и причинно-следственные связи...
Только не вижу, принципиального согласия начать с базовых функций.
ЭРВ, к примеру, хватает лишь двух датчиков в испарителе...

 

Действительно, какая разница, ТРВ или ЭРВ железо, холодит и тот и другой...
Кончайте эту затею, все равно ничего толкового в колхозно-демократическом варианте не получится...

 

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

 

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

 

Не "вставила" логика табличек.
Может пойти по пути конфигурации конкретной конструкции ТН: переливная схема, ДХ испаритель, старт-стоп?

 

А ШИМ плюс маленький конденсатор поставить - религия не позволяет!

 

@Elprog, объясню на пальцах.
1. Что такое перегрев - читать здесь
2. Есть два варианта вычислить перегрев - по двум датчикам температуры на входе и выходе испарителя или по датчику температуры и датчику давления на выходе. Первый вариант убогий, второй дорогой.
3. ЭРВ представляет собой шаговый мотор, управляющий количеством хладогента, подаваемого в испаритель. Про механический ТРВ читать здесь, работа электронного не отличается.
4. Ваш алгоритм должен реализовать ПИД (ПИ) регулятор положения рабочей точки ЭРВ от значения перегрева.

 

Так там и есть конфиг 1 конфиг 2 и т. д. а после таблички предлагается написать словами что за конфигурация.
Сразу будет видно общие датчики и обязательные датчики во всех конструкциях.
Таблица показывает РАСХОЖДЕНИЯ по разным конструкциям ТН (конфигурациям)

 

@Pav2000,
Три простейшие конфигурации.
Их можно расширять и модифицировать бесконечно.

 

дак он это и пишет... может так?
1конф: стартстоп+шаговый ЭРВ (автора так)
2конф: инвертор+ЭРВ
3конф: инвертор+капиллярка
4конф: +РТО
5конф: +ГВС

 

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

 

1конф: стартстоп+шаговый ЭРВ (автора так)+ГВС
2конф: инвертор+ЭРВ+ГВС
3конф: инвертор+капиллярка+ГВС
4конф: +РТО+ГВС

ГВС должно быть везде как функция (работает/не работает) и если его нет то ставим что не работает.

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