Ненавязчивая автоматизация ректификационной установки

Извините за встревание в тему.
Почему не уйти от DSок раз и навсегда?
Один раз взять платиновые и всё..
Само собой АЦП....

экранированной витой парой датчики подключить, то, наверное, даже электросварка рядом не помешает их работеOldBean, 21 Мая 17, 11:33

Не мешает, даже если не экранированной, не далее как вчера варил ) Для ДС-ок потрошу UTP пятой категории, для патчей который гибкий, вытягиваю две пары (шина и питание), немножко их докручиваю, и вручную навиваю их друг на друга. Удобный приятный кабелек получается:

OldBean, я бы всё же предпочел ds-ки на uart вешать. Меньше гимора с программированием.
И какое отношение у тебя ds-ки имеют к i2c я что то не понял.

Почему не уйти от DSок раз и навсегда?71lelik, 21 Мая 17, 12:23

А зачем? Платина + АЦП - это, конечно, круто, надежно, профессионально. Но ds-ки это - очень недорого, очень доступно и очень удобно. Сразу цифра, простая шина и стандартный интерфейс, реализованный везде где угодно. Точность и стабильность работы вполне приемлема. Для домашней винокурни - в самый раз. Все это "перевешивает". И платину и другие более серьезные температурные решения.

Удобный приятный кабелек получается:makh, 21 Мая 17, 12:24

Т.е. и питание и шина каждая независимо обвита землей? Действительно, неплохо! Для варианта "Lite" (с температурным серверком) обязательно такую же себе сделаю. Сейчас у меня просто 3 параллельных провода, оторванные от "ремня", идут. Спасибо!

И какое отношение у тебя ds-ки имеют к i2c я что то не понял.Kotische, 21 Мая 17, 12:47

Если речь идет о "температурном серверке", схема которого чуть выше, то - никакого.

По шине i2c микроконтроллер связан с малинкой. Именно по ней он передает малинке измеренные им температуры. По сути, микроконтроллер - это температурный сервер для малинки. А с самими ds-ками МК связан, естественно, по 1-Wire. Причем, с каждым датчикам по своей отдельной шине 1-Wire. Каждая шина 1-Wire подключена к соответствующему пину одного и того же порта (в данном случае - PB). Поэтому управлять всеми этими датчиками (на разных шинах) можно одновременно (и запускать их, и считывать данные). Как с одним датчиком - т.е. одной командой сразу для всех шин. Программирование здесь почти тривиально - на каждой шине сидит только один датчик. В результате отпадают накладные расходы на адресацию датчиков. 1-Wire - очень простая шина и очень простой протокол. Легко реализуется программно. Тем более, что других забот у МК температурного серверка в общем-то и нет. Да и примеров кода программной реализации 1-Wire на C для AVR-ок в сети прорва.

PS
Шины 1-Wire на прилагаемом рисунке пометил красным. Кстати, где-то на форуме я уже видел подобные решения ("растаскивание" ds-ок по одной на несколько шин 1-Wire). К сожалению, не запомнил автора (в то время для меня это было не актуально). Но, в любом случае, это - уже пройденный кем-то путь.

3 параллельных провода, оторванные от "ремня"OldBean, 21 Мая 17, 14:00

Можно чутка улучшить -- GND-BUS-GND-VCC-GND.

Ну только "чутка" :)
У меня сейчас GND-BUS-VCC. По переменке (наводке) GND и VCC, естественно, замкнуты на малинке (да и на ds-ках, наверняка тоже емкости стоят). Так что они все равно работают как своеобразный экран. Работает шина - да и ладно. А рядом с установкой сварки, да и другого безобразия все равно нет.

Кстати, где-то на форуме я уже видел подобные решения ("растаскивание" ds-ок по одной на несколько шин 1-Wire).OldBean, 21 Мая 17, 14:00

я это делал, на меге8, но не помню что и где про это писал, библиотеки не использовал, полностью все свое было включая 1wire

но не помню что и где про это писалmak, 21 Мая 17, 15:06

Жаль. Ну да ладно. "Переизобретем" еще раз. Напишем и "запомним" в оглавлении темы ;) В общем-то, проблема не самая сложная...

---

PS
Поиском нашел вот здесь. Но только упоминание.

я бы всё же предпочел ds-ки на uart вешать. Меньше гимора с программированием.И какое отношение у тебя ds-ки имеют к i2c я что то не понял.Kotische, 21 Мая 17, 12:47

