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

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

Вопрос уважаемому магистру OldBean - вот Вы используете для контроля температуры DS18B20, а Вас не смущает, что они довольно таки неточно отображают температуру выше 75ºС? Из моего опыта - десяток датчиков показывают одну и ту же температуру термостата, допустим 80ºС кто в лес, кто по дрова, с разбегом до 1.5ºС кто вверх, кто вниз... Или для процесса ректификации нам всё таки важнее дифферент температуры от установившейся, независимо от абсолютного значения?

Kotobus, это зависит от назначения датчиков и используемых алгоритмов управления. Чаще всего, действительно, важны лишь относительные измерения. Но, к сожалению, не всегда. Например, это не так при регулировании скорости отбора по температуре в кубе. Особенно при малой спиртуозности. Поэтому, конечно хотелось бы использовать более точные датчики. Но удобство и цена DS18B20 - это очень сильные факторы ;)

Например, это не так при регулировании скорости отбора по температуре в кубе.OldBean, 21 Апр. 17, 14:51

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

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

использовать более точные датчикиOldBean, 21 Апр. 17, 14:51

Если будет реализована идея с модулем контроля температуры, то для регистрации кубовой Т° вполне закономерно использовать LM35, калиброванный датчик с погрешностью 0.25-0.75°С в диапазоне -55 - 150°С. Задейсвовать для этого АЦПшный вход ардуинки.
Правда, не знаю, как при этом бороться с помехами, все-таки расстояние от датчика до модуля будет не 10 см... Может, витая пара спасет?

http://www.analog.com/...ets/ADT7410.pdf

В 6мм гильзу можно засунуть как-то так:

Коллеги, мне кажется, что лучше, все-таки, решать проблемы по мере их поступления. Сейчас у меня в архивах номер крайнего лога - 36. Это означает, что с этой системой уже на новом софте (с классами-обертками) проведено 36 полных ректификаций. И еще ни разу во время этих ректификаций я не уперся ни в одну проблему, которая хоть как-то была бы связана с точностью термодатчиков DS18B20 на высоких температурах.

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

Хотелось бы додавить тему опасности использования DS18B20 в таком тонком деле, как ректификация. Согласно документации изготовителя - ошибка измерения при температурах выше 85 - целых ДВА градуса!

Особых проблем в этом действительно нет, оборудование как работало, так и работает, показывает (например) в кубе 91.5 и Вы продолжаете ректифицировать... А там (на самом деле) 93.5, а это уже нарушение технологического процесса.
Для себя на сегодняшний день вижу выход в использовании PT100 (желательно класса А или АА) в паре с преобразователем на основе MAX31865 (это не самое дешевое решение) или хотя бы с преобразователем на основе HX711.

На мой взгляд - это единственный легкодоступный способ получения информации о РЕАЛЬНОЙ температуре.

Приношу заранее извинения, если был излишне нуден.

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

DS18B20 врут, да. Но врут довольно стабильно. Т.е. два пути в наличии -- внесение поправки (в т.ч. на неправильную установку градусника) или подбор датчика. Подбор в смысле экспериментально выбрать удачный (для куба, остальные васче пофик на самом деле). У мну один такой нашолся -- по воде 99.16, точненько как положено для моей высоты над уровнем моря. Но я-то знаю, что если поменять на кубе теплоизоляцию, то придется заново кипятить воду. И выяснять атмосферное давление поточней..

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

Был такой период, когда хотелось точности градусников. Заморачивался с ADT7410, сверхтонкими проводниками, пористым тефлонном, и т.д. По итогам утвердился во мнении, что намного важнее и нагляднее любой точности есть динамика изменения показаний и возможность ее визуализации. Т.е. для гуманоида -- график с перерисовкой в реальном времени, для автомата -- расчет нескольких тенденций за разный период времени. Далласовского датчика для этого более чем достаточно.

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

Т.е. я вовсе не хотел сказать, что точность может быть излишней. Но DS-ка такая удобная штука ,)

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

Кстати, у максима есть кучка специализированных термопарных АЦП, в т.ч. с 1-Wire интерфейсом. Были среди них очень крутые штуки, но подороже. Названия не помню уже, руки до них так и не дошли.

