Микроконтроллеры, АЦП, память и т.д Темы касающиеся микроконтроллеров разных производителей, памяти, АЦП/ЦАП, периферийных модулей... |
15.06.2017, 03:34
|
|
Прописка
Регистрация: 25.03.2013
Адрес: Глубокое замкадье
Сообщений: 216
Сказал спасибо: 3
Сказали Спасибо 71 раз(а) в 55 сообщении(ях)
|
Re: Надежность температурных датчиков
Странно это все.
У меня они работали до тех пор, пока плавилась термоусадка и коротило ноги... После замены термоусадки на трубочки из стеклоткани продолжали работать.
Полностью дохли только одним способом: в цеху пошел дождь, датчики оказались в воде, ноги отгнили около корпуса...
Сообщение от avgust75
|
Не все датчики выдерживают тайминги по удержанию лог. 0,1.
|
Не сталкивался. А вот с растянутыми таймингами из-за большой емкости длинного шлейфа сталкивался. Датчик выдавал короткий импульс, а шлейф заряжался так долго, что к микроконтроллеру приходил уже значительно более длинный. Правда все укладывалось в диапазон из datasheet.
|
|
|
|
15.06.2017, 11:46
|
|
Прописка
Регистрация: 02.03.2010
Сообщений: 139
Сказал спасибо: 12
Сказали Спасибо 49 раз(а) в 26 сообщении(ях)
|
Re: Надежность температурных датчиков
Вставлю свои 5 копеек.
Любая линия передачи данных требует правильного согласования (терминирования) на приемной стороне. И как рукой снимет всякие затяжки и искажения.
И про защиту уже было тут сказано - хотя бы стабилитрон с резистором, да нужен. Молния наводит в любом проводнике значительный потенциал относительно земли, из за сильно переменного (импульсного) электрического поля.
|
|
|
|
17.06.2017, 01:45
|
|
Частый гость
Регистрация: 10.09.2010
Адрес: Резиновая
Сообщений: 45
Сказал спасибо: 3
Сказали Спасибо 14 раз(а) в 12 сообщении(ях)
|
свои 5 копеек
ну и я встану в очередь, наблюдателей-практиков.
практически то, что тут звучало часто - на мой взгляд имеет место быть.
в первую голову - софт. причём как тут уже прозвучало - не все датчики попадают в тайминг - ну это и понятно, они заняты другим делом = тупо подсчитывают переключения... могут немного и опоздать. посему протокол нужно немного корректировать по временным фронтам (но в основе конечно-же даташит). чтоб это прочуствовать на своей шкуре - достаточно подключить кабель в несколько десятков метров.
подключаете правильно, один порт = один датчик. для аппаратуры а не понтов это идеальная архитектура (простота в диагностике и замене, на объекте эксплутационщики будут благодарны всегда), если ещё и разъём а не под винт - милое дело, но надо помнить про окисление и влагу.
по нагрузочному резистору. только в одном даташите он нарисован явно у МК. отсюда маленький финт ушами - хотите вытащить ышо пару десятков метров, когда уже в притык - переносите резистор (сотни ом уже) к датчику явно.
по поводу дохнут. как тут и многие говорили - не встречал. из защиты со стороны МК либо растяжка срезающая пики, либо сборка от Далласа родная. но на рассыпухе вроде как по практичнее, но по току выходит достаточно пузатенькие стабилитроны.
по поводу сбоев... имею многолетний опыт юзанья 1821 - он имеет одну сотую дискретности, в отличае от 20 - она 6 сотых с хвостиком. но 21 не имеет ЦРЦ. Софтово добиваюсь 100% надёжности (на основании опыта чётко заявляю - проблема именно в ПЕРЕДАЧЕ!!! Далее думаю сами догадаетесь ). У Вас попроще - есть ЦРЦ. Читать можно до совпадения. Сканирование постоянное - один раз в 0,8 секунды где-то. Встречающиеся в инете сказки про разогрев датчиков НЕ замечал (эксперименты ставил периодически, не раз и не два десятков раз. он есть но в пределах десятых градуса, около 0,2 по памяти сейчас скажу...) Думаю народ сталкивается с дрейфом по питалову, при паразитной запитке (только так могу объяснить заявления дрейфа на градусы).
алгоритм сканирования переделывал несколько раз. Сейчас практически в коде определяю только ножки и набор команд идущие на сканирование (типа макросов), если требуется перейти с 21 на 20 к примеру. всё остальное асинхронно. даже 51 серия спокойно протаскивает такой подход. сканирование по таблице, фильтрация помех, алгоритм преобразования из параллельных бит (сразу до 8 в параллель в лёгкую. но на практике больше 6 не приходилось.) в свои буфера - то на прерывании, сам расчёт естественно в основной ветке. при расчёте так-же формируется вспомогательная инфа для дальнейшего анализа. для 21 немного больше обвеса по электронике - они имеют неприятный эффект перехода в режим термостата при помехе. увы и ах... но замены им к сожалению нет... у Вас этого нет - баба с возу...
как то так
с уважением
(круглый)
Последний раз редактировалось kolobok0; 17.06.2017 в 01:55.
|
|
|
Эти 3 пользователя(ей) сказали Спасибо kolobok0 за это сообщение:
|
|
|
20.06.2017, 01:17
|
|
Прописка
Регистрация: 03.02.2005
Адрес: между степью и рекой
Сообщений: 163
Сказал спасибо: 10
Сказали Спасибо 81 раз(а) в 42 сообщении(ях)
|
Re: Надежность температурных датчиков
Добавлю в коллекцию ещё и свои грабли: - Несколько сотен контроллеров термометрии моей разработки успешно трудятся на зернохранилищах. Правда, на отработку суммарно ушло ~пару лет, и всё равно есть куда развиваться
- Каждый контроллер - это 13 каналов One-Wire, на канале - до 30 далласов. Длина каждой линии - метров до 80. И работает ведь!
- Как показал опыт и исследования, не существует "единственно правильного" момента семплирования состояния линии при считывании битов для произвольной ёмкости линии. Те "15 мкс" от начала бита, что предлагает "Даллас" в своей докции, справедливы для "локального" датчика. Когда же добавляется ёмкость линии, времянки растягиваются, мастер через 15 мкс "увидит" лог. "0" независимо от того, что хочет передать датчик. Можно, конечно, исправлять в программе, "отодвигать" момент считывания. Но тогда настаёт момент, когда перестаёт читаться локальный датчик - он через 45 мкс уже "отпускает" линию. Поэтому, пришлось внедрить систему автоподстройки момента семплирования по каждому из каналов. После окончания "Reset pulse" мастер замеряет время "восстановления" линии, и потом его использует для оценки входного сигнала.
- Само собой, необходимо для длинных линий принимать меры по подавлению "звона". Несмотря на то, что "тактовая частота" OneWire совсем небольшая, выходной каскад на ножке современного микроконтроллера переключается быстро, выдаёт резкий фронт и генерирует волну в линии. Так что если всё же не хотите ставить специально заточенный драйвер линии с ограничением времени нарастания, то хотя бы поставьте последовательно с ножкой МК резистор 47...100 Ом. Но лучше драйвер!
- Когда к одному контроллеру подключается несколько "веток", их взаимные связи начинают давать "антенный эффект". Всяческие помехи и наводки резко усиливаются. Необходимо принимать меры по развязке каналов по ВЧ. В идеале - гальваноразвязка каждого канала, но это уж очень громоздко выглядит...
Ну и без запоминающего осциллографа тут, конечно, ничего толкового не выйдет. Увы, "шина" OneWire предназначалась исходно совсем не для длинных линий, и попытка использовать её не по назначению оборачивается проблемами и плясками с бубном.
__________________
Паяю помаленьку...
|
|
|
Эти 7 пользователя(ей) сказали Спасибо GrayCatt за это сообщение:
|
|
|
21.06.2017, 11:03
|
|
Частый гость
Регистрация: 05.10.2007
Сообщений: 19
Сказал спасибо: 0
Сказали Спасибо 3 раз(а) в 3 сообщении(ях)
|
Re: Надежность температурных датчиков
Я на таких датчиках строил линию в 600м в коробе по силовым проводам. К вышесказаному добавлю, что много зависит еще от места установки датчика от конца линии. Если быть честным то при испытании в лаборатории все работало, все датчики (~25шт) стояли на конце 600м бухты. Когда кабель проложили в короб и поставили распределенно начались глюки. Проблему решила статья, счас не вспомню как называлась но, смысл ее в том, что решение не только программное но и аппаратное.
1. защитные цепи по питанию и линии связи.
2. дополнительные емкости на питание на каждый датчик.
3. программное определение времени прихода единицы и нуля с постоянной коррекцией, для КАЖДОГО датчика.
В общем поищите статью.
Справедливости ради кабель был типа КВВГ 3 медных жилы.
|
|
|
|
Ваши права в разделе
|
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения
HTML код Выкл.
|
|
|
Часовой пояс GMT +4, время: 12:28.
|
|