В чем смысл вешать DS на uart? Тем более в малинке - это дефицит.
Есть чип - мост i2c - w1, есть одноканальный, есть семиканальный.

Если чип моста аппаратный - нет проблем.
Я про програмную реализацию 1w на микроконтроллере говорил.

USART аппаратно формирует временные параметры сигналов 1w. DS-ки крайне негативно относятся к искажению временных параметров сигнала. Если на микроконтроллере выполяется что то ещё кроме опроса датчиков - это важно.
Если на микроконтроллере выполняется ТОЛЬКО формирование сигналов 1w то накаких проблем.

Kotische, В броадкоме, тот который в малине - только один uart, я уж даже коммутатор сделал по распилу опросов на разные нужности.
Программная реализация непосредственно с gpio - ведет к выходу из строя gpio. Там мегадохлые IO.
Аппаратный мост i2c<->w1 тут 2 страницами ранее светили.
Вот еще у меня тут A20 - это да: 6 уартов, gpio жесткие. Но цена....

Тогда, может, вот это:
https://yadi.sk/i/pNgoy9J03JP6cq
I2C мастер 8х1Wire?

цена у txs0108 мягко говоря не очень.sevpro, 20 Мая 17, 23:49

https://m.aliexpress.com/s/item/32469448151.html

Добавлено через 7мин.:

А про ds2482 пишут что есть грабли когда кто то кроме него на шине сидит. Так что на первый взгляд самодельный мост i2c - 1wire на атмеге выглядит перспективнее

Ну или еще смешнее
https://ru.aliexpress.com/...0308.0.0.zLlqP1

Если на микроконтроллере выполняется ТОЛЬКО формирование сигналов 1w то накаких проблем.Kotische, 21 Мая 17, 19:30

На самом деле требования гораздо мягче - если работа микроконтроллера не связана с внешними (аппаратными) прерываниями, требующими немедленной реакции. ;)

Для "температурного серверка" это условие выполняется. Причем, если правильно написать софт, т.е. жестко засинхронизовать работу МК и паузы, естественно, делать не тупо через _delay (таймеров хватает), то бОльшую часть времени (можно посчитать, но так от фонаря - как минимум процентов 90) - МК будет свободен и может заниматься другими делами. Например, вычислять и усреднять по времени дельту, если кому-то нужно. Накапливать и усреднять температуры с датчиков, если температурный ("квантовый" из-за дискретности ds-сок) шум датчика нужно сгладить и т.п. Поэтому этот МК я и называю именно "температурным серверком", а не просто многоканальным мостом i2c-1-Wire. Потому что собираюсь повесить на него дополнительные функции.

Тогда, может, вот это:
https://yadi.sk/i/pNgoy9J03JP6cq
I2C мастер 8х1Wire?Dmi_D, 21 Мая 17, 22:15

Это зависит от решаемой задачи. Если нужен просто многоканальный мастер 1-Wire, причем, для большой серии, то конечно это нормальное решение. Но для единичного устройства/установки проще поставить МК. А если еще настоящий "температурный серверок" (см. предыдущий абзац), то - тем более.

17.X. Вариант LITE. Тупиковые решения

В раздел "Тупиковые решения" я перебросил часть уже опубликованных решений. Это сделано не из-за того, что эти решения совсем уж неработающие, а из-за того, что в процессе работы были найдены более удачные. ИМХО.

---

"Ненавязчивая автоматизация Lite" это шуточное рабочее название нового (в определенном смысле - упрощенного) варианта системы автоматизации ректификационной установки. Это тоже будет иерархическая система с малинкой во главе. Малинка будет иметь небольшой сенсорный дисплейчик для индикации и управления. "Модульки" нижнего уровня иерархии будут выполнены на базе AVR-ок. Они не содержат индикации, кнопочек и не предназначены для автономной работы (как в предыдущей системе). Все функции индикации и интерфейса с пользователем будут переданы малинке. Немножко подробнее об архитектуре варианта Lite - чуть ниже в преамбуле к описанию температруного сервера.

Итак, первый модуль нижнего уровня "Варианта Lite" - это температурный сервер.

17.X.1. Температурный сервер