И даже если, то насколько много смысла в сверхточной цифре температуры без такой же точной цифры давления в той же измерительной точке?makh, 26 Апр. 17, 17:45

Я бы сюда добавил еще и точность модели, по которой на основе температуры кипения (и давления) определяется спиртуозность :)  Ибо именно она (и только она) несет адекватную информацию для системы управления ректификацией.

---

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

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

OldBean, у меня проблема с датчиком RMS. Контроллеры ТЭНа и клАпана срабатывают правильно, а RMS глючит. Проводку от малинки до платы проверил. В режиме настройки датчика RMS контрольное число было чуть больше 400 (точно не помню). Настраивал с ЛАТРом в диапазоне 160--230 вольт. Линейность хорошая, показания с Ваттметром совпадают. Что нужно еще проверить? Когда 220в отключено датчик RMS показывает 4.

ZagAl, этот глюк (пропадание старшего бита) проявляется на 3-й малинке. На 2-й, на которой я собственно и разрабатывал систему, его не было. Поэтому сесть и "честно зафиксить" его, к сожалению, руки пока не дошли :(  Но, в качестве врЕменной меры, можно просто уменьшить скорость обмена по i2c. Как это сделать описано здесь.

---

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

OldBean, спасибо за совет. Попробовал, но не помогло. У меня Raspberry Pi Zero. Прошу прощения - 220+то я не подключил! Больше нет времени. Вечером продолжу.

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

1. На индикаторе датчика RMS цифры нормальные?
2. Давайте погоняем тест на каком-нибудь контроллере (ТЭНа или клапана отбора). В цикле пишем в контроллер какие-нибудь числа (от 0 до 255) и через, скажем, секунду читаем их и сравниваем. Нормально или нет?

OldBean, еще раз прошу прощения. С утра торопился и забыл подключить 220 вольт.
Несколько раз прогнал цикл в 255 шагов. Все прекрасно работает.
P.S. Ну и хочется похвастаться - вот такая красота у меня получается. Пока нет датчика давления - еще не пришел. OldBean, спасибо!
P.S.S. Хотя с контроллера клапана возникают ошибки. Может я не правильно команды даю.

Может я не правильно команды даю.ZagAl, 05 Мая 17, 19:29

Вы все правильно делаете.

Давайте повторим последний тест в двух вариантах.
1. Точно в том виде как и был (на скриншоте). Во время теста смотрите на индикаторы контроллеров. На них числа правильные?
2. В цикле между командами чтения u=bus.read... и k=bus.read...  вставьте небольшую задержку и повторите тест. Каков результат?

1. На индикаторах отображения правильные.
2. Ошибка все же возникает и составляет 128. И когда i<128 ошибка не проявляется.

ZagAl, спасибо за тесты. Теперь ясно, что это проблема не локальная (т.е. не только моя, случайная и частная). Поэтому, несмотря на то, что при пониженной скорости все работает более-менее стабильно, желательно все-таки как-то "зафиксить" проблему. Хорошо. Займусь при первой же возможности.

---

Итак, получается такая "феноменология" проблемы:

0. Проблема проявляется на 3-й малинке и на Zero. На 2-й малинке этой проблемы нет. 
1. Суть проблемы: при побайтном чтении малинкой (master) с ардуинки (slave) иногда "пропадает" старший бит. Т.е. вместо 1 считывается 0. Наоборот (1 вместо 0) не бывает.
2. Вероятность ошибки чтения старшего бита быстро падает при уменьшении скорости обмена.
3. Какие-то дополнительный функции, выполняемые ардуинкой (прерывания от таймера, индикация, измерения и управление), никак не сказывается на вероятности пропадания старшего бита. "Голая" ардуинка (в скетче - только обмен по i2c) точно так же теряет старший бит.

PS
В i2c старший бит идет первым. Поэтому гипотеза насчет "затягивания" отпадает. Других соображений о проблеме (почему первый бит данных может "теряться") пока нет...

В прошедшие праздники появилась возможность немного посидеть и поразбираться с пропаданием старшего бита при чтении малинкой байта с ардуинки по i2c. Ниже - краткий отчет и некоторые рекомендации по "лечению" бага.

14.4. Особенности реализации протокола i2c на малинках

Итак, в моем распоряжении две малинки. Одна старенькая Raspberry Pi Model B (512MB). Процессор находится под чипом памяти, поэтому прочитать что на нем написано проблематично. Судя по литературе, должен стоять чип Broadcom BCM2835. Вторая малинка довольно свежая: Raspberry Pi 3 Model B, на чипе написано Broadcom BCM2837RIFBG. Эти малинки будут ведущими устройствами (master) в экспериментах с шиной i2c.

Ведомым устройством (slave) выступает Arduine Pro Mini 5V/16MHz. Скетч самый примитивный. Для обмена по i2c используется библиотека Wire. Две callback-функции: одна принимает байт с шины i2c и запоминает его в глобальной переменной, другая посылает байт (значение этой переменной) на шину.

Малинка и ардуинка связана друг с другом тремя проводками (длиной около 20 см). Это земля, шина данных (SDA) и шина синхронизация (SCL). К этим же проводкам подключены щупы осциллографа для регистрации кадров обмена по шине i2c. Подтягивающие резисторы расположены на плате малинки.

Тестовый скрипт на малинке (на питоне) выполняет следующее. После инициализации шины i2c производится запись одного байта в ардуинку (ее адрес на шине - 0x06). Для конкретики - это 255. Далее в цикле производится периодическое чтение одного байта с ардуинки, сравнение полученного значения с тем что должно быть (в нашем случае - 255), подсчет количества ошибок, если таковые возникают, и выдача всего этого добра на консоль.

Прежде чем переходить к результатам экспериментов, давайте вспомним некоторые детали работы шины i2c. На эту тему существует очень много популярной информации в Сети. Поэтому мы рассмотрим только наш конкретный случай - чтение байта (со значением 255) с ведомого устройства, имеющего адрес 0x06. Кадр одного такого обмена представлен на рисунке ниже. Те моменты времени, когда уровнем шин SDA и SCL управляет ведущее устройство (малинка), обозначены красным, а когда ведомое (ардуинка) - синим.

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

Итак, после старта, мастер выдает на шину 7-битный адрес ведомого (начиная со старшего бита) и команду (чтение или запись) в 8-м бите. Высокий уровень означает, что мастер будет читать данный от ведомого. Это - наш случай. После этого ведомый должен "прижать" шину SDA (Ack) к низкому уровню, подтвердив, что он жив и готов общаться. Поскольку он (ведомый) получил команду чтения, то он начинает готовить данные. Если ведомый - тормоз и не успевает приготовить данные к началу следующего строба, он может "придержать" низкий уровень на шине синхронизации (см. синий горизонтальный фрагментик на нижней диаграмме - SCL). Мастер в этом случае должен подождать, пока ведомый приготовит данные и выставит первый (старший) бит на шину SDA. После этого ведомый "отпускает" шину синхронизации SCL и мастер начинает генерировать последовательность стробов, синхронно с которыми ведомый выставляет на шину данных (SDA) биты передаваемого байта. После передачи последнего (младшего) бита, ведомый оставляет высокий уровень во время Ack. Это означает, что все данные переданы и мастер может завершать обмен (команда "стоп").

Если в качестве мастера мы подключим старую малинку, на которой никогда никаких проблем с пропаданием битов не наблюдалось, и запустим описанный выше тест, то мы должны увидеть именно такую картинку, как и было показано на рисунке выше. И действительно, именно такой малюнок мы и видим на осциллограмме, приведенной на следующем рисунке. На этой осциллограмме зафиксирован один кадр обмена по шине i2c старой малинки и ардуинки. Зелененький сигнал - шина данных (SDA), желтенький - шина синхронизации (SCL).

Мы видим, что все работатет именно так, как и должно быть. Что же произойдет, если теперь в качестве мастера мы подключим новую (т.е. 3-ю) малинку? К сожалению, картина радикально изменяется.

Во-первых, во всем диапазоне скоростей обмена (baudrate), которые я протестировал (от 9600 до 160000) малинка самопроизвольно, по непонятным причинам переключает частоту синхроимпульсов с установленной (параметр baudrate в файле /etc/modprobe.d/i2c.conf) на пониженную (примерно на треть) частоту и обратно. Т.е. несколько секунд малинка-мастер работает на номинальной частоте. Затем переключается на пониженную. На пониженной тоже работает несколько секунд и вновь переключается обратно на номинальную. И так далее. Причем строгой периодичности нет. Интервалы работы на номинальной и пониженной скоростях "гуляют" как попало.

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

На правой диаграмме как раз изображен кадр обмена на пониженной скорости. Мы видим, что один синхроимпульс очень короткий (обведено красным). Это - следствие того, что малинка просто игнорирует clock stretching (удерживание шины SCL на низком уровне) со стороны ардуинки. Действительно, переходя к чтению данных с шины, малинка, как ни в чем ни бывало, выдает обычный импульс синхронизации. Но данные-то еще не готовы и бедная ардуинка держит низкий уровень на шине SCL, пытаясь предложить малинке немного подождать. Но малинка этого не замечает и тупо считывает ноль при, как бы, высоком уровне (но это малинка-мастер так думает !!!) синхроимпульса на шине SCL. А на самом деле в это время на SCL низкий уровень. Его удерживает ардуинка, лихорадочно подготавливающая свои данные ;) Ну вот, наконец, ардуинка подготовила данные, выставила старший бит на шину SDA (в нашем случае - высокий уровень) и наконец-то "отпустила" шину синхронизации SCL. По идее, малинка только сейчас (!) должна начать формировать строб для чтения старшего бита. Но увы, поезд уже ушел. Некорректный старший бит уже тупо считан малинкой. Кстати, "огрызок" того злополучного синхроимпульса, после того, как ардуинка "отпустила" шину SCL, мы как раз и видим в виде короткого строба (который на рисунке обведен красным).

