Сообщений в теме: 743

[nikr]

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

[UL7AAjr]

Николай, вполне разумно. Только надо с адресом определиться. Логично будет разместить ID датчика в самое начало EPROM, и отвести под него два байта, как для обычного регистра. Тогда его адрес будет 40001, а дальше идут все остальные регистры хранения. Причем на стороне датчика хорошо-бы предусмотреть механизм смены адреса датчика ПОСЛЕ выполнения команды записи или как-то по другому обеспечить правильный ответ на запись. Иначе управляющее приложение на запрос записи получит ответ как-бы от другого датчика. Конечно, особой роли не сыграет, но ошибку выдаст.

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

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

Итак подытожим.

Датчик влажности:

• Регистр влажности 30001
• Регистр температуры первый 30002
• Регистр температуры второй 30003
• Флаг готовности 0001
• Флаг реле 0002
• Уникальный код 40001
• Регистры настройки добавляемые пользователем (40002...)

Регистры 30001..30003 имеют настройки пересчета. Регистр 30002 может быть использован как корректирующий для значений регистра 30001 (коррекция температуры). Флаг готовности говорит о достоверности данных остальных регистров и может быть сброшен управляющим приложением для переинициализации датчика (reset). Флаг реле включается для выполнения действия, предписанного датчику. Регистры настройки добавляются и изменяются пользователем по необходимости за исключением регистра 40001, содержащего уникальный код регистра.

Датчик насоса:

• Регистр влажности 30001 используется как датчик дождя (можно не использовать)
• Регистр температуры первый 30002 температура воздуха (можно не использовать)
• Регистр температуры второй 30003 температура насоса (можно не использовать)
• Флаг готовности 0001 наличие воды для полива или True если не используется
• Флаг реле 0002 включение/выключение насоса
• Уникальный код 40001
• Регистры настройки добавляемые пользователем (40002...) на усмотрение пользователя

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

Николай, как вам такая конфигурация? И подскажите по вашему алгоритму полива.

[nikr]

Николай, вполне разумно. Только надо с адресом определиться. Логично будет разместить ID датчика в самое начало EPROM, и отвести под него два байта, как для обычного регистра. Тогда его адрес будет 40001, а дальше идут все остальные регистры хранения. Причем на стороне датчика хорошо-бы предусмотреть механизм смены адреса датчика ПОСЛЕ выполнения команды записи или как-то по другому обеспечить правильный ответ на запись. Иначе управляющее приложение на запрос записи получит ответ как-бы от другого датчика. Конечно, особой роли не сыграет, но ошибку выдаст.

Игорь, я бы регистр ModBus для управления ID разместил в конец таблицы адресов, напимер, 65535 (FFFF). Так более вероятна совместимость с промышленными датчиками. В EEPROM имеет смысл отвести под ID один байт. Насчет правильного ответа согласен, надо подумать как реализовать.

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

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

Николай, как вам такая конфигурация? И подскажите по вашему алгоритму полива.

По конфигурации замечание только одно адрес ID в ModBus не особо удачно расположен, хотя если использовать только свои датчики то и без разницы где он будет. Можно вообще пользовательскую команду создать для смены ID из диапазона (от 65 до 72 и от 100 до 110).

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

[UL7AAjr]

По конфигурации замечание только одно адрес ID в ModBus не особо удачно расположен, хотя если использовать только свои датчики то и без разницы где он будет. Можно вообще пользовательскую команду создать для смены ID из диапазона (от 65 до 72 и от 100 до 110).

Николай, у меня на МК только 1KB EEPROM расположенный по адресу 8000h. Поэтому никак не смогу использовать FFFFh. Если честно, то для упрощения задачи, я все регистры настроек датчика просто замапил на начало вектора EEPROM. Т.е. весь диапазон EEPROM разбит на двухбайтовые регистры и доступен через команды modbus. Если вы сделаете так же, то отпадет необходимость обрабатывать каждую команду чтения/модификации регистров хранения персонально. Поэтому и логично разместить ID в самое начало, конец-то у всех разный будет, а в середину - то можно и запутаться.

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

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

По поводу датчика дождя. Тут надо конструкцию какую-то придумывать. Слабый дождь и роса у нас тоже часто. Нужно что-то типа воронки сделать и ограничить вытекающий поток. При обильном дожде, вода вытекать не успеет и это дело надо как-то отловить. В общем пробовать надо.