В выходные появилась возможность закончить "температурный сервер" для варианта Lite. Теперь, наконец-то, мы можем полностью разделить иерархическую систему управления ректификационной установки на два уровня. Первый (нижний) уровень - это устройства, выполняющие низкоуровневые операции в реальном времени (RT - Real Time). К этому уровню относятся контроллеры (ТЭНа и клапана отбора) и датчики (RMS, температуры и давления). "Интеллект" устройств нижнего уровня представлен недорогими 8-битными микроконтроллерами AVR (в данном случае - ATMega328P), способными функционировать в реальном времени. С управляющим компьютером (это - второй уровень иерархии) устройства нижнего уровня связаны по шине I2C. С точки зрения шины I2C, управляющий компьютер является ведущим (Master), а МК нижнего уровня - ведомыми (Slave). Управляющий компьютер выполняет более сложные и громоздкие задачи, не требующие жесткой привязки к реальному времени. К таким задачам относятся: общее управление процессом ректификации, обеспечение пользовательского интерфейса, протоколирование, статистика, аналитика и т.п. Решение этих задач существенно упрощается за счет того, что управляющий компьютер имеет "на борту" достаточно развитую операционную систему (Linux, Windows и т.д.). В качестве управляющего компьютера могут выступать современные микрокомпьютеры (например, замечательная Raspberry Pi aka "Малинка"), планшеты или даже обычные рабочие станции или ноутбуки, имеющие порты и/или адаптеры для работы с шиной I2C.

Итак, что же такое "температурный сервер"?

Температурный сервер представляет собой микроконтроллер ATMega328P с подключенными к пинам порта PD датчиками температуры DS18B20 (не более одного на каждый пин, т.е. всего до 8 датчиков). Каждый пин PD, к которому подключен датчик, имеет подтягивающий резистор 4.7k и образует, таким образом, независимую шину 1-Wire с единственным ведомым устройством. Схема сервера представлена на рисунке ниже.

Управление всеми шинами 1-Wire происходит синхронно. Идентификаторы датчиков DS18B20 (уникальные 64-битные коды-идентификаторы, в миру - "серийники" :) не используются. Никак. Датчики нумеруются соответственно номерам пинов порта PD (от 0 до 7), к которым они подключены. Т.е. датчик, поключенный, например, к PD0 имеет номер 0.

Температурный сервер связан с внешним миром по шине I2C как ведомое (slave) устройство с адресом 0x07 (может быть изменен; константа ADDR). Протокол прикладного уровня выглядит следующим образом:

1. Мaster шины I2C (например, малинка) отправляет по адресу сервера 0x07 байт, равный 0x44. Это число интерпретируется сервером как команда.
2. Сервер, получив эту команду, запускает одновременные циклы преобразования всех подключенных к нему датчиков DS18B20 и, на время преобразования, перестает откликаться на запросы к нему по шине I2C. Остальные устройства, подключенные к этой же шине, естественно продолжают работать в штатном режиме.
3. После завершения преобразования, сервер разрешает доступ к нему по шине I2C для считывания данных (измеренных температур) или - для запуска очередных циклов преобразования температурных датчиков.
4. В текущей версии сервера, температурные данные могут быть считаны одним блоком. Например, при помощи функции read_i2c_block_data питоновского модуля smbus. Считанный блок представляет собой последовательность 17 байтов, содержащих следующую информацию:
     1-й байт - битовая маска наличия датчиков на шинах 1-Wire (1 - датчик
                есть, 0 - датчик отсутствует). Номерация датчиков
                соответствует нумерации пинов порта PD (от 0 до 7), к
                которым подключаются датчики.
     2 и 3 байты - слово, содержащее код температуры 0-го датчика (пин PD0 МК).
                Старший байт - первый. Температура в °C получается путем
                умножения этого кода на 0.0625
     4 и 5 байты - код температуры следующего датчика (с номером 1) и так
                далее... Если датчик отстутсвует, то код равен 65535.

Поскольку вариант Lite ненавязчивой автоматизации планируется выполнить в виде единой платы (шилда), то на данный момент, отработка температурного сервера выполнялась только на макете. Печатная плата будет сделана после отработки всех модулей нижнего уровня. Фотография макета представлена на рисунке ниже.

Программное обеспечение на стороне температурного сервера (firmware) выполняет три основные функции: 1) связь с внешним миром по I2C в качестве ведомого устройства (slave), 2) обеспечение физического уровня протокола 1-Wire, используемого для работы с датчиками DS18B20 и 3) обеспечение прикладного уровня используемых протоколов для управления датчиками и обмена информацией с управляющим микрокомпьютером.