Интересно, что при baudrate меньше 64000, ошибка чтения возникает при другой ситуации - на номинальной скорости. А на пониженной чтение происходит без ошибок.

Итак, механизм пропадания старшего биты мы вскрыли. Что делать дальше? Увы, поскольку протокол i2c в малинках (точнее - в чипах Broadcom BCM2837) реализован аппаратно, то некорректная работа с clock stretching - это явный аппаратный баг самого чипа. Порывшись в Сети, я нашел упоминание об аналогичной проблеме. Только не для BCM2837 (который установлен в 3-й малинке), а для Broadcomm BCM2835. Смешно, но у меня-то как раз 2835 (это который на старой малинке) работает безупречно! В общем - гнило что-то в Датском королевстве... Вот этот ресурс: Raspberry Pi I2C clock-stretching bug. Особенно умилила фраза:"Don't expect help from the Raspberry Pi creators or from Broadcomm. They know the problem (at least partially), but they unfortunately did neither document nor solve it."

Итак, для 2835 этот баг существует и зарегестрирован. Обидно, что и в 2837-м чипе разработчики этот глюк так и не исправили. Так что единственное, что нам остается - воспринимать его просто как некую "особенность" реализации i2c на 3-й малинке и, судя по экспериментам, проведенным коллегой ZagAl еще и на Zero ;)))

