- Первый реле в списке (r0) - это контактор подачи силового питания на все устройства
- Первый PDM (w0) - это модуль управления ТЭНом
- Первый PWМ (q0) - первый клапан отбора
По этой логике первый датчик давления (P0) должен быть датчик атмосферного давления, по нему и температуре кипения будем определять спиртуозность. А если датчик атмосферного давления из-за подключения/отключения датчиков кубового давления будет скакать то P0, то Р1 как программа будет знать какой ключ в данный момент нужно использовать? Нужно будет при каждом запуске клиента уточнять у оператора на каком "P" в данный момент находится атмосферный датчик. Если названия разнести, то прога всегда будет искать Pa0 в качестве атмосферного, а Рс0, РС1 в качестве кубовых.
Ну появится еще датчик давления (по типу атмосферного) где-нибудь в колонне или буфере. Атмосфера стоит на 0x77, а новый, скажем, станет на 0x76. И номер у атмосферного датчика опять поплыветOldBean, 21 Авг. 19, 14:59Да, в данном случае поплывет. Действительно, старый который был на 0х77 станет Ра1, а новый с 0х76 появится как Ра0, но ситуация аналогична тому когда у нас датчик температуры Т0 был подключен к каналу 1 хаба, а затем мы к каналу 0 хаба подключили второй температурный датчик. Старый после этого стал Т1, а новый будет Т0. Так и с атмосферными датчиками: новый Ра0 - это датчик такого же типа как и предыдущий Ра1, т.е. атмосферный. Поэтому вести себя нужно в обоих случаях одинаково. Рассмотрим:
Пусть у нас есть ПРОГРАММА-клиент. Но программа одна, а алгоритмов ее работы может быть множество. Поэтому после запуска программа должна запрашивать у оператора РЕЖИМ своей работы. В свою очередь, для каждого режима где-то внутри должны быть прописаны ТРЕБОВАНИЯ для его включения. В требованиях необходимо прописать нужный состав оборудования (сколько нужно температурных датчиков, клапанов, датчиков давления) и выдать оператору рекомендацию по подключению данного оборудования к железу. Например (первое что пришло в голову):
1. Монитор.
Пользователь просто видит информацию со всех доступных датчиков, но не может ей управлять. Где установлены эти датчики знает только пользователь, программе это не важно
2. Полностью ручной режим.
Пользователь просто видит информацию со всех доступных датчиков, может управлять всеми датчиками позволяющими запись. Где установлены эти датчики знает только пользователь, программе это не важно, т.к. она сама никакими процессами сейчас не управляет.
Далее автоматические режимы, процессами в которой будет управлять клиентская программа:
3. Простая дистилляция.
Требования к аппаратуре: контактор, тэн, один датчик атмосферного давления, один датчик температуры.
Требования к расположению датчиков:
Ра0 - датчик атмосферы используемый для определения спиртуозности
Т0 - куб
4. Дистилляция по Габриэлю.
Требования к аппаратуре: контактор, тэн, один датчик атмосферного давления, два датчика температуры.
Требования к расположению датчиков:
Ра0 - датчик атмосферы используемый для определения спиртуозности
Т0 - куб
Т1 - верхняя часть дистиллятора
5. Ректификация 1
Требования к аппаратуре: контактор, тэн, один датчик атмосферного давления, один клапан, два датчика температуры.
Требования к расположению датчиков:
Ра0 - датчик атмосферы используемый для определения спиртуозности
Т0 - куб
Т1 - дефлегматор (по нему старт-стоп будем отрабатывать)
6. Ректификация 2
Требования к аппаратуре: контактор, тэн, один датчик атмосферного давления, один клапан, три датчика температуры.
Требования к расположению датчиков:
Ра0 - датчик атмосферы используемый для определения спиртуозности
Т0 - куб
Т1 - колонна
Т2 - дефлегматор
7. Ректификация 2 + ЦП
Требования к аппаратуре: контактор, тэн, один датчик атмосферного давления, два клапана, четыре датчика температуры.
Требования к расположению датчиков:
Ра0 - датчик атмосферы используемый для определения спиртуозности
Т0 - куб
Т1 - колонна
Т2 - ЦП
Т3 - дефлегматор
8. ну и так далее...
В автоматических режимах пользователь перед запуском должен выполнить требования программы по количеству датчиков и их месту установки в оборудовании. Автоматические режимы будут отрабатывать по ШАГАМ, задаваемым при описании данных режимов. Для разных режимов количество шагов и их состав может быть различным: разгон, работа на себя, пауза, отбор голов, отбор подголовников, пауза, отбор тела, отбор хвостов, промывка колонны и т.п. Если подключены дополнительные датчики, избыточные для ТРЕБОВАНИЙ конкретного РЕЖИМА работы, то просто показываем их значение в качестве факультативной информации. Количество режимов работы теоретически может быть не ограниченным, каждый из них всего лишь пункт в меню. Базовые режимы (монитор, ручной, простая дистилляция) должны быть запрограммированы в клиенте, а по остальным наверное нет смысла забивать в программу конфигурацию по всем мыслимым и немыслимым комбинациям. Конфигурацию (описание, требования, рекомендации, набор щагов) для каждого режима можно, например, расположить в отдельном XML файле, нужно лишь определить правила его заполнения. Клиент при запуске будет разбирать набор этих файлов и строить меню выбора режима. Файлы смогут составлять сами пользователи и делиться друг с другом. Файлы с режимами можно складывать в определенную директорию малинки либо вставлять на USB флэшке в порт малинки. Представляете, каждый сможет сформировать свой собственный набор файлов с режимами, только нужных ему лично с его собственным оборудованием! И меню режимов в программе не будет распухать ненужными пунктами пытаясь удовлетворить всех. По мере апгрейда оборудования нужно будет лишь доложить нужные файлы с режимами использующие это оборудование.
Теперь вернемся к нашим баранам, т.е. сымитируем ситуацию когда после подключения одного из датчиков другие однотипные сменили имена... :-)
Пусть у нас выбран режим 5 - Ректификация 1. Есть два датчика Т0 на канале 2 хаба и Т1 на канале 4 хаба. Согласно требованиям режима датчик с канала 2 должен быть подключен в куб, а с канала 4 в дефлегматор. Теперь в канал 1 включаем еще один датчик температуры. Происходит следующее переназначение датчиков:
- канал 1: Т0 - новый
- канал 2: Т0 -> Т1
- канал 4: Т1 -> Т2
Т.к. все датчики однотипные (и я подразумеваю что взаимозаменяемые), то согласно требованиям мы вновь установленный датчик должны воткнуть в куб, из куба переставить в дефлегматор, а из дефлегматора вытащить и оставить болтаться в воздухе - с него показания не будут использоваться в алгоритме, а просто будут отображаться факультативно.
Режим по-прежнему 5:
Аналогично для взаимозаменяемых датчиков давления. Пусть у нас есть ВМР180 на 77 адресе, который видится как Ра0. Пусть мы добавили к нему ВМР280 на 76 адрес и нумерация изменилась:
- ВМР280: Ра0 - новый
- ВМР180: Ра0 -> Ра1
Опять же, т.к. эти датчики однотипные (и взаимозаменяемые), то аналогично температурам как бы виртуально "перетыкаем" их. Теперь для расчетов алгоритма будут использоваться показания ВМР280 (т.к. он теперь Ра0), а со второго датчика показания будут отображаться факультативно. Если добавить датчик кубового давления, то он появится как Рс0 и не повлияет на нумерацию группы Ра, он вообще ни на что в данном режиме не повлияет, т.к. датчиков группы Рс нет в требованиях и его показания будут отображаться как факультативная информация.
А теперь представим ситуацию как сейчас у Вас для режима 5:
Есть ВМР180, который виден как Р0. Все хорошо. Ставим кубовый датчик, который теперь Р0, а атмосфера будет Р1. Но в требованиях режима атмосфера должна быть Р0 и обеспечить их мы не можем, т.к. эти датчики не взаимозаменяемые!!! Один абсолютного атмосферного давления, а другой дифференциальный кубового и один не может исполнять функции другого. Поэтому они должны быть в разных группах. Количество групп должно быть именно по количеству взаимозаменяемых сущностей.
А тем, что на уровень lsync закладывается конкретная семантика.OldBean, 21 Авг. 19, 14:59Так Вы уже для датчиков атмосферного давления прописали в lsync конкретную семантеку создав классы BMP180, BMP280, МС5611 и опрашивая из них шину I2C особым образом! Остается лишь именовать эти три типа датчика по-другому выделив их в отдельную группу! :-)
Ух, много написал, тормознусь пока... :-)
