Arduino.ru

Любой. Подойдёт. Технологически nano удобнее, но это вкусовщина, подойдёт любой

>

Зависит в первую очередь от уровня криворукости и кривоголовости того, кто будет делать, а во-вторую от качества электропитания и т.п. вещей

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

>Сначал нужно спроектировать устройство, а потом уж подбирать компоненты.

Ну вроде бы тут устройство примитивное. Плата контроллера, датчики + реле.

WD есть, но при нормальной реализации он не нужен, а при кривой - не спасёт.

Что же до тривиальности устройства, ... ну-ну. Удачи Вам!

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

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

bwn, у ТС видимо отдельная, независимая от основной схемы управления система защиты. Кажется для скважинных насосов есть такой параметр, - максимальное время работы в час.

Согласен, не разобрался сразу. Тады варианты:
1. МК управляет насосом. РД 220В через оптрон или напрямую 5В (выйдет ли), сигнал на МК.
2. МК через РД управляет насосом. Выход с РД через оптрон на МК и 220В на насос.
Это по напряжению. Если насос заклинит или сгорит, мы ничего не узнаем.
Контроль по току обе ситуации отработает корректно, возможно получится и сухой ход отловить.

Согласен, что датчик тока тут самый информативный. А по минимуму ТС в общем-то устраивает любой из 3-х вариантов.

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

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

Самый простой способ понять - работает или нет насос подключаемый через реле давления, это считывать напряжение с его разъема питания. Как я понимаю, готовых датчиков на переменный ток до 400 В нету, поэтому придется городить что-то самостоятельно, например, из реле.

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

Дуина у вас управляет в любом случае, кроме варианта свето-звуковой сигнализации, где отключает оператор.
Датчик наличия напряжения это оптрон с резистором. В качестве управляющего реле я бы взял контактор на DIN рейку, а им управлял с МК. Мелкие китайские реле для силовых нагрузок не айс, через них можно управлять контактором.
А вот наличие напряжения на котактах насоса ни о чем кроме наличия напряжения не говорит. Горелую обмотку уже ничем не спасешь, а если заклинило, есть шансы.
Датчики тока не обязательно включаются в разрыв. Есть бесконтактные в виде кольца с обмоткой, через кольцо пропускают один силовой провод. Для них скорее всего потребуется еще ОУ, возможно не прав. Самое близкое место для поиска такого датчика - неисправный цифровой электросчетчик.

Реле задержки.

http://www.ebay.com/itm/AC-220V-H3Y-2-Power-On-Time-Relay-Delay-Timer-1-...

После того как вы  подаёте на него  питание
реле делает задержку на  установленное время и щёлкает релюшкой.
Отключает насос и включает вашу сирену.

http://www.electro-tech-online.com/attachments/aaesp06-gif.81115/
http://www.electro-tech-online.com/attachments/h3y_dsheet_csm92-pdf.81122/

Мне не требуется контролировать обмотку электромотора насоса :) В нем есть своя автоматика по этому поводу. Необходимо контролировать отсутствие затопления поверхностными водами в случае обрыва водопровода, когда насос будет качать бесконтрольно. По ряду причин, использования датчиков протечки - нецелесообразно.

Если я правильно понял описание сего устройства, то оно делает примерно следующее: ограничивает максимальное время работы нагрузки. Т.е., алгоритм работы примерно следующий:

А. подается питание на реле, обнуляется счетчик, подается питание на нагрузку.

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

Не очень понятно, отрубается она совсем или же до следующего цикла А?

Штука интересная, однако нет скользящего окна. Поскольку насосы оборудованы гидроаккумуляторами, то работать могут импульсно, если повреждение водопровода небольшое. Т.е. включатся, накачают ГА до нормы, отключатся, из-за утечки водица уйдет, насосы включатся опять. Именно по этой причине, необходимо скользящее окно за период.

Тогда просто оптрон и контактор, или выше у trembo

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

типа РС814. например, через  82к 1вт в сеть. На выходе, входе ардуино,  можно собрать простенький интегратор.

я делал похожее по логике устройствоhttp://radiokot.ru/lab/controller/66/

здесь тоже электромотор. Датчиком ASC712 я замеряю мгновенные токи через мотор. Алгоритм такой - считаю мгновенные токи и усредненные токи. В программе заданы три константы - максимальный мгновенный ток, максимальный средний ток во время пуска и максимальный средний ток после пуска (через несколько сек после включения)

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

Константы подбирал вручную с тестированием в разных режимах работы

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

собственно больше и не от чего защищать. как и в моем случае у вас наверняка есть защита от заклинивания через термопредохранитель и защтита от сухого хода. Но с датчиком тока по идее вы среагируете быстрее

Именно так :) Скользящее окно за период, в нем сколько работало.

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

Спасибо, у меня устройство немного более простое. Ему не требуется защищать двигатели. От сухого хода они защитятся самостоятельно, впрочем как и от перегрева. Тут защита немного другого рода, от нормальной работы насосов в аварийной ситуации водопровода. Ибо получить 200 кубометров воды в подвал или еще куда - очень неприятно :)

если так то почему это делать по косвенным признакам (время работы)?

сделайте датчики протечки и переводите в аварийный режим при наличии воды

а для чего такая точность, дискрет в  10сек или, скажем, 1 мин, тут чего-то решает?

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

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

Это совсем не проблема.

Предложу такой алгоритм.

записываем число 3603

