Если для "фиксация" уставки и измерения текущей температуры используется один и тот же датчик температуры (обычно так и есть), то его калибровка не обязательна. То же касается и давления. В формуле для коррекции используется разность давлений. Поэтому датчик давления тоже можно не калибровать. Главное, чтобы датчики давали цифры в градусах Цельсия и мм.рт.ст. соответственно. В противном случае нужно изменить коэффициент в формуле коррекции уставки. Под те единицы, в которых работают датчики.
Примечание. Здесь под калибровкой понимаем согласование абсолютных показаний датчиков с соответствующими эталонами.
ys1797
Доцент
Санкт-Петербург
1K 339
Отв.141 19 Марта 17, 00:46
бнаружилась еще одна несовместимость малинок "снизу вверх" - на новых малинках (Raspberry Pi 3 model B) "заглючила" многопоточная реализация циклов преобразования датчиков DS18B20.OldBean, 01 Марта 17, 08:26
Сегодня детально изучал: drivers/w1/w1.c drivers/w1/slaves/w1_therm.c
Принципиально, если на ds18*20 подается питание, то задержка в 750 мс не производится. По умолчанию тип питания спрашивается у самого датчика, если он сказал, что есть внешнее питание - задержка не производится.
что заставляет начать процесс измерения температуры не всех датчиках, которые подключены к мастеру. Далее, я без задержек читаю температуру с каждого из датчиков - это 28 мСек на датчик. Но все это имеет смысл, если используется паразитное питание. Иначе профит всего 10 мСек на датчик, что при моих 4х - фигня.
Трейды, по моему мнению. не дадут прирост, т.к. в процессе чтения температуры на шину ставится mutex_lock(), что заблочит параллельные обращения.
C-Bell
Научный сотрудник
Улан-Удэ
1.8K 1.3K
Отв.142 19 Марта 17, 04:03
Я сделал небольшой кернел хакys1797, 19 Марта 17, 00:46
можно подробнее где и как сделал?
makh
Профессор
Sаmara
2.1K 1K
Отв.143 19 Марта 17, 05:16
Далее, я без задержек читаю температуру с каждого из датчиковys1797, 19 Марта 17, 00:46
Т.е. читаешь старый скратчпад. Результат запущенных перед чтением измерений появится там позже.
1999 -- timestamp, ms; посылаем в шину SKIP_ROM и CONVERT_T и читаем сенсоры первый раз, в скратчпаде reset-state. 2844B009060000BA<85.0000 28F2362403000080<85.0000 2891022403000081<85.0000 2344 -- второй раз читаем, та же фигня. Задержку создает поиск сенсоров на шине, чтение, вывод, и отправка в шину SKIP_ROM и CONVERT_T. 2844B009060000BA<85.0000 28F2362403000080<85.0000 2891022403000081<85.0000 2690 -- первый результат имзмерений, прикидываем время. 2844B009060000BA<17.3750 28F2362403000080<17.3750 2891022403000081<17.5625 3035 -- те же яйца. 2844B009060000BA<17.3750 28F2362403000080<17.3750 2891022403000081<17.5625 3380 -- второй результат измерений. 2844B009060000BA<17.3750 28F2362403000080<17.3750 2891022403000081<17.5625 3725 -- снова он же. 2844B009060000BA<17.3750 28F2362403000080<17.3750 2891022403000081<17.5625 4070 -- третий результат измерений, ну и т.д. 2844B009060000BA<17.3750 28F2362403000080<17.4375 2891022403000081<17.5625
Т.е. реально датчик отрабатывает быстрее, чем заявленных производителем 750 мс. Несущественно быстрее.
Добавлено через 11мин.:
Можно, конечно, представить себе контекст, в котором был бы уместен такой подход. Но в общем случае, ИМХО, нам нужны актуальные данные.
ys1797
Доцент
Санкт-Петербург
1K 339
Отв.144 19 Марта 17, 16:47
можно подробнее где и как сделал?C-Bell, 19 Марта 17, 04:03
Т.е. читаешь старый скратчпад. Результат запущенных перед чтением измерений появится там позже.makh, 19 Марта 17, 05:16
Да, сейчас ситуация именно такая.
Идея в том, что теперь я запускаю конвертацию для всех устройств на bus (шине). Например: cat /sys/bus/w1/drivers/w1_master_driver/w1_bus_master1/w1_master_convert_all Чтение закончится примерно через 750 мс (W1_CONVERT_TEMP + задержка в 750мс) Далее, я с чистой совестью читаю скратчпад уже для каждого девайса на шине по отдельности.
Единственный ньюанс, что для ds2482-800 надо или 8 раз почитать w1_master_convert_all для каждой шины или городить отдельный огород с раздачей W1_CONVERT_TEMP в каждый доступный канал и одной задержкой.
Трейды, по моему мнению. не дадут прирост, т.к. в процессе чтения температуры на шину ставится mutex_lock(), что заблочит параллельные обращения.ys1797, 19 Марта 17, 00:46
Нет. Потоки не блокируются. Цикл преобразования каждого датчика запускается в своем потоке практически параллельно. Вот пример самотестирования моего питоновского модуля sens.py, где как раз используется многопоточная (параллельная) работа с датчиками DS18B20: Ненавязчивая автоматизация ректификационной установки. Автоматика. В первом случае (последовательный опрос) 830 мс на каждый датчик, а во втором - 950 мс на все 4 датчика. Объекты потоков и их запуски производятся в питоновском коде. Ниже - как раз этот фрагмент кода.
# Создаем объекты-потоки для каждого датчика температуры for i in range(nts): t = threading.Thread(target = DS18B20.temperature, args = (fns[i], ids[i])) threads.append(t) # Запускаем параллельные потоки циклов преобразований датчиков for i in range(nts): threads[i].start() for i in range(nts): # Ждем завершения всех циклов преобразований датчиков threads[i].join()
Так что "параллельность" на шине 1-wire вполне нормально работает (естественно, питание датчиков внешнее).
PS Проблемы были только на 3-й малинке, причем только с модулем thread. А при реализации многопоточности на основе модуля threading все (и на всех малинках) работает прекрасно.
C-Bell
Научный сотрудник
Улан-Удэ
1.8K 1.3K
Отв.146 20 Марта 17, 05:40
Правда в том, что не всякий раз многопоточность работает строго параллельно: Ненавязчивая автоматизация ректификационной установки. Автоматика. Это результат работы многопоточного сканирования пяти DS18B20 в течение более 12 часов. Видно, что средняя продолжительность получения новых температурных данных составляет около 1,05 сек. Иногда длительность опроса может составлять 3,45 сек.
OldBean
Доцент
Красноярск
1K 1.4K
Отв.147 20 Марта 17, 07:10
А что там, на этой секретной картинке? Ненавязчивая автоматизация ректификационной установки. Автоматика.
C-Bell, дело тут не в многопоточности, а в дизайне шины и сенсора. На измерение датчику по-любому надо что-то типа 700 мс, плюс, как минимум, коммуникация с каждым при чтении. Ну никак низя одновременно читать несколько сенсоров на одной шине. Послать всей гирлянде SKIP_ROM и CONVERT_T можно, но потом, даже без поиска датчиков, сколько потоков не запусти, процедура чтения каждого будет ждать своей очереди, увы.
capsolo
Профессор
Зелик
5.3K 1.6K
Отв.149 20 Марта 17, 13:17
OldBean, Коллега, мне кажется порочной сама идея отбора на максимуме стабилизации колонны. Как я люблю повторять - мы живем в аналоговом мире, и залет на квалификационном участке колонны означает, что мы УЖЕ ушли от стабильного состояния и все УЖЕ нехорошо. Читая коллег и их опыты, изучая хроматограммы пришел к выводу, что график, получаемый твоей автоматикой можно использовать как опорный, с привязкой к кубовой темпетратуре. После получения такого графика для той же самой навалки исходного сырья можно использовать значения отбора из него, умножая их на 0.8-0.9, чтобы просто не допускать факта изменения т на квалификационном участке.
OldBean
Доцент
Красноярск
1K 1.4K
Отв.150 20 Марта 17, 16:24
Это результат работы многопоточного сканирования пяти DS18B20 в течение более 12 часов. Видно, что средняя продолжительность получения новых температурных данных составляет около 1,05 сек. Иногда длительность опроса может составлять 3,45 сек.C-Bell, 20 Марта 17, 05:40
Попробую повторить такой эксперимент со своим софтом. Хотя я уже довольно много ректификаций провел с многопоточной реализацией работы с датчикам, но каких-то явных задержек в главном цикле не замечал. Но такой чистый тест, конечно же, нужно сделать.
мне кажется порочной сама идея отбора на максимуме стабилизации колонны.capsolo, 20 Марта 17, 13:17
Да. Возможно, так и есть.
Я в последнее время поэкспериментировал с разными алгоритмами регулирования (от П-ПИ до всяких "самодельных", дурацких и нелинейных :))) Задачка действительно оказалась непростой. Застабилизировать температуру в колонне (в пределах плюс-минус 1-2 кванта датчика во всем диапазоне спиртуозности в кубе) только при помощи плавного регулирования скорости отбора, пока не удалось. Старт-стоп периодически вынужден (автоматически) включаться и спасать ситуацию.
К сожалению, сказывается еще и отсутствие адекватной компьютерной модели колонны, а натурные эксперименты - такие длительные! Никак не могу понять (точнее - почувствовать) "фазовый портрет" системы (видимо, свое, положенное каждому, количество шишек я еще не набил :))). Но надежду пока не потерял. "Поколдую" еще немного. Все-таки, попытки научить малинку ректификационной "эквилибристике" - очень увлекательное занятие!
capsolo
Профессор
Зелик
5.3K 1.6K
Отв.151 20 Марта 17, 16:40 (через 17 мин)
Старт-стоп периодически вынужден (автоматически) включаться и спасать ситуацию.OldBean, 20 Марта 17, 16:24
Думаю стоит учесть пару простых факторов: 1) Если отбирать меньше предельного значения отбора для текущей спиртуозности (температуры) в кубе (можно сильно меньше, можно несильно меньше) "залета" внизу не будет. 2) Спирт начинает кончаться при температуре 90-92 в кубе, до этого процесс квазистационарный. То есть если колонна стабильна, отбор не меняется, мощность нагрева не меняется - стоп по сути можно не мониторить, он не состоится.
OldBean
Доцент
Красноярск
1K 1.4K
Отв.152 20 Марта 17, 19:26
1) Если отбирать меньше предельного значения отбора для текущей спиртуозности (температуры) в кубе (можно сильно меньше, можно несильно меньше) "залета" внизу не будет.capsolo, 20 Марта 17, 16:40
Да. Если мы знаем спиртуозность в кубе и мощность нагрева, мы можем оценивать поток пара спирта в колонну. Но для установки скорости отбора мы должны задаться еще как минимум одним параметром. Если этот параметр - флегмовое число, то рассчитывая таким образом скорость отбора, мы проводим процесс при постоянном ФЧ. Другой вариант - задаться какой-нибудь температурой в нижней части колонны и пытаться ее стабилизировать, регулируя скорость отбора. Т.е. процесс при "постоянной" температуре в какой-нибудь точке внизу колонны. Этот способ мне почему-то кажется более корректным (строго доказать пока не могу, но интуиция "хочет" его). Но в обоих случаях встает вопрос о значении этого параметра (ФЧ или температуры, т.е., по сути, уставки). Если брать его "с запасом" - вопросов нет. Но ведь хочется-то достигнуть какого-то оптимума (максимума) скорости отбора. Вот здесь-то "рог" и уперся в землю...
Т.е., помимо выбора регулятора и оптимизации его параметров, очень важным и нетривиальным является выбор (оценка) самой уставки (ФЧ или температуры) при которой можно достигнуть максимальной средней скорости отбора.
OldBean
Доцент
Красноярск
1K 1.4K
Отв.153 21 Марта 17, 04:45
2C-Bell
На всю ночь запустил на малинке тестовый скрипт, который в цикле запускает многопоточный вариант запусков датчиков температуры, измеряет время и собирает небольшую статистику. Выдача на скриншоте ниже. Ненавязчивая автоматизация ректификационной установки. Автоматика. В каждой строке - номер цикла преобразования, минимальное время на все датчики (за все время работы скрипта на момент выдачи), максимальное время и маленькая гистограмма, в которой первый элемент - число запусков с временем преобразования (всех датчиков параллельно) меньше 1 сек, затем - от 1 до 2 сек, затем - от 2 до 3, от 3 до 4 сек и в последней ячейке - 4 сек и более.
Как мы видим, за ночь скрипт выполнил 38900 циклов параллельного запуска 4-х температурных датчиков. Из них подавляющее большинство (37660) завершилось за время менее 1 сек. А всего 3.3% (1240 запусков) - завершилось на время, более 1 сек, но не превышающее 1.81 сек.
Так что преобразование датчиков в любом случае происходит параллельно (ибо последовательное преобразование четырех датчиков дает примерно 3.3 сек). Тут makh, скорее всего прав - все что более (700-750 мс + накладные расходы на организацию потоков) - это уже просто издержки операционной системы (на открытие файлов, чтение, чистку "перышек" и т.п. :))). За удобство пользования ОСью тоже приходится платить. Она же не RT, все-таки...
C-Bell
Научный сотрудник
Улан-Удэ
1.8K 1.3K
Отв.154 21 Марта 17, 05:52
Да, я наблюдал продолжительность одного цикла "параллельного" обращения чуть более 5 сек для пяти датчиков. Действительно, время поедает операционка. Вот сижу и репу чешу, если я ещё загружу веб-сервером, не затянет ли это циклы опроса термометров? Скорее затянет. Буду смотреть выриант с хаком, предложенный ys1797.
OldBean
Доцент
Красноярск
1K 1.4K
Отв.155 21 Марта 17, 08:36
Буду смотреть выриант с хаком, предложенный ys1797.C-Bell, 21 Марта 17, 05:52
Может быть будет проще и надежнее температурные датчики повесить на отдельную ма-а-а-ленькую ардуинку? И лучше - каждый датчик на свой пин ардуинки (для совсем пущей надежности :))). Такая ардуинка, подключенная к малинке по i2c будет для нее своеобразным "температурным сервером".
Вот сижу и репу чешу, если я ещё загружу веб-сервером,C-Bell, 21 Марта 17, 05:52
Зря Вы, коллега, таки планируете повешать на малинку серьезные интерфейсные функции. Это не дело "встраиваемых" систем. Даже с ОС. У нее итак много "домашних" хлопот - с установкой. Особенно, если какие-нибудь сложные алгоритмы управления ректификацией в планах.
Если не на продажу, а для себя любимого, то ИМХО, непосредственный интерфейс с малинкой - это всего лишь два файла. Один для вывода (журнал), другой - для ввода (оперативных параметров и даже команд, если нужно). Это весь интерфейс, полностью закрывающий весь необходимый функционал взаимодействия с ректификационной установкой. Эти файлы могут быть хоть на малинке, хоть в облаке (в локальной сети), либо вообще - где-нибудь в паутине. А работать с ними можно хоть через web-интерфейс, хоть через десктоповскую гую, хоть через ту же консоль. И обеспечением этого может заняться какой-нибудь другой, специализированный сервер.
Когда заходит речь об UI, мне почему-то всегда вспоминается старый Одесский анекдот.
Ловит на Дерибасовской мужик машину. - Это такси? - Такси. - А где шашечки? - А вам шашечки, или ехать?
C-Bell
Научный сотрудник
Улан-Удэ
1.8K 1.3K
Отв.156 21 Марта 17, 08:50 (через 14 мин)
Вы любите детей? Нет, скорее сам процесс...
Веб-интерфейс как минимум позволит в онлайн-режиме не программисту менять параметры. Я уже не говорю про удобство пользования с совершенно различных устройств без необходимости ставить какое-то программное обеспечение - ведь браузер есть везде...
makh
Профессор
Sаmara
2.1K 1K
Отв.157 21 Марта 17, 10:21
Ездят ли Наши люди™ в булочную на такси? Наверное, во многом зависит от расстояния до булочной. В каком-то случае уместнее лисапет, например .)
Т.е. я к тому, что веб-сервер для домашней песочницы не обязательно должен представлять из себя полновесного страшилку вроде nginx или апача. Есть решения попроще, thttpd например, да хоть самописный типа
my_www.sh | /bin/nc.openbsd -kl 80
Кстати, о птичках -- в 6.1-м релизе OpenBSD есть arm64 для третьей малины.
OldBean
Доцент
Красноярск
1K 1.4K
Отв.158 21 Марта 17, 12:34
Веб-интерфейс как минимум позволит в онлайн-режиме не программисту менять параметры. Я уже не говорю про удобство пользования с совершенно различных устройств без необходимости ставить какое-то программное обеспечение - ведь браузер есть везде...C-Bell, 21 Марта 17, 08:50
А я и не призываю "непрограммиста" садиться за консоль. Это только для железного непрограммиста-гурмана. Я-то здесь о том, зачем web-сервер размещать именно на малинке? Нашему непрограммисту со смартфоном или планшетом какая разница с кем соединяться - непосредственно с малинкой или с каким-нибудь другим сервером в сети?
Есть решения попроще,makh, 21 Марта 17, 10:21
Сам-то web-сервер, конечно, никаких проблем не представляет. В питоне - это одна строчка кода. Но ведь нужны дополнительные скрипты, чтобы обрабатывать запросы, формировать странички, кнопочки, боксики и прочую хренотень. Сразу же захочется и графики показывать. И не просто, а в реальном времени. Да еще и интерактивные, чтобы посмотреть детали. И пошло и поехало... На бедную малинкину голову!
Ну ладно. Это теория. Посмотрим, что у C-Bell получится на практике. Может и вправду не так все жестоко получится ;)))
capsolo
Профессор
Зелик
5.3K 1.6K
Отв.159 21 Марта 17, 13:35
Сам-то web-сервер, конечно, никаких проблем не представляет. В питоне - это одна строчка кода. Но ведь нужны дополнительные скрипты, чтобы обрабатывать запросы, формировать странички, кнопочки, боксики и прочую хренотень. Сразу же захочется и графики показывать. И не просто, а в реальном времени. Да еще и интерактивные, чтобы посмотреть детали. И пошло и поехало... На бедную малинкину голову!OldBean, 21 Марта 17, 12:34
Ну потянет она, потянет. Читал статейку - парнишка 100 сайтов легких захостил на ней и прямо она совсем не тормозила. А вот по поводу малинку заставлять кучу датчиков постоянно быстро опрашивать - тут я бы подумал. У нас "грязной" работой занимается Нана, вроде безопасности, РМ, шим клапана, прогон по паузам через ПИД и т.д. Наверх у нее торчит серийник. Ну и сверху может быть еще одна нана, Апельсинка, комп - да что угодно. Если апельсинка-малинка, дык ей только и остается веб сервер крутить, с "нижним" контроллером общаться и логи постить/доставать