[Программирование микроконтроллеров, Схемотехника, Производство и разработка электроники] Как мы контроллер управления элементами наружной рекламы делали (часть 2)
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
В предыдущей части статьи мы рассмотрели этап начала проектирования системы. Сейчас я хочу рассказать какое устройство получилось в итоге.
Часть 1
Часть 2
В обсуждение первой части был затронут вопрос измерения напряжения и тока. Поэтому я решил осветить его более подробно. Как я уже писал ранее, датчиками напряжения и тока у нас в схеме являются трансформаторы. Для измерения напряжения используется миниатюрный трансик BV 201 0145, а для датчика тока AC-1020:
С них снимаются напряжения, которые оцифровываются встроенным в микроконтроллер АЦП. Аналоговая часть показана ниже:
Датчик тока нагружается на резистор R3. Стабилитрон VD3 защищает от резких всплесков напряжения, вызванных короткими бросками тока. Резисторы R2, R4 задают «нулевую точку» в районе 1,8В. Аналогично сделано для трансформатора напряжения. Только там делитель на резисторах R8 и R10, т. к. трансформатор в нашем случае выдаёт номинальное напряжение 12 В.
Оцифровку мы осуществляем с частотой 1000 Гц в течение 200 мс. На основе полученных значений рассчитываем RMS. Быстрый расчёт квадратов значений мы производим прямо в прерывании. После накопления 200 выборок уже в основном цикле программы осуществляется окончательный расчёт с использованием чисел с плавающей точкой.
Для чего нужно измерение RMS и как его лучше сделать хорошо описано вот в этой статье.
Я уже не раз писал, что при разработке наших устройств мы всегда стараемся максимально использовать самые обычные электронные компоненты, чтобы с одной стороны снизить себестоимость, а с другой стороны не иметь проблем с их поставкой при производстве серии. В данной разработке все используемые резисторы имеют 5% допуск. Естественно, из-за такой погрешности изделия после производства имели большую ошибку при измерении напряжения и тока. Данная ошибка устранялась на автоматизированном калибровочном стенде. «Стенд», конечно, звучит немного громко, но свою функцию он исполняет как надо. Состоит стенд из следующих компонентов:
- Набор из трёх галогеновых ламп мощностью по 500 Вт
- Датчик тока, описанный выше
- Электросчётчик Энергомера СЕ102М
- Преобразователь USB-RS-485
- Автоматический выключатель
Счётчик мы используем в качестве образцового измерителя напряжения в сети и тока нагрузок. Модель СЕ102М очень удобна тем, что, во-первых, подключается всего двумя проводами к преобразователю USB-RS-485 (внутри счётчика имеется собственный преобразователь питания), а, во-вторых, не требует для считывания данных ввода серийного номера. Вроде мелочи, но удобства в пользовании счётчиком они прибавляют.
Протокол обмена хорошо описан в руководстве от производителя. Так что сложностей с программной реализацией не возникало.
Кстати, по счётчикам можно отдельную небольшую статью написать. В своё время я с ними плотно работал, в итоге в некоторых наших устройствах реализована поддержка четырёх популярных моделей: Инкотекс-СК «Меркурий 206», Энергомера «СЕ102», Энергомера «СЕ102М» и IEK «STAR 104/1».
Общий вид стенда получился такой:
Для автоматизации была разработана несложная программа, которая считывает данные со счётчика, управляем встроенными реле контроллера и автоматически подбирает коэффициенты для измерителя тока и напряжения:
Обычно мы используем штрих-коды для серийных номеров наших устройств. Их очень удобно вводить при помощи сканера штрих-кодов:
Но в данном случае девайс был заказным, и заказчик попросил выполнить серийник просто в виде крупных цифр на лицевой панели.
Программа по итогу калибровки сохраняет все данные в нашей внутренней системе. Там записывается кто, когда что проверял и соответствующий список параметров. Самые важные это серийный номер и MAC-адрес.
Кстати, по поводу MAC-адресов. Мы покупаем их в виде микросхем 24AA025E48-I/SN производства Microchip. При оптовой закупке они обходятся недорого, при этом очень удобны в использовании. MAC-адрес считывается по интерфейсу I2C.
Теперь что касается связи с сервером. На начало разработки основной функционал у нас уже имелся. Это несложный Web-сервис, написанный на ASP.net и отдельная серверная программа для обмена данными с «железом». Каждый контроллер раз в минуту передаёт информационный пакет по протоколу UDP. Серверное ПО разбирает его, сохраняет данные в базе (с «прореживанием» до раза в час) и дополнительно запоминает внешний IP-адрес и порт, с которого пришёл пакет. Это нужно для управления контроллером с сервера.
Так как фактически 100% устройств расположены за NAT, то требуется учитывать некоторые особенности. Основная из них заключается в том, что некоторые NAT’ы имеет малый тайм-аут для выделения внешнего порта клиенту (менее минуты). Процент таких по нашей статистике не очень большой, но это в любом случае приводит к необходимости уменьшения интервала отправки данных мониторинга от контроллера на сервер для «поддержания» выделенного порта.
Сразу напишу почему мы используем именно UDP-, а не TCP-соединение, хотя наше устройство, естественно, имеет реализацию обоих протоколов. Выбор UDP обосновывается всего лишь простотой использования и малыми вычислительными затратами как со стороны контроллера, так и со стороны сервера. Да, он не гарантирует доставку пакетов данных, но нужно понимать, что это легко реализуется протоколом более высокого уровня, который работает поверх UDP. Кроме того, при передаче данных мониторинга потеря нескольких пакетов в сутки абсолютна несущественна, особенно учитывая, что при сохранении в базу мы их всё равно «прореживаем» и сохраняем данные только раз в час. А вот при удалённом управлении контроллером, например, при включении/выключении реле в ручном режиме, работает система «запрос-ответ» и осуществляется несколько попыток отправки команды.
Помимо этого через сервер у нас реализовано удалённое обновление «прошивок» контроллеров. Оно так же работает по UDP. Правда обновление работает в полуавтоматическом режиме. Всё таки нехорошо запускать его в автомате в произвольный момент, так как это может привести к проблема в работе у конечных пользователей. Представьте как они удивятся, если средь бела дня Ethernet-реле отключить у них какую-то нагрузку и перезапуститься :-)
В заключение хочу сказать, за последние два года мы произвели почти тысячу таких устройств. Все она находятся в «онлайне». Ещё около двух тысяч других контроллеров также постоянно общаются с нашим сервером. В целом всё работает достаточно устойчиво. Хотя функционал мы, конечно, постоянно расширяем. Например, недавно мы выпустили моб. приложение для удалённого управления нашими устройствами через Интернет. Но о нём напиши как-нибудь в следующий раз…
===========
Источник:
habr.com
===========
Похожие новости:
- [Производство и разработка электроники, История IT, Звук] Где производят аудиотехнику: репортажи с заводов и история аудиобрендов — 10 избранных материалов
- [Программирование микроконтроллеров, DIY или Сделай сам] Учим железки разговаривать, или ESP32 DAC и немного таймера
- [Разработка мобильных приложений, Разработка под Android, Монетизация мобильных приложений, Медийная реклама] Монетизация рекламного трафика в мобильной экосистеме Huawei
- [Программирование микроконтроллеров] Сравнение компиляторов ARMCC, IAR и GCC
- [Программирование, Разработка под iOS, Разработка мобильных приложений] SPM: модуляризация проекта для увеличения скорости сборки
- [Визуализация данных, Производство и разработка электроники, Научно-популярное, Физика] Узреть незримое: визуализация излучений среднего инфракрасного диапазона
- [Тестирование мобильных приложений, Машинное обучение, Аналитика мобильных приложений, Научно-популярное] Кто сказал «мяу»: бывший разработчик из Amazon создал переводчик с кошачьего
- [Информационная безопасность, Управление разработкой, Управление продуктом, Софт] Жизнь до и после Scrum в разработке B2B продуктов
- [Разработка мобильных приложений, Разработка под Android] Как исправить баг с Drawable.setTint в API 21 Android SDK
- [Работа с 3D-графикой, Отладка, Тестирование игр, Прототипирование, Управление персоналом] История о желании думать, работать и творить
Теги для поиска: #_programmirovanie_mikrokontrollerov (Программирование микроконтроллеров), #_shemotehnika (Схемотехника), #_proizvodstvo_i_razrabotka_elektroniki (Производство и разработка электроники), #_kontroller (контроллер), #_reklama (реклама), #_razrabotka (разработка), #_rele (реле), #_blog_kompanii_spetspromdizajn (
Блог компании СпецПромДизайн
), #_programmirovanie_mikrokontrollerov (
Программирование микроконтроллеров
), #_shemotehnika (
Схемотехника
), #_proizvodstvo_i_razrabotka_elektroniki (
Производство и разработка электроники
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 19:16
Часовой пояс: UTC + 5
Автор | Сообщение |
---|---|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
В предыдущей части статьи мы рассмотрели этап начала проектирования системы. Сейчас я хочу рассказать какое устройство получилось в итоге. Часть 1 Часть 2 В обсуждение первой части был затронут вопрос измерения напряжения и тока. Поэтому я решил осветить его более подробно. Как я уже писал ранее, датчиками напряжения и тока у нас в схеме являются трансформаторы. Для измерения напряжения используется миниатюрный трансик BV 201 0145, а для датчика тока AC-1020: С них снимаются напряжения, которые оцифровываются встроенным в микроконтроллер АЦП. Аналоговая часть показана ниже: Датчик тока нагружается на резистор R3. Стабилитрон VD3 защищает от резких всплесков напряжения, вызванных короткими бросками тока. Резисторы R2, R4 задают «нулевую точку» в районе 1,8В. Аналогично сделано для трансформатора напряжения. Только там делитель на резисторах R8 и R10, т. к. трансформатор в нашем случае выдаёт номинальное напряжение 12 В. Оцифровку мы осуществляем с частотой 1000 Гц в течение 200 мс. На основе полученных значений рассчитываем RMS. Быстрый расчёт квадратов значений мы производим прямо в прерывании. После накопления 200 выборок уже в основном цикле программы осуществляется окончательный расчёт с использованием чисел с плавающей точкой. Для чего нужно измерение RMS и как его лучше сделать хорошо описано вот в этой статье. Я уже не раз писал, что при разработке наших устройств мы всегда стараемся максимально использовать самые обычные электронные компоненты, чтобы с одной стороны снизить себестоимость, а с другой стороны не иметь проблем с их поставкой при производстве серии. В данной разработке все используемые резисторы имеют 5% допуск. Естественно, из-за такой погрешности изделия после производства имели большую ошибку при измерении напряжения и тока. Данная ошибка устранялась на автоматизированном калибровочном стенде. «Стенд», конечно, звучит немного громко, но свою функцию он исполняет как надо. Состоит стенд из следующих компонентов:
Счётчик мы используем в качестве образцового измерителя напряжения в сети и тока нагрузок. Модель СЕ102М очень удобна тем, что, во-первых, подключается всего двумя проводами к преобразователю USB-RS-485 (внутри счётчика имеется собственный преобразователь питания), а, во-вторых, не требует для считывания данных ввода серийного номера. Вроде мелочи, но удобства в пользовании счётчиком они прибавляют. Протокол обмена хорошо описан в руководстве от производителя. Так что сложностей с программной реализацией не возникало. Кстати, по счётчикам можно отдельную небольшую статью написать. В своё время я с ними плотно работал, в итоге в некоторых наших устройствах реализована поддержка четырёх популярных моделей: Инкотекс-СК «Меркурий 206», Энергомера «СЕ102», Энергомера «СЕ102М» и IEK «STAR 104/1». Общий вид стенда получился такой: Для автоматизации была разработана несложная программа, которая считывает данные со счётчика, управляем встроенными реле контроллера и автоматически подбирает коэффициенты для измерителя тока и напряжения: Обычно мы используем штрих-коды для серийных номеров наших устройств. Их очень удобно вводить при помощи сканера штрих-кодов: Но в данном случае девайс был заказным, и заказчик попросил выполнить серийник просто в виде крупных цифр на лицевой панели. Программа по итогу калибровки сохраняет все данные в нашей внутренней системе. Там записывается кто, когда что проверял и соответствующий список параметров. Самые важные это серийный номер и MAC-адрес. Кстати, по поводу MAC-адресов. Мы покупаем их в виде микросхем 24AA025E48-I/SN производства Microchip. При оптовой закупке они обходятся недорого, при этом очень удобны в использовании. MAC-адрес считывается по интерфейсу I2C. Теперь что касается связи с сервером. На начало разработки основной функционал у нас уже имелся. Это несложный Web-сервис, написанный на ASP.net и отдельная серверная программа для обмена данными с «железом». Каждый контроллер раз в минуту передаёт информационный пакет по протоколу UDP. Серверное ПО разбирает его, сохраняет данные в базе (с «прореживанием» до раза в час) и дополнительно запоминает внешний IP-адрес и порт, с которого пришёл пакет. Это нужно для управления контроллером с сервера. Так как фактически 100% устройств расположены за NAT, то требуется учитывать некоторые особенности. Основная из них заключается в том, что некоторые NAT’ы имеет малый тайм-аут для выделения внешнего порта клиенту (менее минуты). Процент таких по нашей статистике не очень большой, но это в любом случае приводит к необходимости уменьшения интервала отправки данных мониторинга от контроллера на сервер для «поддержания» выделенного порта. Сразу напишу почему мы используем именно UDP-, а не TCP-соединение, хотя наше устройство, естественно, имеет реализацию обоих протоколов. Выбор UDP обосновывается всего лишь простотой использования и малыми вычислительными затратами как со стороны контроллера, так и со стороны сервера. Да, он не гарантирует доставку пакетов данных, но нужно понимать, что это легко реализуется протоколом более высокого уровня, который работает поверх UDP. Кроме того, при передаче данных мониторинга потеря нескольких пакетов в сутки абсолютна несущественна, особенно учитывая, что при сохранении в базу мы их всё равно «прореживаем» и сохраняем данные только раз в час. А вот при удалённом управлении контроллером, например, при включении/выключении реле в ручном режиме, работает система «запрос-ответ» и осуществляется несколько попыток отправки команды. Помимо этого через сервер у нас реализовано удалённое обновление «прошивок» контроллеров. Оно так же работает по UDP. Правда обновление работает в полуавтоматическом режиме. Всё таки нехорошо запускать его в автомате в произвольный момент, так как это может привести к проблема в работе у конечных пользователей. Представьте как они удивятся, если средь бела дня Ethernet-реле отключить у них какую-то нагрузку и перезапуститься :-) В заключение хочу сказать, за последние два года мы произвели почти тысячу таких устройств. Все она находятся в «онлайне». Ещё около двух тысяч других контроллеров также постоянно общаются с нашим сервером. В целом всё работает достаточно устойчиво. Хотя функционал мы, конечно, постоянно расширяем. Например, недавно мы выпустили моб. приложение для удалённого управления нашими устройствами через Интернет. Но о нём напиши как-нибудь в следующий раз… =========== Источник: habr.com =========== Похожие новости:
Блог компании СпецПромДизайн ), #_programmirovanie_mikrokontrollerov ( Программирование микроконтроллеров ), #_shemotehnika ( Схемотехника ), #_proizvodstvo_i_razrabotka_elektroniki ( Производство и разработка электроники ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 19:16
Часовой пояс: UTC + 5