Самодельный контроллер для горелок на отработанном масле

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

По моему, Седой недавно проболтался. Видимо у тебя поплавок находится вблизи с ТЭНом, поэтому и плавится.

По поводу схем - Welcome - это ко мне.
Буду рад с Вами обсудить увиденные прогрехи, обменяться опытом, может покажите свои решения.

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

рассматривая схему, даже если отсутствуют контакты в различной комбинации на нагрузках или датчиках при работающем СPU, прога должна зделать соответствующее дейтсвие на непонятное событие (в прогу заложен анализ возможных событий). Другое дело - CPU здох - какая вероятность, при его скоропостижности, включения всех нагрузок и двигателя подкачки масла в том числе? Не знаю, на сколько мне известно, такой ситуации на сайтах о надежности AVR не встречалось. Напротив, огромные отклики о надежности кристалла. Я 2 года с ними, балдею, все глюки программы - это мои логические ошибки, когда их отслеживаешь, то понимаешь, что CPU сделал все правильно!

 

С добрым утром всех!
Тогда первое предложение по контроллеру.
Нога, управляющая опасным механизмом, например насосом подкачки, должна быть с обратным сигналом. Седой меня поймет. Так же и о входных сигналах особо важных датчиков.
В некоторых устройствах (управление насосами 500кВт) я управлял рэле по двум ногам: когда на одной "0", а на другой "1", тогда старт срабатывал. Это к примеру.

Поддерживаю. АВР рулит! В свое время начинал с ПИКов, а потом узнал об АВР. В результате ПИКи закинул. У АВР более развитая система прерываний, высокая производительность и много чего еще.

Еще совет. Часто случается сбой ЕЕПРОМ данных при пропадании питания. Устраняется выставлением супервизора внутреннего, например на 4.2в, если питание 5 в.

Хороша идея (не помню, Седого кажется) по разделению перифирии ввода/вывода (клава и экран) на отдельный МК (мега8). Поддерживаю такой вариант.

 

Да нет идея не моя. Мои идеи иногда встречаются с Калашом в руках. Но позже вооплощаются в жизнь. По современной схемотехнике : конечно шаги огромные. Но скажу всё ещё зависит от качества выполнения монтажа, паек. В своё время собирал с 10 Радио 86 РК . Всё ставил на панельках. Ни разу не было чтоб сбои по тех. стороне. В основном логические.

 

Вообщем, надежность весчь нужная. Надо испытывать на всех внештатных ситуациях модель.

А кто на комп данные выводил? Ну, например, дисплей в котельной, но ползти туда не хотца. Сидишь за компом, на форуме общаешься, а попуно посмотрел, что там (в кот) творится. И по какому интерфейсу?

 

Что-то я пропустил это, давай продолжим.

 

Верно-верно. Причём обратный связь должна идти от независимого датчика. Например, как проверить, что насос работает? Самый простой и недорогой способ - померить ток потребления. НО! Это не будет достоверным сигналом, что насос качает. Вот если в магистраль завести датчик расхода, и от него получать сигналы, то да - это есть самое правильное решение.
В управлении релюхой таким образом не вижу никакого смысла, так как программе всё равно, какие ноги дёргать. Можно хоть целыми портами шевелить, а толку - ноль. Единственное, где можно использовать такой способ коммутации - при сильных помехах, притом настолько сильных, что они могут наложиться на сигнал управления и врубить реле. Но это лечится правильной схемотехникой.

Есть такое. Поэтому правильные пацаны запитывают МК от батарейки, через диоды или hot-swap микрухи. МК обнаруживает пропажу питания, переходит в неактивный режим (гасит всю ненужную периферию) и доделывает то, что надо. А это факт пропажи питания записывает в лог.

Это имеет смысл делать, если основной узел и узел ввода/вывода - разные физические устройства и их можно отдалять на расстояние. В этом случае советую организовать на UARTе физический протокол RS-485. Лучше бы конечно смотрелся CAN, но его ни на 168-ой, ни на 8-ой мегах нет. Разве что внешний трансивер на SPI прикрутить.

 

сбой ЕЕПРОМ данных - запись данных в ЕЕПРОМ самая медленная и ранимая часть СPU. Внутренний супервизор исключительно для поддержки штанов (реализация RESET для CPU в приложениях не "злоупотреблявшых" записью в ЕЕПРОМ - иначе необходим внешний супервизор. Желательно с формированием RESET чере тайм-аут.

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

 

Тут делается хитро
Во первых ставится контроллер с буквой V. Они пашут от 1.8 вольт. На внутренний компаратор в одно плечо ставится опорное напряжение, например 3.3 вольт (батарейка), а второе на питание. Как только питание ниже опорника, прерывание, спасать всё что-можно и перевод в неактивный режим. АЦП для этого использовать нельзя, оно медленное по сравнению с компаратором.
А внутренний ресет выставить на напругу 1.8 вольт.

А что пробовать. Я так делал И многие так делают. Я почему про CAN заикнулся? Потому что с ним самое-то делать такие вещи. Он мультимастерный.

Хорошие идеи всегда приятно поддерживать.

 

Данные на комп выводить и управлять горелкой в целом через любой канал ввода вывода, хоть через PC/2, не проблема. Думаю, важно, выбрать какой именно интерфейс подойдет. Считаю, присвоить IP-адрес, самое гуманное на сегодняшний день. Доступ из любого места с любог inet-устройства. Все остальное, часный случай для конкретного компа.

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

 

У каждого своя вера
На INT0 вешают сигнал от внешнего супервизора. А борода - это когда много внешних регистров, операционников, ЦАП и АЦП

 

Немного в вере безопасности: ставим проц(голова) - за всем следит/управляет, по бокам ставим еще три независтимых(контролирующих), общение между ними уникальным словом. Любой из них обнаруживает отсутствие звена - отрубаем горелку (вариант для замороченных). Не зря у секретных дверей есть несколько ключей, находящиеся у разных людей и собирает всех по команде. А еще в народе говорят: "На молоке обожжешься, потом на воду дуешь".


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


СУПЕРВИЗОРЫ УЖЕ ТОРЧАТ там где надо и волшебным образом обработаны всеми прерываниями.

 

Супервизор встроеный не плохой. Батт обязательно и с детектором отсутствия питания, т.к. супервизор не спасет еепром, если в момент записи он сработал. Но! Даже без записи без супервизора внутреннего, но с наличием в коде команд записи еепром, последняя всё же сбивалась. Есть такая глючность.

По поводу протокола. Предлагаю использовать 485-й. Промышленный стандарт, надежный. А поверх Модбус РТУ. В случае появления каких-либо (в будущем) устройств с таким же стандартом (мировой, дефакто) легко будет их подключить.


Стараюсь всю удаленную перефирию делать с таким протоколом (модбус-рту).

 

Кто- то спрашивал о корпусах? Вот они наши корпуса под контроллеры.

 

Расскажу тогда одну историю. Делали девайс для военных. Кажется систему управления двига вертолёта или систему наведения. Не помню уже. Делали на ПЛИСках. В общем корпус, в корпусе общая шина, на шине сидят несколько плат, на каждой плате несколько ПЛИСин. Так вот, этот блок должен был работать при 50% повреждений. Во время испытаний по блок тупо дали очередь из калаша. Блок остался работоспособным, хотя часть микрух разлетелась, часть плат закоротилась, но блок остался работоспособный. Такая вот страшилка про надёжность

 

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