Для реализации протокола I2C используются аппаратные средства микроконтроллера (TWI). Для протокола 1-Wire, в силу нестандартности задачи (параллельная работа до 8 шин на одном МК), используется программная реализация. Большинство фрагментов программы довольно стандартны, просты и достаточно прокомментированы. Поэтому разобраться с их работой, если кому-то потребуется, будет несложно. Исходный код, makefile, готовый hex-файл для прошивки и краткая инструкция по компилированию и прошивке под Linux (Ubuntu) находятся в архиве, прилагаемом к данному топику (файл firmware.zip).

Тестирование температурного сервера производилось при помощи малинки в качестве управляющего компьютера. Тестовый скрипт на язые python прилагается тоже (файл test.py.zip). Пример результата тестирования показан на скриншоте, приведенном ниже.

---

Что можно сказать в качестве выводов? Мне понравилось это устройство (в том числе и сам процесс его разработки :). Помимо "концептуальной чистоты" такой сервер упрощает работу с температурными датчиками и повышает надежность системы. Во-первых, за счет использования 5-вольтовой логики, возрастает помехозащищенность шин 1-Wire. Во-вторых, выход из строя или сбой одного датчика никак не сказывается на работе остальных. Поэтому, для критических измерений, вполне можно дублировать датчики. Да и последствия сильных наводок на шины 1-Wire (если что, не дай Бог!) будут не так обидны: все-таки AVR-ки более, чем на порядок дешевле малинок :)

======================================
Предыдущий топик[/url]  Вернуться к оглавлению  Следующий топик

Отлично, спасибо!

Однако контрольная сумма с DSок не считается и нет алгоритма, если DSка разово глюканула?

Однако контрольная сумма с DSок не считаетсяU-M, 29 Мая 17, 00:29

Да. Сейчас протокол обмена с DS-ками очень упрощен. Читаются только два первых байта с температурами. Конечно, и нет никакого CRC. Просто хотелось побыстрее "почувствовать" usability температурного серверка. Ну, "как бы на практике".

В окончательном релизе firmware температурного серверка, я планирую сделать дополнительный режим непрерывного преобразования (с периодом не более 1 сек) и, главное, - циклический буфер для вычисления скользящих средних всех измеряемых температур и, естественно, вычисление самих скользящих средних. Этим мы снимем некоторые очень раздражающие моменты в алгоритмах управления ректификацией, вызванные все-таки сравнительно большим (0.0626°C) температурным квантом DS-ок. Здесь-то я как раз и собирался отлавливать "сбойные" значения температур (это которые заметно отклоняются от скользящего среднего). ИМХО, это более правильный подход, чем CRC, который контролирует только ошибки канала связи.

---

А сейчас скользящие средние приходится вычислять малинке, причем, с бОльшим интервалом между отсчетами (от4 до 6 сек). Не барское (малинкино) это дело :))) Пусть температурный серверок этим занимается.

---

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

дополнительный режим непрерывного преобразования (с периодом не более 1 сек) и, главное, - циклический буфер для вычисления скользящих средних всех измеряемых температур и, естественно, вычисление самих скользящих средних. Этим мы снимем некоторые очень раздражающие моменты в алгоритмах управления ректификацией, вызванные все-таки сравнительно большим (0.0626°C) температурным квантом DS-ок.OldBean, 29 Мая 17, 05:22

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

Контроллер градусников достаточно мощный, чтобы лопатить непрерывно эти температуры и иметь всегда готовые результаты последних вычислений в ячейках.capsolo, 29 Мая 17, 11:55

Здесь дело не в мощности МК. Дело в том, что у ATMeg-ов нет DMA. Поэтому, при общении по I2C, несмотря на его (TWI) аппаратную реализацию, все равно чуть-чуть приходится задействовать процессор. В частности, - для того, чтобы обновлять буфер порта (регистр TWDR). Если в это время процессор занят критическими операциями с 1-Wire, то возникает конфликтная ситуация. Поэтому избежать периодического блокирования доступа к серверку по I2C на таких AVR-ках вряд ли удастся. Правда это совсем небольшой процент от полного времени. Блокировка доступа к серверку по I2C будет только: 1) во время сброса и обнаружения датчиков, 2) во время самого запуска преобразования и 3) во время чтения данных с DS-ок. Т.е. бОльшую часть времени (750 ms и остаток до конца главного цикла) серверок будет доступен.

Именно поэтому режим, который сейчас реализован, вполне оправдан. Это просто самый простейший способ синхронизации малинки с температурным серверком. Если работы мало и торопиться некуда ;)))