Николай, а у вас какое устройство USB-RS485?

[nikr]

Николай, у меня на МК только 1KB EEPROM расположенный по адресу 8000h. Поэтому никак не смогу использовать FFFFh. Если честно, то для упрощения задачи, я все регистры настроек датчика просто замапил на начало вектора EEPROM.

Ну пусть остается 40001.

Николай, а у вас какое устройство USB-RS485?

Ага, именно такую штуку использую.
http://bolid.ru/prod.../usb-rs485.html

[UL7AAjr]

Николай, я оставил 40001 под адрес датчика и зарезервировал два байта. У меня слово в памяти хранится старшим разрядом вперед, поэтому пришлось в коде датчика сделать адрес байта ID = 1001h (вместо 1000h), иначе в холдинг-регистре ерунда отображается вместо адреса (вернее ID * 256). У вас, кстати, как слово хранится, младшим байтом вперед? И еще один вопрос. Какую длину паузы на RS485 ваш датчик распознает как начало нового пакета? Достаточно ли будет 30ms?

[nikr]

Игорь, как хранится слово я вообще то не разбирался. На языке С этим заведует компилятор. Пока перезапись адреса не написал - занялся новой печаткой. В EEPROM буду кидать 1 байт - все равно адрес больше не бывает. Слово тишины у меня 3 символа. Если не понижать битрейд UART до 600 бод, то 30ms хватает за глаза. На стандартной скорости в 9600 слово тишины у меня получается 2ms.

[UL7AAjr]

Николай, я посмотрел, AVR "остроконечник" (младшие байты по младшему адресу). Предлагаю простой и удобный вариант работы с регистрами хранения, это наложить их на область адресов EEPROM. Небольшой недостаток - доступ по словам, а не по байтам. Николай, а почему вы избегаете размещения RJ45 на плате? Между прочим, очень удобно соединять датчики обычным патч-кордом. Для экономии места можно установить только один разъем основной шины на плату, а коммутацию производить через тройники.

[nikr]

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

Да нет, в AtMege не все так просто. Там при записи в EEPROM надо манипулировать тремя регистрами ( адрес, данные, управление) да еще смотреть не пишется ли что нибудь в это время во Flash. Так что наложение там не проходит.

Николай, а почему вы избегаете размещения RJ45 на плате? Между прочим, очень удобно соединять датчики обычным патч-кордом. Для экономии места можно установить только один разъем основной шины на плату, а коммутацию производить через тройники.

RJ45 у меня просто в наличии нету, а RJ12 валялись - вот и попробовал. Пока остановлюсь на гребенке.

[UL7AAjr]

Да нет, в AtMege не все так просто. Там при записи в EEPROM надо манипулировать тремя регистрами ( адрес, данные, управление) да еще смотреть не пишется ли что нибудь в это время во Flash. Так что наложение там не проходит.

Николай, не в буквальном смысле наложить. Я имею в виду, что регистру 40001 соответствует адрес EEPROM[0], 40002: EEPROM[2] и т.д. Другими словами, логически разместить регистры хранения последовательно в EEPROM. У меня тоже пришлось манипулировать немного с управлением EEPROM.

Для упрощения, можно держать копию EEPROM (или его части) в оперативке и сделать процедуру, которая на холостом ходу датчика сравнивает копию с оригиналом и вносит изменения в EEPROM при необходимости. Это, кстати, позволит правильно ответить датчику на команду смены ID.

[nikr]

Ну тогда понятно. Для хранения в EEPROM пока подходит только адрес датчика. Остальные регистры при выключении хранить незачем. Сейчас у меня все хранится структурами (адрес, данные) в ОЗУ. Поэтому могу набрать набор регистров с произвольными адресами.

[UL7AAjr]

Остальные регистры при выключении хранить незачем.

А как же настройки сервы? Да еще и установки частоты накачки можно туда засунуть.

Тем не менее, управляющее приложение все-таки сделал гибридное. Можно создавать и настраивать произвольные датчики, или создать предопределенные датчики (влажность-температура, насос и т.д.). Сейчас отлаживаюсь. Пока полет нормальный
 sg-1.jpg   103.51К   26 Количество загрузок:

[UL7AAjr]