при работе насоса каждую секунду из числа вычитаем тройку, (кстати, время работы насоса можно подсчитывать по числу периодов  или полупериодов сети с оптрона)

Если число меньше или = 3,  - блокировка насоса, сообщение о ошибке на индикатор, ожидания сброса.

При неработающем насосе, каждую секунду плюсуем 1, если число меньше 3603, 

если число равно 3600, то проц сидит в режиме ожидания включения насоса.

Мне кажется, что алгоритм не особо. Нет движущегося окна. Т.е. включили устройство, на счетчике 3603. Час насос не работал, на счетчике 7203. Потом насос включился, проработал без перерыва 20 минут 6003 на счетчике. Насос пора мочить аварийно, но счетчик нам говорит, что нет.

на счетчике не может быть больше 3603 см последнюю строку алгоритма. (там я троеку забыл исправить)

"если число равно 3603, то проц сидит в режиме ожидания включения насоса."

а почему нельзя просто при обнаружении включении нагрузки, взводить таймер на 20 мин? 

или сравнивать значение работы насосов и давления в трубопроводе

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

Так это еще и датчик давления воды нужен. А это уже дополнительная проблема, которая не учитывает наличие кранов и обратных клапанов установленных между датчиком давления и насосом. Хотя как вариант, вполне.

Тогда вроде бы работает, но очень уж простой получается алгоритм :) Можно и дискретизацию повысить :)

Я тут обещал вечером опубликовать алгоритм, вот освободился, посмотрел и увидел, что коллега ВН уже опубликовал практически точно такой же.

Более того, на мой взгляд, для нужд ТС вариант ВН подходит больше и поэтому следует просто реализовать его. Мой вариант того же алгоритмя значительно сложнее и единственный случай, когда его стоит предпочесть, это если есть возможность погрузить МК в сон и экономить энергию, т.к. в моём варианте не нужно каждую секунду ничего инкрементировать и МК может спокойно спать между моментами включения и выключения двигателя (выключения планового или принудительного).

Насколько я понял, здесь у ТС не тот случай - все равно спать МК не положишь, т.к. у него ещё другие дела есть, так что я бы реализовал простой и изящный алгоритм, предложенный ВН. Но, если надо, я свой таки опишу.

Меня то больше интересовало, как получить min-max значения за промежуток времени (час, сутки....), с учетом реального времени. Надеялся из Вашего что то почерпнуть.

В смысле мин/макс - это, например, максимальное время непрерывной работы за некоторый период (типа суток)? Да, это почерпнёте.

Идея такая же, как и у ВН. Такой же счётчик, также в одну сторону считается по 1, в в другую по 3 (если для 20 минут), а работает так.

Состоит из трёх функций:

ON_Engine_ON - вызывается. когда двигатель включился 

Спасибо на добром слове, ЕвгенийП!

Алгоритм конечно простой, но вряд ли его можно назвать оптимальным. Эпитет "изящный" получен с большим авансом, наверно он скорее - прозрачный, понятный, но имеет слишком много телодвижений вокруг подсчета секунд, если это дело развернуть и раскрыть в коде. В данном проете это вроде как не критично, и работать будет, да и написан он был влет, собственно и все.

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

========

О, пока писал, можно читать уже готовенькое =)

Спасибо, ЕвгенийП!

ЕвгенийП, благодарю, прием осознал. У меня другое. Задача чисто умозрительная, может когда и понадобится. Есть итальянский заоконный термометр, показывет текущую, минимальную и максимальную за сутки + тренд. Платка всего ничего (мелкосхема - капля), батарейки ААА хватает года на три. Задумался, как они это организовали? У меня кроме массивов в голову ничего не приходит, но где там столько памяти? Вот и решил, что какой то прием из виду упустил.))))

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

tmin=t
tmax=t//присваиваем текущую, начальную температуру
t=t+dt // температура изменилась
if(t<tmin)
{tmin=t}
if(t>tmax)
{tmax=t}

если грубо то так

надо же этот мин-макс иногда обнулять, иначе зимой так и будет показывать летний максимум.

tmin=t
tmax=t//присваиваем текущую, начальную температуру
t=t+dt // температура изменилась
if(t<tmin)
{tmin=t}
if(t>tmax)
{tmax=t}

Это за общее время работы, а как за последние 24 часа от текущего времени, не раздувая память?

два массива на 24 числа каждый? 

tmin=t
tmax=t//присваиваем текущую, начальную температуру
t=t+dt // температура изменилась
if(t<tmin)
{tmin=t}
if(t>tmax)
{tmax=t}

А если внимательно прочитать:

то это без массива не сделать.
Утром встаём- видим ночной минимум, вечером смотрим- видим дневной максимум.
И сбрасывать ничего не надо.

Каким угодно способом (таймер, RTC, Интернет и т.п.) делаем, чтобы раз в сутки (допустим, в полночь) вызывалась маленькая функция которая всего лишь присваивает очень маленькое значение МАКС, и очень больше МИН. При первом же замере они поменяются на вновь измеренное значение, ну и дальше всё пойдёт как раньше.

Я ж собственно именно такой поход описал в конце поста о своём алгоритме. 

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

Ой, виноват, недостаточно внимательно прочитал "последние 24 часа от текущего времени".

Так, как я саказал - не прокатит.

Но Всё равно там всё просто делается. Сейчас убегаю, позже поговорим.

Если они есть. В реальной системе, архитектруно более правильно не путать. Измерение идёт само по себе по своему расписанию. А процедурка, которая сбрасывает, просто вклинивается и она не знает текущего значения.