Как же бороться с этой "особенностью"? Можно предложить три простых варианта решения.

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

2. Если понижение скорости по каким-то причинам не устраивает, можно наоборот - повысить скорость (baudrate). Точно таким-же образом, как описано в предыдущем варианте. Смешно, но при повышении baudrate до 128000 и выше (в разумных пределах, конечно! :) ошибка, связанная с пропаданием старшего бита исчезает! Возможно это связано с тем, что растяжка (clock stretching) начинает превышать пол-периода синхроимпульсов и Broadcom начинает ее корректно отрабатывать? Тем не менее, периодическое переключение частоты синхронизации с номинальной на пониженную все равно происходит. Но ошибок нет ни на номинальной скорости, ни на пониженной. Ниже представлены осциллограммы двух кадров с номинальной частотой (128 кГц) и пониженной (80.65 кГц). Baudrate малинки установлен на 128000. По осциллограммам видно, что BCM2837 отрабатывает clock stretching в обоих случаях корректно.

Этот вариант я не использовал в реальной работе, но проверил на тестах. На миллион обменов - ноль ошибок. Так что в реальной жизни это способ тоже должен работать.

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

Ну вот, пожалуй, и все по поводу этой "особенности" реализации i2c на чипах BCM2837 от Broadcom.

---

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