Еще вот мысли по поводу конструкции сенсора. Когда-то давно, я делал бесконтактный датчик уровня воды. Он был аналоговый, представлял собой генератор ВЧ и работал по принципу срыва генерации. Вот, нашел фотку  cs_photo.jpg   54.59К   8 Количество загрузок: В качестве сенсора использовал пищевую фольгу, наклеенную при помощи скотча на внешнюю сторону пластикового бака. Вот я и подумал, что можно попробовать наклеить на цветочный горшок два кольца из пищевой фольги одно над другим и подсоединить это дело к датчику, работающему на 1MHz. По идее, работать должно. Еще, для цветочных горшков (которые рядом), можно на датчик поставить демультиплексор, и соорудить несколько каналов измерения.

[oduvan]

Поставил диоды 1N4148, 150 раз проверил схему, но как не странно получить диапазона в 600 ед так и не удалось, сначала грешил на датчик померил скотч, которым обклеен датчик он 45 мкм должен норм работать, использую ардуино уно с atmega328, может он отличается от нано :blink: ??

 

Сергей, вы для проверки, датчик закоротите. Показания должны резко упасть. Если не получится, дело в схеме, если получится - дело в сенсоре.

 

Спасибо за совет сегодня вечером попробую поэкспериментировать!

[nikr]

А как же настройки сервы? Да еще и установки частоты накачки можно туда засунуть.

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

[nikr]

Поставил диоды 1N4148, 150 раз проверил схему, но как не странно получить диапазона в 600 ед так и не удалось, сначала грешил на датчик померил скотч, которым обклеен датчик он 45 мкм должен норм работать, использую ардуино уно с atmega328, может он отличается от нано :blink: ??

Сергей, вы какое опорное напряжение на АЦП используете. Если 3,3в то больше 300 едениц дельты не получится.
Потом на уно у вас какой кварц стоит 16мГц или 8?
Еще хотелось бы знать: параметры сенсора, показания в воздухе, показания полностью в воде.

[nikr]

Закончил новый дизайн платы датчика.  GygroV3.2-1.jpg   140.26К   56 Количество загрузок: Специально для стандартной телефонной розетки  GygroV3.2-2.jpg   99.85К   59 Количество загрузок: сенсор будет втыкаться в этот 6-ти контактный разъем  GygroV3.2-3.jpg   77.24К   35 Количество загрузок: Правда сам сенсор в новом дизайне пока не готов.

[UL7AAjr]

Николай, нормально так получилось. Теперь только размножить осталось Кстати, эти корпуса герметичностью не славятся, для дома, понятно, и так пойдет, а для улицы я их пищевой пленкой обернул, не эстетично - но сухо. По поводу хранения настроек. Еще ведь хотели настройки уровней перехода светодиода туда положить. Это наверняка придется сделать. Для отладки Modbus я использовал CAS Modbus Scanner, мне он показался поудобнее. Можно создать несколько запросов, которые автоматически сохраняются, и легко переназначить их на другое устройство. В управляющем приложении надо еще поработать с настройками вывода графиков. Планирую добавить возможность вывода содержимого любого из регистров датчика с настройкой масштаба и цвета. А пока приложение на стендовых испытаниях (стенд это два датчика в горшках + датчик управления насосом ). Защиту от "неправильных" настроек вообще еще не делал, думаю, что есть сотня способов намертво повесить приложение. Этим позже займусь.

[oduvan]

Ура! разобрался в причине маленькой дельты, при подключении датчика нужно избегать прохождение в.ч. проводов близко к друг другу у меня они были рядом на проводе длиной 35 см и на макетной плате))) после разрывания провода на 2 сразу полегчало))). Провел несколько экспериментов с разного размера и формами датчиков - самым эффективным оказался с фольгой с одной стороны шириной полосок по 5 мм и расстоянием между полосками 2 мм, длина рабочей части датчика 150 мм общая 170мм, при этом на воздухе 920, а в воде 0. Покрасил датчик жинским лаком)) в один слой чувствительность оч. высокая, думаю еще пару слоев не повредит, в перспективе думаю взять паркетный лак). Сопротивление между 3,3 и AREF 33к Кварц в уно 16мГц. Буду подбирать экранированный провод для линии до датчика. Попробую при разных покрытиях датчика засовывать это дело в горшок с растишкой и следить за показаниями). Спасибо всем за помощь и советы

[UL7AAjr]

Буду подбирать экранированный провод для линии до датчика.

Сергей, попробуйте телефонный провод ТРП вместо экранированного.

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