Форум самогонщиков Сайт Барахолка Магазин Помощь солдатам

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

Форум самогонщиков Автоматика
1 ... 5 6 7 8 9 10 11 ... 132 8
OldBean Доцент Красноярск 1K 1.4K
Отв.140  15 Марта 17, 02:43
2U-M

Если для "фиксация" уставки и измерения текущей температуры используется один и тот же датчик температуры (обычно так и есть), то его калибровка не обязательна. То же касается и давления. В формуле для коррекции используется разность давлений. Поэтому датчик давления тоже можно не калибровать. Главное, чтобы датчики давали цифры в градусах Цельсия и мм.рт.ст. соответственно. В противном случае нужно изменить коэффициент в формуле коррекции уставки. Под те единицы, в которых работают датчики.

Примечание. Здесь под калибровкой понимаем согласование абсолютных показаний датчиков с соответствующими эталонами.
ys1797 Доцент Санкт-Петербург 1K 338
Отв.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 мс не производится.
По умолчанию тип питания спрашивается у самого датчика, если он сказал, что есть внешнее питание - задержка не производится.


Вот, покажи  свой аналог чтения, это мой:
root@raspberrypi:/home/data/src/linux# time cat /sys/bus/w1/devices/28-8000000458f4/w1_slave
85 01 ff ff 7f ff ff ff 32 : crc=32 YES
85 01 ff ff 7f ff ff ff 32 t=24312

real    0m0.038s
user    0m0.000s
sys    0m0.000s

Я сделал небольшой кернел хак, и на мастер при чтении определенного файлика в sysfs выдаю на w1 шину:
w1_reset_bus(md);
w1_write_8(md, W1_SKIP_ROM);
w1_write_8(md, W1_CONVERT_TEMP);

что заставляет начать процесс измерения температуры не всех датчиках, которые подключены к мастеру.
Далее, я без задержек читаю температуру с каждого из датчиков - это 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 1.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 338
Отв.144  19 Марта 17, 16:47
можно подробнее где и как сделал?C-Bell, 19 Марта 17, 04:03

Идея взята отсюда: https://forum.armbian.com/...w1-term-driver/
Адаптирована к текущему ядру из:
git clone --depth=1 https://github.com/raspberrypi/linux
Если надо могу дифф приатачить.

Т.е. читаешь старый скратчпад. Результат запущенных перед чтением измерений появится там позже.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 в каждый доступный канал и одной задержкой.




d.diff 4.5 Кб
OldBean Доцент Красноярск 1K 1.4K
Отв.145  19 Марта 17, 19:15
покажи  свой аналог чтенияys1797, 19 Марта 17, 00:46
pi@raspberrypi:~ $ ls /sys/bus/w1/devices/
28-00000180a353  28-0000018c5c68  w1_bus_master1
28-00000180c746  28-0000018c6520
pi@raspberrypi:~ $ time cat /sys/bus/w1/devices/28-00000180a353/w1_slave
b5 03 4b 46 7f ff 0b 10 d9 : crc=d9 YES
b5 03 4b 46 7f ff 0b 10 d9 t=59312

real 0m0.829s
user 0m0.000s
sys 0m0.030s

Трейды, по моему мнению. не дадут прирост, т.к. в процессе чтения температуры на шину ставится 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
А что там, на этой секретной картинке?
Ненавязчивая автоматизация ректификационной установки
Ненавязчивая автоматизация ректификационной установки. Автоматика.
sc_sh.png
sc_sh.png Ненавязчивая автоматизация ректификационной установки. Автоматика.
makh Профессор Sаmara 2.1K 1.1K
Отв.148  20 Марта 17, 11:13
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 1.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 сайтов легких захостил на ней и прямо она совсем не тормозила. А вот по поводу малинку заставлять кучу датчиков постоянно быстро опрашивать - тут я бы подумал. У нас  "грязной" работой занимается Нана, вроде безопасности, РМ, шим клапана, прогон по паузам через ПИД и т.д. Наверх у нее торчит серийник. Ну и сверху может быть еще одна нана, Апельсинка, комп - да что угодно. Если апельсинка-малинка, дык ей только и остается веб сервер крутить, с "нижним" контроллером общаться и логи постить/доставать
IMG_1526.JPG
IMG_1526.JPG Ненавязчивая автоматизация ректификационной установки. Автоматика.