для малого превышения температуры заслонка открывается с определенной периодичностью, а для истинно аварийной ситуации (при значительном превышении заданной температуры) заслонка открыта постоянно.
Вот этот вариант имеет право на жизнь.Я где то на китайском сайте читал,что у них(китайских инков) заслонки постоянно закрыты и по какому то алгоритму(не стал вникать)открываются на определенное время для обмена воздухом.Лично я себе не стал никаких приводов и эл.магнитов городить,вручную регулирую(на глаз,опыт есть,обслуживаю 3 инкубатория с "Универсал 45" и "ИСУ 12" у местных фермеров).
Все упомянутое очень часто применяется в примышленных инкубаторах по одной простой причине, сгорают электромагниты и их не очень то легко можно найти, поэтому и отслеживают в ручном режиме. На основе этих сведений можно с уверенностью проработать 2 варианта заслонок: 1) электромагнит с ограничителем приоткрывния (это самый простой и дешевый вариант с достаточной функциональностью) и 2) Шаговый двигатель с датчиком нулевого положения (более сложный вариант, но зато удовлетворяет практически любой каприз).Остальные варианты я пока откладываю в сторону из-за более сложного решения и более экзотической комплектации. Далее народ уже сам выберет нужный вариант под свою конструкцию инкубатора.
В сообщениях повыше Дмитрий высказал опасение что у шагового двигателя не запоминается текущее положение при перезапуске микроконтроллера, против таких ситуаций есть довольно эффективный способ который позволяет его преодолеть. Вся суть заключается в следующем: в неопределенной ситуации двигатель переводится в режим закрытия заслонки и подсчитываются число шагов до срабатывания датчика нулевого положения, далее двигатель переводится в режим открывания и задают движение на число шагов определенных при движении на закрытие. В таком случае заслонка лишний раз дернентся туда-обратно, но зато отслеживается правильное текущее положение, такой прием пригоден даже для промышленного приложения. Такие вещи я экспериментировал еще в далеком 2003 году и у меня это работало, только в моей системе я использовал 2 датчика положения заслонки, один на поз. "полностью закрыт" и второй на поз. "полностью открыт", в качестве шаговиков применял ПМГ-42 и ДШИ-200-1
На основе данных из постов повыше я набросал свою версию схемы (она отличается от версий Дмитрия), где учел все эти пожелания, правда допустил и некоторое излишество, это микросхемы RTC и EEPROM с учетом сервиса на перспективу, интерфейс связи с компьютером пока оставил в виде черного ящика и желающий поставит свой вариант связи под нужную задачу (связь может быть двунаправленной). На всякий случай предусмотрел возможность расширения функций путем подключения дополнительной 74НС595, в основном для управления шаговым двигателем (это добавлю по заявкам трудящихся).
Всем Привет
Товарищи, я думаю что это уже излишества нехорошие , если для аварийного охлаждения нужна автоматизация заслонки, то в схеме есть выход аварийного вентилятора-от него можно и запитать привод заслонки, если же заслонка нужна для увеличения воздухообмена(для уменьшения уровня углекислого газа в инкубаторе) то мне кажется что проще сделать отдельный автомат для постепенного (на продолжении 21 дня для кур например )приоткрытия заслонки
каждый день или раз в неделю , интервал времени можно выбрать любой. Конечно это мое личное мнение, у меня схема на МЕГЕ 168 и СХТ 10 отработала на отлично с мая и до августа, у меня стоят пенопластовые легкие заслонки,при аварийном охлаждении(когда жара на дворе а в инкубаторе лежат гусиные яйца) кулер включился погнал воздух -заслонка приоткрылась, перестал дуть кулер -заслонка под своим весом -закрылась, вот и вся автоматизация заслонки.
Единственное что мне кажется можно подкорректировать в проге так это циркуляцию воздуха внутри инкубатора, кулер внутри молотит воздух пока не сравняет верх и нижн температуры один к одному, в больших инкубаторах это
сделать очень тяжело, я думаю что можно сделать какую то дельту например 1-2 градуса до верхней температуры(более горячего датчика) с шагом регулировки 0.1град , то есть подгонять холодный датчик к горячему с учетом дельты,
например :если дельта допустим 0.1градус , температура горячего датчика равна 38градусов, то кулер внутри инкубатора должен молотить воздух пока на более холодном датчике не будет 37.9 град. (дельту можно выбирать любую от 0.1 до 1-2град например с шагом 0.1градуса) .Не забывайте , чем проще схема , тем надежнее она работает.
Повторюсь это мое личное мнение.
Не думаю что это излишества, просто это штатный перечень типового инкубатора (температура, влажность, заслонка, поворот и охлаждение). Просто ради дешевизны и простоты часть из этих функций для мелких инкубаторов просто перекладывают на пользователя (или грубо говоря безцеремонно выбрасывают). И про разность температур в камере, основная причина кроется в недостаточной интенсивности конвекции воздуха в камере и некоторых недоработках самой конструкции камеры инкубатора, к сожалению нет единой методики проектирования и расчета камеры инкубатора, каждый делает по своему, причем здесь можно спорить до посинения и конца этому не будет. Если maks067 заметил что это излишество, то в качестве альтернативы могу представить до предела урезанную схему (она выполнена на другом, более древнем микроконтроллере семейства х51), но зато отслеживает температуру, влажность, заслонку и поворот с должным сервисом по индикации. Как еще один вариант привожу урезанную версию схемы которую приводил в предыдущем посте, эта уже на ATmega8/168 и она держит весь набор:температура, влажность, заслонка, поворот и тревога/охлаждение. После этого уже есть что посмотреть, прощупать и оценить (правда пока без программы) для начала по железу.
Serge, ну так пожалуйста предоставьте свою "УРЕЗАННУЮ ВЕРСИЮ"только с программой(без программы железо это только железо и не более),так как Вы пишите- "но зато отслеживает температуру, влажность, заслонку и поворот с должным сервисом по индикации." , а народ протестирует в реальных условиях, "прощупает и оценит", все равно я считаю что Ваша урезанная версия температуру в инкубаторе точнее чем схема Дмитрия на СНТ10 держать не будет, была бы она такой хорошей Вы бы не пытались сотворить что то другое (разве что ради спортивного интереса).Приведу пример, мой товарищ и конкурент по совместительству приобрел блок автоматики (не буду говорить какой дабы не рекламировать) навороченный на Универсал55 , после года эксплуатации он просил уже что бы я ему спаял блок Дмитрия (точность поддержания температуры оставляет желать лучшего,программа за время инкубации дала один сбой зависла так сказать, очень много всяких коэффициентов надо вводить-это его очень напрягает).У меня точность поддержания получилась 0.1 гр. на графике идут просто прямые линии, летом когда на улице начинается жара до 38град. срабатывает аварийка, вот тогда немного идут скачки температуры по графикам.В будущем хочу установить в инкубатории кондиционер .
Ну а на счет недостаточной интенсивности конвекции воздуха в камере , я хорошо знаком и хочу разность температур
датчиков догнать до 0.2градусов с помощью установки дополнительных вентиляторов в камерах , правда не знаю получится такой результат или нет буду пробовать...
Еще добавлю по схемам что Вы выложили , для меня да я думаю и для многих вариант с ЖКИ индикатором не очень подходит, потому что в потемках его плохо видно(цыфири ну очень уж маленькие), а светодиоды видать из далека :)
да и дороже он на много семисегментника...
Я надеюсь что если будит управление заслонкой то для нее будет отдельная прошивка и отдельная плата для управлении заслонкой. При таком варианте можно будит каждому выбирать делать или не делать этот блок.
Serge, ну так пожалуйста предоставьте свою "УРЕЗАННУЮ ВЕРСИЮ"только с программой(без программы железо это только железо и не более),так как Вы пишите- "но зато отслеживает температуру, влажность, заслонку и поворот с должным сервисом по индикации." , а народ протестирует в реальных условиях, "прощупает и оценит", все равно я считаю что Ваша урезанная версия температуру в инкубаторе точнее чем схема Дмитрия на СНТ10 держать не будет, была бы она такой хорошей Вы бы не пытались сотворить что то другое (разве что ради спортивного интереса).
В какой-то мере вы правы, в основном приведенные мной примеры показывают как надо оптимизировать "железо" и выжать из него по максимуму из того что есть. Когда идет доводка железа то предпочитаю проработать по бумаге побольше вариантов, где потом из них было что выбрать, только после всего этого в работу запускаю только 1 схему, в крайнем случае 2, после всего этого у меня практически отсуствует доводка железа при наладке.
С программами разговор отдельный, я их пишу только после полной доводки схемы, только так можно получить оптимальный код программы (т.е. железо первично и программа вторично). Программы пока не могу предоставить, они еще крайне сырые и находятся в работе (у меня не принято выдавать на гора сырые программы).
На счет измерения более точней или менее точней, все упирается в алгоритм программы и точности вычислений при одних и тех же датчиках, так что вопрос довольно спорный и оставлю его открытым до завершения мной запущенного проекта, дальше испытания скажут свое слово. К примеру в МК2С (ими комлектуются промышленные ИУП-45 и ИУВ-15) стоят датчики DS1624 которые по алгоритму работы очень схожи с DS18В20 (только у них другой интерфейс, I2C, и чуть уступают по точности, примерно вдвое) и контроллер показывает температуру с разрешением 0,0325 градуса, далее такая информация должна заставить призадуматься, насколько эффективно мы используем ресурсы контроллера.
На счет предоставить народу железо и программу для испытаний, то я с удовольствием, но меня душат те же проблемы что и Дмитрия, все та же нехватка времени и в плане написания программ я более капризен, мне нужно чтобы располагал 3-4 дня без всяких отвлечений на другие занятия. А так у меня специфика работы постоянно дробит мое время на отрезки менее 1,5 часа и при таком режиме крайне тяжело сделать крупный комплексный проект, в основном удается довести до финиша только мелкие и средние проекты. Другой мотив что выкладываю только железо связанно с моими заказчиками, где я работаю в паре с программистами и на мне при разработках лежит железо, а программистам выдаю структуру и алгоритмы, далее они выдают готовый код, статистика показывает что им предоставленных сведений достаточно для написания и отладки без особых хлопот (только надо попасть на грамотного программиста). Вот таковы пирожки с котятами.
Если затронут вопрос о СД индикаторах, проблема решаемая причем очень хорошо можно ее решить совместно с поддержкой клавиатуры, там можно довести до 6-8 кнопок при необходимости, а число индикаторов до 9...12 знаков (раньше делал проекты типа "Бегущая строка" которые были куда сложней)
Наконец-то уважаемый Serge признал, что ему нечего предложить по микроконтроллерным блокам управления, кроме схем, которые без программ не стоят и бумаги, на которых они нарисованы, ИМХО.
Ув. д. Ака, вы ошибочно восприняли высказанное, программы будут попозже, просто я с ними еще работаю, т. е. сначала "железо", потом программа. Такая очередность выполнения шагов разработки у меня тянется еще завода (причем режимного в советские времена), ведь вначале я работал в отделе "Контроль и диагностика цифровых устройств" и там я прошел всю эту "мясорубку" разработки от ТЗ до подписания акта сдачи-приемки, поэтому очередность выполнения этапов разработки жестко регламентировано. И придется повторить одну вещь уже явно, до официальной публикации (бумажной) я стараюсь программы не публиковать, это требования различных редакций, поэтому я могу позволить привести только некоторые части схем, да и то исходные варианты (просто нет у меня удовольствия ждать почти год пока выйдет публикация), "матерые волки" это смогут расшифровать, а менее подготовленные будут иметь затруднения.
А на счет ценности схемы вы частично не правы, грамотный специалист очень многие решения для своих программ может взять из самой схемы.
Другая причина что приходилось работать совместно с напарниками-программистами это все та же нехватка времени, но при этом вместе со схемой я давал и подробные блок-схемы на программы, подпрограммы и процедуры обслуживания прерываний, а если есть готовая блок-схема то это фактически 2/3 от всей программы, дальше перевести ее в исходный текст менее хлопотно, пострашнее только сама отладка программы, именно она съедает львинную долю времени и нервов. Поэтому мне и приходилось в совместных проектах брать на себя в основном аппаратное обеспечение, отодвигая подальше программирование, но если они (программисты) упирались в тупик, то приходилось долбить программы наравне с ними, в основном на ассемблере.
И в заключение, предложенные схемы это всего лишь заготовка для любителей программировать самостоятельно, поэтому если хотите заполучить побольше подробностей, то пишите мне в ЛС, там я отвечу более развернуто, здесь не очень хочется засорять такую интересную тему.
"Ув. д. Ака, вы ошибочно восприняли высказанное, программы будут попозже"- я и говорю, что "нечего предложить по микроконтроллерным блокам управления". Может быть надо было добавить "пока", но от этого суть не меняется.
ИМХО напрасно уважаемый Serge переносит свой старый опыт работы с аналоговыми и дискретными цифровыми средствами на микропроцессорную технику, в разработке которой ведущая роль принадлежит все-таки программисту.
А мысль о том, что " не очень хочется засорять такую интересную тему." достойна всяческих похвал и претворения в жизнь.
Опять ув. д. Ака делаете преждевременные выводы. Изначально я и указал что представляю схему без программы, так что не должно быть иных толкований. Основная цель предложенных мной схем является выслушать мнения, замечания и предложения по предложенным вариантам схем, что и как можно приспособить под различные условия у различных пользователей, начиная от личного подворья и заканчивая промышленным инкубаторием. Далее, какой сервис и функции достаточны, что излишне и что добавить. Вот все это служит мне отправной точкой для написания программы. Дальше у меня последует одна из версий программы которая и пойдет для опробования, после очередных дебатов, но уже по программе я представляю очередную версию и т.д. Учитывая тот факт что я этот вариант делаю на 3 года позже чем Дмитрий (только совсем недавно я получил возможность заниматься более плотно с микроконтроллерами, а не как раньше, изредка и наскоками), то многие моменты мне еще предстоит копать и утряхивать основательно, но без ошибок моих предшественников или известных публикаций.
К сожалению не знаю какая у вас д. Ака специальность, но с большой вероятностью могу предположить что вы на заводе по выпуску электронных изделий (приборов и аппаратов) не работали. Радиолюбитель может себе позволить исправить или сделать доработку готовой платы у себя дома, а вот попробуй сделать такое на заводе, в особенности когда изготовлена целая партия приборов... Просто сожрут с потрохами, да еще заставят исправить ошибки за счет виновника. Поэтому у меня уже в крови вылизать до совершенства схему и только потом взяться за программу. Другие предпочитают наоборот, сначала программу а потом доделывают железо под нее, все зависит с какой колокольни на это смотрят. Как правило любители руководствуются последним вариантом.
Лично я я считаю крайне некорректно чтобы в разработках отдавать исключительный статус только программисту или только аппаратчику, каждый по отдельности много не сделает, все должно быть комплексно, т.е. программист+аппартчик и никак иначе.
Остальные детали я уже заброшу в ЛС, здесь уже и без того достаточно полемики с отклонением от темы.
Если вернуться опять к нашим контроллерам, то их программирование имеет свои тонкости, в особенности их отладка, причем сколько программистов столько и методов со своими приемами. Хоть и есть в наличии много программ-отладчиков и прочих симуляторов, все равно сделать работоспособную программу с первого захода не получиться, по любому придется прогонять на реальном объекте, логические и алгоритмические ошибки только так можно выловить. Симуляторы и отладчики позволяют в основном выловить грубые и средние ошибки, вдобавок трудно имитировать случайные воздействия на операции с портами в/в.
Единственное что мне кажется можно подкорректировать в проге так это циркуляцию воздуха внутри инкубатора, кулер внутри молотит воздух пока не сравняет верх и нижн температуры один к одному, в больших инкубаторах это
сделать очень тяжело
Провалялся больным эту неделю, сейчас отпустило. Так как этот момент требует не больших изменений в программе, попробовал его сделать.
Теперь:
Параметр "РАЗ"-допустимая разница температур между 1 и 2 датчиком.
Параметр "Р.Гс"-гистерезис включения регулятора.
Тревога по разности Т рассчитывается из условия Фактическая разница > (1.5 градуса + параметр "РАЗ").
То есть параметр "РАЗ" это мертвая зона (подставка). И еще, [Т1-Т2] это модуль, число без знака, это значит что нет разницы какой датчик будет холодней/теплей.
Все делалось в состоянии не стояния, возможны ошибки. И при перепрошивке все старые данные слетят и будут пере инициализированы значениями по умолчанию.
------------------------------
Отвлекусь на схемы предоставленные Serge. Я бы не ставил внешний кварц на тактирование микроконтроллера. В плане помехоустойчивости и надежности он хуже внутреннего RC, информация почерпнута в интернете. Да, даже если судить по более сложным АРМ процессорам, у них в случае отказа высокочастотного кварцевого генератора тактирование переходит на внутренний RC. Ну и излишен он, так как есть уже часовой на DS1307.
Ну вот еще мое мнение по еепром и2с, что то в мегах я не наблюдал слета еепром, эта микросхема не усложнит на много плату, но программу сильно. Правильный драйвер и2С мне показался тяжел.
Дмитрий М. Здравствуйте Дмитрий. Не Вы автор этого терморегулятора для инкубатора http://startcd.narod.ru/inkubator2/index.html много вопросов имеется но не могу найти автора этой схемы.
------------------------------
Отвлекусь на схемы предоставленные Serge. Я бы не ставил внешний кварц на тактирование микроконтроллера. В плане помехоустойчивости и надежности он хуже внутреннего RC, информация почерпнута в интернете. Да, даже если судить по более сложным АРМ процессорам, у них в случае отказа высокочастотного кварцевого генератора тактирование переходит на внутренний RC. Ну и излишен он, так как есть уже часовой на DS1307.
Ну вот еще мое мнение по еепром и2с, что то в мегах я не наблюдал слета еепром, эта микросхема не усложнит на много плату, но программу сильно. Правильный драйвер и2С мне показался тяжел.
Дима. спасибо что и на мои схемы удалось уделить внимание. То что я предложил поближе к промышленному варианту с кучей сервиса, поэтому она более насыщена чем версия 3 из этой темы и вещи на счет применения RC генератора я согласен, этот вариант дает мне 2 лишних линии портов в/в под расширение возможностей. В моей схеме я оставил внешний кварц для ситуации программирования контроллера не снимая его из платы, иначе программатор через JTAG его не берет. После этого я внесу поправки и заброшу схему повторно.
Далее висит в воздухе вопрос о приводе заслонки на шаговом двигателе, у меня есть набросок который я смогу повесить на незадействованные выводы от 75РС595 дополнительного индикатора через усилители, только чешу репу как сделать программу с минимальной правкой, тебе как автору сделать проще (знаешь исходник чуть ли наизусть). Другой вариант привода шагового двигателя эта отдельная плата и всего три провода на управление: перемещение на шаг, направление движения и сигнал датчика нулевого положения, для 3-й версии это будет самым подходящим решением.
С I2C я еще повоюю, ведь в мега8 есть аппаратный I2C согласно его же даташиту и просто надо его (аппаратный I2C) заставить работать на общее благо.
Выздоравливай основательно, ты еще очень нужен, успехов в дальнейшем.
JTAG в AtMega8 нет. Здесь у Вас какая то ошибка. Так же как и проблемы программирования без кварца. На счет и2с, я и имел ввиду аппаратный, так вот здесь, как раз интересный момент. На аппаратном, Вам придется использовать полный драйвер TWI, иначе наступите на хорошие грабли, когда программа повиснет на ожидании флага в статусном регистре. То есть куций TWI я бы не рискнул применить с аппаратным блоком. Это по опыту использования TWI. AVR315: TWI master implementation. Если же есть уже большой опыт и отлаженная программа, то да, использовать можно. Я так думаю, что эти вопросы здесь многим не интересны, только любителям программистам..
Меня до сих пор интересует, как же делать заслонку и на до ли. Если делать, то
1) На шаговом двигателе.
2) Двигатель с редуктором, включил/выключил. Алгоритм Руслана.
3) Иначе.
Пока нет четкого представления, поэтому не берусь делать.
VictorUA пишет:
Дмитрий М. Здравствуйте Дмитрий. Не Вы автор этого терморегулятора для инкубатора http://startcd.narod.ru/inkubator2/index.html много вопросов имеется но не могу найти автора этой схемы.
Да. Задавайте здесь, собравшие этот регулятор возможно помогут с ответами.
Да. Задавайте здесь, собравшие этот регулятор возможно помогут с ответами.
Ну во первых я чет запутался с прошивками, какую прошивку надо взять для индикаторов с ОА и поворотным механизмом на концевиках, я чет думал что это 1 файл, а когда скачал тяжело разобраться какой мне нужен.
Скачай прошивки для этой версии. Почитай внимательно текст, там все написано какая прошивка, как называется. Переименуй нужный файл в hex1.Повнимательней почитай, Там файлов с прошивками много. Выбери какую тебе надо. Да, какой у тебя програматор? Я недавно сделал эту версию, работает отлично.
VictorUA там в текстовом документе все расписано.Я программировал PoniProg с помощью 5ти проводов-все без проблем.Дима ты так и не ответил "Вопрос к Дмитрию.Можно применить в качестве датчика влажности DHT22,пишут вроде как аналог SHT11 и SHT15?"Ребята,не надо городить огород с заслонками!Вполне достаточно что есть выход аварийной температуры.Тогда мож с печи не слазить совсем?А то как в анекдоте:"не царское это дело,прикажу вы.....т"
"Наконец-то уважаемый Serge признал, что ему нечего предложить по микроконтроллерным блокам управления, кроме схем, которые без программ не стоят и бумаги, на которых они нарисованы, ИМХО." Я на этом форуме 2 года и не видел ни одного стоящего предложения от Вас,почему Вы требуете это от других?Предложите хоть одну схемку Вашей разработки,даже на МП 39.
Я сегодня не успел но завтра создам новую тему, и там будем обсуждать кто что умет, а кто не умет не чего. Это все в новой теме а тут только про схему от Дмитрия.
VictorUA там в текстовом документе все расписано.Я программировал PoniProg с помощью 5ти проводов-все без проблем.Дима ты так и не ответил "Вопрос к Дмитрию.Можно применить в качестве датчика влажности DHT22,пишут вроде как аналог SHT11 и SHT15?"Ребята,не надо городить огород с заслонками!Вполне достаточно что есть выход аварийной температуры.Тогда мож с печи не слазить совсем?А то как в анекдоте:"не царское это дело,прикажу вы.....т"
категорически поддерживаю. ИМХО от автоматической заслонки да и еще с релейным регулированием кроме вреда никакой пользы не получится. для начала это неплохо раскачает регулятор, особенно в холодное время, когда активный кратковременный приток свежего воздуха способен дать провал по температуре, а если все это умножить на неизвестное запаздывание в регулировании...
Дима, не ведись на это дохлое дело, и запыхаешься, и удовольствия никакого, и пользы ноль.
если уж говорить о полезных модернизациях, то вместо индикатора на борту меги полезно было-бы воткнуть еще один канал регулирования температуры, а если хватит места, то и с каналом влажности. для выводника например, или для канала подготовки приточного воздуха (для "суровых" инк-ов).
ЗЫ. Дима, не смог не переделать под себя твое детище, сейчас готовлю немного переделанную 3.5 версию с подкорректированной прошивкой и обвязкой. времени на сборку мало, так что думаю где-то в марте смогу отчитаться с фотками и описаниями полевых испытаний
"Наконец-то уважаемый Serge признал, что ему нечего предложить по микроконтроллерным блокам управления, кроме схем, которые без программ не стоят и бумаги, на которых они нарисованы, ИМХО." Я на этом форуме 2 года и не видел ни одного стоящего предложения от Вас,почему Вы требуете это от других?Предложите хоть одну схемку Вашей разработки, даже на МП 39.
Необходимую информацию для размышлений я забросил в ЛС. Просьба забросить мне в ЛС ответ обратно.
Если затронут вопрос о схемах моих разработок, то это: А120Б , А50Б, А35Б, "Блок поворота инкубатора", на все эти вещи открыты темы в этой ветке. Так что просьба более внимательно читать заголовки тем.
Меня до сих пор интересует, как же делать заслонку и на до ли. Если делать, то
1) На шаговом двигателе.
2) Двигатель с редуктором, включил/выключил. Алгоритм Руслана.
3) Иначе.
Пока нет четкого представления, поэтому не берусь делать.
Спасибо, с I2C(TWI) пока кувыркаюсь и рою окопы, там есть с чем повоевать. С вопросами связанных с шаговиком и электромагнитом я пока еще поработаю, надо оставить только 2 варианта.
ЗЫ. Дима, не смог не переделать под себя твое детище, сейчас готовлю немного переделанную 3.5 версию с подкорректированной прошивкой и обвязкой. времени на сборку мало, так что думаю где-то в марте смогу отчитаться с фотками и описаниями полевых испытаний
Все упомянутое очень часто применяется в примышленных инкубаторах по одной простой причине, сгорают электромагниты и их не очень то легко можно найти, поэтому и отслеживают в ручном режиме. На основе этих сведений можно с уверенностью проработать 2 варианта заслонок: 1) электромагнит с ограничителем приоткрывния (это самый простой и дешевый вариант с достаточной функциональностью) и 2) Шаговый двигатель с датчиком нулевого положения (более сложный вариант, но зато удовлетворяет практически любой каприз).Остальные варианты я пока откладываю в сторону из-за более сложного решения и более экзотической комплектации. Далее народ уже сам выберет нужный вариант под свою конструкцию инкубатора.
В сообщениях повыше Дмитрий высказал опасение что у шагового двигателя не запоминается текущее положение при перезапуске микроконтроллера, против таких ситуаций есть довольно эффективный способ который позволяет его преодолеть. Вся суть заключается в следующем: в неопределенной ситуации двигатель переводится в режим закрытия заслонки и подсчитываются число шагов до срабатывания датчика нулевого положения, далее двигатель переводится в режим открывания и задают движение на число шагов определенных при движении на закрытие. В таком случае заслонка лишний раз дернентся туда-обратно, но зато отслеживается правильное текущее положение, такой прием пригоден даже для промышленного приложения. Такие вещи я экспериментировал еще в далеком 2003 году и у меня это работало, только в моей системе я использовал 2 датчика положения заслонки, один на поз. "полностью закрыт" и второй на поз. "полностью открыт", в качестве шаговиков применял ПМГ-42 и ДШИ-200-1
На основе данных из постов повыше я набросал свою версию схемы (она отличается от версий Дмитрия), где учел все эти пожелания, правда допустил и некоторое излишество, это микросхемы RTC и EEPROM с учетом сервиса на перспективу, интерфейс связи с компьютером пока оставил в виде черного ящика и желающий поставит свой вариант связи под нужную задачу (связь может быть двунаправленной). На всякий случай предусмотрел возможность расширения функций путем подключения дополнительной 74НС595, в основном для управления шаговым двигателем (это добавлю по заявкам трудящихся).
Всем Привет
Товарищи, я думаю что это уже излишества нехорошие , если для аварийного охлаждения нужна автоматизация заслонки, то в схеме есть выход аварийного вентилятора-от него можно и запитать привод заслонки, если же заслонка нужна для увеличения воздухообмена(для уменьшения уровня углекислого газа в инкубаторе) то мне кажется что проще сделать отдельный автомат для постепенного (на продолжении 21 дня для кур например )приоткрытия заслонки
каждый день или раз в неделю , интервал времени можно выбрать любой. Конечно это мое личное мнение, у меня схема на МЕГЕ 168 и СХТ 10 отработала на отлично с мая и до августа, у меня стоят пенопластовые легкие заслонки,при аварийном охлаждении(когда жара на дворе а в инкубаторе лежат гусиные яйца) кулер включился погнал воздух -заслонка приоткрылась, перестал дуть кулер -заслонка под своим весом -закрылась, вот и вся автоматизация заслонки.
Единственное что мне кажется можно подкорректировать в проге так это циркуляцию воздуха внутри инкубатора, кулер внутри молотит воздух пока не сравняет верх и нижн температуры один к одному, в больших инкубаторах это
сделать очень тяжело, я думаю что можно сделать какую то дельту например 1-2 градуса до верхней температуры(более горячего датчика) с шагом регулировки 0.1град , то есть подгонять холодный датчик к горячему с учетом дельты,
например :если дельта допустим 0.1градус , температура горячего датчика равна 38градусов, то кулер внутри инкубатора должен молотить воздух пока на более холодном датчике не будет 37.9 град. (дельту можно выбирать любую от 0.1 до 1-2град например с шагом 0.1градуса) .Не забывайте , чем проще схема , тем надежнее она работает.
Повторюсь это мое личное мнение.
Не думаю что это излишества, просто это штатный перечень типового инкубатора (температура, влажность, заслонка, поворот и охлаждение). Просто ради дешевизны и простоты часть из этих функций для мелких инкубаторов просто перекладывают на пользователя (или грубо говоря безцеремонно выбрасывают). И про разность температур в камере, основная причина кроется в недостаточной интенсивности конвекции воздуха в камере и некоторых недоработках самой конструкции камеры инкубатора, к сожалению нет единой методики проектирования и расчета камеры инкубатора, каждый делает по своему, причем здесь можно спорить до посинения и конца этому не будет. Если maks067 заметил что это излишество, то в качестве альтернативы могу представить до предела урезанную схему (она выполнена на другом, более древнем микроконтроллере семейства х51), но зато отслеживает температуру, влажность, заслонку и поворот с должным сервисом по индикации. Как еще один вариант привожу урезанную версию схемы которую приводил в предыдущем посте, эта уже на ATmega8/168 и она держит весь набор:температура, влажность, заслонка, поворот и тревога/охлаждение. После этого уже есть что посмотреть, прощупать и оценить (правда пока без программы) для начала по железу.
Serge, ну так пожалуйста предоставьте свою "УРЕЗАННУЮ ВЕРСИЮ"только с программой(без программы железо это только железо и не более),так как Вы пишите- "но зато отслеживает температуру, влажность, заслонку и поворот с должным сервисом по индикации." , а народ протестирует в реальных условиях, "прощупает и оценит", все равно я считаю что Ваша урезанная версия температуру в инкубаторе точнее чем схема Дмитрия на СНТ10 держать не будет, была бы она такой хорошей Вы бы не пытались сотворить что то другое (разве что ради спортивного интереса).Приведу пример, мой товарищ и конкурент по совместительству приобрел блок автоматики (не буду говорить какой дабы не рекламировать) навороченный на Универсал55 , после года эксплуатации он просил уже что бы я ему спаял блок Дмитрия (точность поддержания температуры оставляет желать лучшего,программа за время инкубации дала один сбой зависла так сказать, очень много всяких коэффициентов надо вводить-это его очень напрягает).У меня точность поддержания получилась 0.1 гр. на графике идут просто прямые линии, летом когда на улице начинается жара до 38град. срабатывает аварийка, вот тогда немного идут скачки температуры по графикам.В будущем хочу установить в инкубатории кондиционер .
Ну а на счет недостаточной интенсивности конвекции воздуха в камере , я хорошо знаком и хочу разность температур
датчиков догнать до 0.2градусов с помощью установки дополнительных вентиляторов в камерах , правда не знаю получится такой результат или нет буду пробовать...
Еще добавлю по схемам что Вы выложили , для меня да я думаю и для многих вариант с ЖКИ индикатором не очень подходит, потому что в потемках его плохо видно(цыфири ну очень уж маленькие), а светодиоды видать из далека :)
да и дороже он на много семисегментника...
Как бы на бумаге это не выглядело распрекрасно, но без программы кто ж будет паять и оценивать. И пощупать получится только детальки в кулечке.
Я надеюсь что если будит управление заслонкой то для нее будет отдельная прошивка и отдельная плата для управлении заслонкой. При таком варианте можно будит каждому выбирать делать или не делать этот блок.
Еще не плохо бы сделать коррекцию датчика СНТ 10, попадался один экземплярчик который врал почти на один градус...
В какой-то мере вы правы, в основном приведенные мной примеры показывают как надо оптимизировать "железо" и выжать из него по максимуму из того что есть. Когда идет доводка железа то предпочитаю проработать по бумаге побольше вариантов, где потом из них было что выбрать, только после всего этого в работу запускаю только 1 схему, в крайнем случае 2, после всего этого у меня практически отсуствует доводка железа при наладке.
С программами разговор отдельный, я их пишу только после полной доводки схемы, только так можно получить оптимальный код программы (т.е. железо первично и программа вторично). Программы пока не могу предоставить, они еще крайне сырые и находятся в работе (у меня не принято выдавать на гора сырые программы).
На счет измерения более точней или менее точней, все упирается в алгоритм программы и точности вычислений при одних и тех же датчиках, так что вопрос довольно спорный и оставлю его открытым до завершения мной запущенного проекта, дальше испытания скажут свое слово. К примеру в МК2С (ими комлектуются промышленные ИУП-45 и ИУВ-15) стоят датчики DS1624 которые по алгоритму работы очень схожи с DS18В20 (только у них другой интерфейс, I2C, и чуть уступают по точности, примерно вдвое) и контроллер показывает температуру с разрешением 0,0325 градуса, далее такая информация должна заставить призадуматься, насколько эффективно мы используем ресурсы контроллера.
На счет предоставить народу железо и программу для испытаний, то я с удовольствием, но меня душат те же проблемы что и Дмитрия, все та же нехватка времени и в плане написания программ я более капризен, мне нужно чтобы располагал 3-4 дня без всяких отвлечений на другие занятия. А так у меня специфика работы постоянно дробит мое время на отрезки менее 1,5 часа и при таком режиме крайне тяжело сделать крупный комплексный проект, в основном удается довести до финиша только мелкие и средние проекты. Другой мотив что выкладываю только железо связанно с моими заказчиками, где я работаю в паре с программистами и на мне при разработках лежит железо, а программистам выдаю структуру и алгоритмы, далее они выдают готовый код, статистика показывает что им предоставленных сведений достаточно для написания и отладки без особых хлопот (только надо попасть на грамотного программиста). Вот таковы пирожки с котятами.
Если затронут вопрос о СД индикаторах, проблема решаемая причем очень хорошо можно ее решить совместно с поддержкой клавиатуры, там можно довести до 6-8 кнопок при необходимости, а число индикаторов до 9...12 знаков (раньше делал проекты типа "Бегущая строка" которые были куда сложней)
Наконец-то уважаемый Serge признал, что ему нечего предложить по микроконтроллерным блокам управления, кроме схем, которые без программ не стоят и бумаги, на которых они нарисованы, ИМХО.
Ув. д. Ака, вы ошибочно восприняли высказанное, программы будут попозже, просто я с ними еще работаю, т. е. сначала "железо", потом программа. Такая очередность выполнения шагов разработки у меня тянется еще завода (причем режимного в советские времена), ведь вначале я работал в отделе "Контроль и диагностика цифровых устройств" и там я прошел всю эту "мясорубку" разработки от ТЗ до подписания акта сдачи-приемки, поэтому очередность выполнения этапов разработки жестко регламентировано. И придется повторить одну вещь уже явно, до официальной публикации (бумажной) я стараюсь программы не публиковать, это требования различных редакций, поэтому я могу позволить привести только некоторые части схем, да и то исходные варианты (просто нет у меня удовольствия ждать почти год пока выйдет публикация), "матерые волки" это смогут расшифровать, а менее подготовленные будут иметь затруднения.
А на счет ценности схемы вы частично не правы, грамотный специалист очень многие решения для своих программ может взять из самой схемы.
Другая причина что приходилось работать совместно с напарниками-программистами это все та же нехватка времени, но при этом вместе со схемой я давал и подробные блок-схемы на программы, подпрограммы и процедуры обслуживания прерываний, а если есть готовая блок-схема то это фактически 2/3 от всей программы, дальше перевести ее в исходный текст менее хлопотно, пострашнее только сама отладка программы, именно она съедает львинную долю времени и нервов. Поэтому мне и приходилось в совместных проектах брать на себя в основном аппаратное обеспечение, отодвигая подальше программирование, но если они (программисты) упирались в тупик, то приходилось долбить программы наравне с ними, в основном на ассемблере.
И в заключение, предложенные схемы это всего лишь заготовка для любителей программировать самостоятельно, поэтому если хотите заполучить побольше подробностей, то пишите мне в ЛС, там я отвечу более развернуто, здесь не очень хочется засорять такую интересную тему.
"Ув. д. Ака, вы ошибочно восприняли высказанное, программы будут попозже"- я и говорю, что "нечего предложить по микроконтроллерным блокам управления". Может быть надо было добавить "пока", но от этого суть не меняется.
ИМХО напрасно уважаемый Serge переносит свой старый опыт работы с аналоговыми и дискретными цифровыми средствами на микропроцессорную технику, в разработке которой ведущая роль принадлежит все-таки программисту.
А мысль о том, что " не очень хочется засорять такую интересную тему." достойна всяческих похвал и претворения в жизнь.
Опять ув. д. Ака делаете преждевременные выводы. Изначально я и указал что представляю схему без программы, так что не должно быть иных толкований. Основная цель предложенных мной схем является выслушать мнения, замечания и предложения по предложенным вариантам схем, что и как можно приспособить под различные условия у различных пользователей, начиная от личного подворья и заканчивая промышленным инкубаторием. Далее, какой сервис и функции достаточны, что излишне и что добавить. Вот все это служит мне отправной точкой для написания программы. Дальше у меня последует одна из версий программы которая и пойдет для опробования, после очередных дебатов, но уже по программе я представляю очередную версию и т.д. Учитывая тот факт что я этот вариант делаю на 3 года позже чем Дмитрий (только совсем недавно я получил возможность заниматься более плотно с микроконтроллерами, а не как раньше, изредка и наскоками), то многие моменты мне еще предстоит копать и утряхивать основательно, но без ошибок моих предшественников или известных публикаций.
К сожалению не знаю какая у вас д. Ака специальность, но с большой вероятностью могу предположить что вы на заводе по выпуску электронных изделий (приборов и аппаратов) не работали. Радиолюбитель может себе позволить исправить или сделать доработку готовой платы у себя дома, а вот попробуй сделать такое на заводе, в особенности когда изготовлена целая партия приборов... Просто сожрут с потрохами, да еще заставят исправить ошибки за счет виновника. Поэтому у меня уже в крови вылизать до совершенства схему и только потом взяться за программу. Другие предпочитают наоборот, сначала программу а потом доделывают железо под нее, все зависит с какой колокольни на это смотрят. Как правило любители руководствуются последним вариантом.
Лично я я считаю крайне некорректно чтобы в разработках отдавать исключительный статус только программисту или только аппаратчику, каждый по отдельности много не сделает, все должно быть комплексно, т.е. программист+аппартчик и никак иначе.
Остальные детали я уже заброшу в ЛС, здесь уже и без того достаточно полемики с отклонением от темы.
Если вернуться опять к нашим контроллерам, то их программирование имеет свои тонкости, в особенности их отладка, причем сколько программистов столько и методов со своими приемами. Хоть и есть в наличии много программ-отладчиков и прочих симуляторов, все равно сделать работоспособную программу с первого захода не получиться, по любому придется прогонять на реальном объекте, логические и алгоритмические ошибки только так можно выловить. Симуляторы и отладчики позволяют в основном выловить грубые и средние ошибки, вдобавок трудно имитировать случайные воздействия на операции с портами в/в.
Провалялся больным эту неделю, сейчас отпустило. Так как этот момент требует не больших изменений в программе, попробовал его сделать.
Теперь:
Параметр "РАЗ"-допустимая разница температур между 1 и 2 датчиком.
Параметр "Р.Гс"-гистерезис включения регулятора.
Тревога по разности Т рассчитывается из условия Фактическая разница > (1.5 градуса + параметр "РАЗ").
Включение вывода "Разность Т1-Т2" [Т1-Т2] >= "РАЗ"+"Р.Гс"
Отключение вывода "Разность Т1-Т2" [Т1-Т2] < "РАЗ"
То есть параметр "РАЗ" это мертвая зона (подставка). И еще, [Т1-Т2] это модуль, число без знака, это значит что нет разницы какой датчик будет холодней/теплей.
Все делалось в состоянии не стояния, возможны ошибки. И при перепрошивке все старые данные слетят и будут пере инициализированы значениями по умолчанию.
------------------------------
Отвлекусь на схемы предоставленные Serge. Я бы не ставил внешний кварц на тактирование микроконтроллера. В плане помехоустойчивости и надежности он хуже внутреннего RC, информация почерпнута в интернете. Да, даже если судить по более сложным АРМ процессорам, у них в случае отказа высокочастотного кварцевого генератора тактирование переходит на внутренний RC. Ну и излишен он, так как есть уже часовой на DS1307.
Ну вот еще мое мнение по еепром и2с, что то в мегах я не наблюдал слета еепром, эта микросхема не усложнит на много плату, но программу сильно. Правильный драйвер и2С мне показался тяжел.
Дима здравствуй. Самое главное не болей и выздоравливай побыстрей.Успехов тебе.
Дмитрий М. Здравствуйте Дмитрий. Не Вы автор этого терморегулятора для инкубатора http://startcd.narod.ru/inkubator2/index.html много вопросов имеется но не могу найти автора этой схемы.
Дима. спасибо что и на мои схемы удалось уделить внимание. То что я предложил поближе к промышленному варианту с кучей сервиса, поэтому она более насыщена чем версия 3 из этой темы и вещи на счет применения RC генератора я согласен, этот вариант дает мне 2 лишних линии портов в/в под расширение возможностей. В моей схеме я оставил внешний кварц для ситуации программирования контроллера не снимая его из платы, иначе программатор через JTAG его не берет. После этого я внесу поправки и заброшу схему повторно.
Далее висит в воздухе вопрос о приводе заслонки на шаговом двигателе, у меня есть набросок который я смогу повесить на незадействованные выводы от 75РС595 дополнительного индикатора через усилители, только чешу репу как сделать программу с минимальной правкой, тебе как автору сделать проще (знаешь исходник чуть ли наизусть). Другой вариант привода шагового двигателя эта отдельная плата и всего три провода на управление: перемещение на шаг, направление движения и сигнал датчика нулевого положения, для 3-й версии это будет самым подходящим решением.
С I2C я еще повоюю, ведь в мега8 есть аппаратный I2C согласно его же даташиту и просто надо его (аппаратный I2C) заставить работать на общее благо.
Выздоравливай основательно, ты еще очень нужен, успехов в дальнейшем.
JTAG в AtMega8 нет. Здесь у Вас какая то ошибка. Так же как и проблемы программирования без кварца. На счет и2с, я и имел ввиду аппаратный, так вот здесь, как раз интересный момент. На аппаратном, Вам придется использовать полный драйвер TWI, иначе наступите на хорошие грабли, когда программа повиснет на ожидании флага в статусном регистре. То есть куций TWI я бы не рискнул применить с аппаратным блоком. Это по опыту использования TWI. AVR315: TWI master implementation. Если же есть уже большой опыт и отлаженная программа, то да, использовать можно. Я так думаю, что эти вопросы здесь многим не интересны, только любителям программистам..
Меня до сих пор интересует, как же делать заслонку и на до ли. Если делать, то
1) На шаговом двигателе.
2) Двигатель с редуктором, включил/выключил. Алгоритм Руслана.
3) Иначе.
Пока нет четкого представления, поэтому не берусь делать.
Да. Задавайте здесь, собравшие этот регулятор возможно помогут с ответами.
Ну во первых я чет запутался с прошивками, какую прошивку надо взять для индикаторов с ОА и поворотным механизмом на концевиках, я чет думал что это 1 файл, а когда скачал тяжело разобраться какой мне нужен.
Скачай прошивки для этой версии. Почитай внимательно текст, там все написано какая прошивка, как называется. Переименуй нужный файл в hex1.Повнимательней почитай, Там файлов с прошивками много. Выбери какую тебе надо. Да, какой у тебя програматор? Я недавно сделал эту версию, работает отлично.
Всем Привет
Хочу поблагодарить Дмитрия за новую прошивку с подправленной циркуляцией воздуха внутри инкубатора.
Весной буду пробовать. Дима Спасибо.
VictorUA там в текстовом документе все расписано.Я программировал PoniProg с помощью 5ти проводов-все без проблем.Дима ты так и не ответил "Вопрос к Дмитрию.Можно применить в качестве датчика влажности DHT22,пишут вроде как аналог SHT11 и SHT15?"Ребята,не надо городить огород с заслонками!Вполне достаточно что есть выход аварийной температуры.Тогда мож с печи не слазить совсем?А то как в анекдоте:"не царское это дело,прикажу вы.....т"
"Наконец-то уважаемый Serge признал, что ему нечего предложить по микроконтроллерным блокам управления, кроме схем, которые без программ не стоят и бумаги, на которых они нарисованы, ИМХО." Я на этом форуме 2 года и не видел ни одного стоящего предложения от Вас,почему Вы требуете это от других?Предложите хоть одну схемку Вашей разработки,даже на МП 39.
Я сегодня не успел но завтра создам новую тему, и там будем обсуждать кто что умет, а кто не умет не чего. Это все в новой теме а тут только про схему от Дмитрия.
Нет. Там интерфейс другой, похож на 1wire. Такой без реального датчика на реальной плате трудно отладить.
категорически поддерживаю. ИМХО от автоматической заслонки да и еще с релейным регулированием кроме вреда никакой пользы не получится. для начала это неплохо раскачает регулятор, особенно в холодное время, когда активный кратковременный приток свежего воздуха способен дать провал по температуре, а если все это умножить на неизвестное запаздывание в регулировании...
Дима, не ведись на это дохлое дело, и запыхаешься, и удовольствия никакого, и пользы ноль.
если уж говорить о полезных модернизациях, то вместо индикатора на борту меги полезно было-бы воткнуть еще один канал регулирования температуры, а если хватит места, то и с каналом влажности. для выводника например, или для канала подготовки приточного воздуха (для "суровых" инк-ов).
ЗЫ. Дима, не смог не переделать под себя твое детище, сейчас готовлю немного переделанную 3.5 версию с подкорректированной прошивкой и обвязкой. времени на сборку мало, так что думаю где-то в марте смогу отчитаться с фотками и описаниями полевых испытаний
тут вроде живой софт по dth11.
http://www.forum.getchip.net/viewtopic.php?f=9&t=77
а по DHT22 очень много негативных отзывов, в отличии от DHT11 эти работать не торопятся.
Необходимую информацию для размышлений я забросил в ЛС. Просьба забросить мне в ЛС ответ обратно.
Если затронут вопрос о схемах моих разработок, то это: А120Б , А50Б, А35Б, "Блок поворота инкубатора", на все эти вещи открыты темы в этой ветке. Так что просьба более внимательно читать заголовки тем.
Спасибо, с I2C(TWI) пока кувыркаюсь и рою окопы, там есть с чем повоевать. С вопросами связанных с шаговиком и электромагнитом я пока еще поработаю, надо оставить только 2 варианта.
Сергей, привет :) Ждем с нетерпением!