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

издатель-подписчик гибче чем хозяин-подчиненныйKypocao, 30 Апр. 18, 00:49

Уважаемый коллега! Не всегда слова "современный" или "гибкий" является синонимами слов "лучший" или "более подходящий".

1. В данной ветке рассматриваются системы автоматизации ректификационной установки с четко иерархической организацией. Низкоуровневые операции, связанные с управлением конкретными узлами или предварительной обработкой показаний датчиков, выполняются отдельными микроконтроллерами. Это первый уровень иерархии с типично подчиненными устройствами (slaves).  Управление же общим процессом ректификации выполняется малинкой (или любым другим подходящим микрокомпьютером). Это второй уровень иерархии. Малинка здесь выступает типичным и единственным мастером (master). В планах еще и третий уровень - это формирование задания, отчеты и т.п. В общем - UI. Но пока он совмещен со вторым уровнем и выполняется той же малинкой. Поэтому модель взаимодействия master-slave для данной системы автоматизации является наиболее естественной.
2. Установка достаточно компактная. Расстояние между узлами - максимум десятки сантиметров. Поэтому физически все устройства связаны общей шиной, включающую в себя и линии шины i2c. Мне кажется, это тоже выглядит вполне естественно.

Вопросы, связанные с протоколами и архитектурами, несколько раз поднимался в данной ветке. Если будет время и возможность, гляньте на пару небольших резюмирующих топиков здесь и здесь. Там немножко подробнее говорится о выборе именно таких решений.

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

ИМХО, командир отделения должен находиться в том же окопе, что и его солдаты ;)

---

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

Во втором варианте (LITE) малинка "подбоченилась", "задрала нос", обзавелась собственной периферией для UI и стала играть роль рабочей станции. Но это только на стадии разработки (по моим представлениям новичкам в программировании так было бы легче). Но она все равно остается командиром отделения (а не генералом, командующим фронтом). После разработки "вернется в часть" ;)

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

Куросао
Прелагаю Вам создать новую тему и разработать свой проект, а мы посмотрим

энтузиазм по этому поводу охлаждался (по крайней мере у меня) вопросами питания этих "беспроводных" устройствOldBean, 30 Апр. 18, 09:10

если забить на wifi и посмотреть в сторону популярных nrf24l01 или BLE чипов, то вполне можно и от батареек.

Друзья!

Чуток оценок от меня по поводу шин modbus, CAN, MQTT и т.д. и. т.п.
Какие шины имеются на борту Малинки?
Читаем:
В качестве низкоуровневых интерфейсов доступны:
   40 портов ввода-вывода общего назначения;
   UART (Serial);
   I²C/TWI;
   SPI с селектором между двумя устройствами;
   пины питания: 3,3 В, 5 В и земля.
Т.е. для реализации modbus, CAN, MQTT треба аппаратные ухищрения, чтобы связаться по физике.
Лично я против...

Теперь к насущному.

Сергей, я тут накидал свои варианты схем по блочно.
Есть еще мысли, но это потом.
Очень хочу услышать мнение на счет ключа по питанию на DS18B20.
Как вариант сделать возможность RESETа питанием, в случае жесткого зависания DS18B20, что бывает при хорошей внешней помехе.  У меня как то было такое от грозового разряда.
Может дадим возможность AtMEGA  передергивать питание?

зы Платы разведены, если кому интересно, выложу

для реализации modbus, CAN, MQTT треба аппаратные ухищрения, чтобы связаться по физикеBogAD, 30 Апр. 18, 18:23

не обязательно. UART практически штатный для modbus-a (rs485 не есть строгое требование даже для RTU). Чипы шины RS485 (если захочется шину) дешевы. И вообще никто не запрещает передавать modbus ADU любым доступным способом) С MQTT то же самое, есть вариант и без TCP/IP.

не обязательно. UART практически штатный для modbus-a (rs485 не есть строгое требование даже для RTU). Чипы шины RS485 (если захочется шину) дешевы. И вообще никто не запрещает передавать modbus ADU любым доступным способом) С MQTT то же самое, есть вариант и без TCP/IP.arkhnchul, 30 Апр. 18, 18:34

Если вам не нравится концепция, опишите что не так.
Уважайте мнение автора! Серей уже подробно описал как он пришел к выбору шины  I2C.

Есть свои мысли, тогда тут свободно можете изложить их:
[Modbus, Ethernet, SCADA и прочие излишества]
[Создадим свой открытый протокол обмена данными между контроллером и модулями]

Лучше придумайте дополнительные функционалы установке, чем пытаться сломать принятую концепцию... 

Если вам не нравится концепция, опишите что не так.BogAD, 30 Апр. 18, 18:45

с чего вы взяли?) не надо додумывать за оппонентов. Мое высказывание (как и практически всегда) относится к одному же конкретному высказыванию, приведенному в цитате.

по поводу шин modbus, CAN, MQTTBogAD, 30 Апр. 18, 18:23

Только CAN это шина, а modbus и MQTT это протоколы передачи данных.

Только CAN это шина, а modbus и MQTT это протоколы передачи данных.Mnz, 30 Апр. 18, 20:40

Это конечно все меняет в корне...

В целом, конечно, обсуждение в данной ветке первичной низкоуровневой архитектуры системы особого смысла не имеет. Т.к. все ключевые решения уже давно приняты. Каких-то грубых (принципиальных) архитектурных ошибок здесь нет. Вряд ли найдутся какие-нибудь "убийственные" аргументы, которые заставили бы выкинуть готовое железо и начать все с начала ;)) Поэтому я и не спорю, а ограничиваюсь только краткими объяснениями почему выбрано такое решение, а не какое-нибудь другое. Безо всяких попыток кого-нибудь в чем-нибудь убеждать. Для этого есть другие, специализированные на этих вопросах, ветки.

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

---

я тут накидал свои варианты схем по блочно.BogAD, 30 Апр. 18, 18:23

Александр, у меня к Вам остается прежняя просьба - делайте это в отдельном топике с заголовком и небольшим описанием (и фотографиями по мере готовности). Чтобы я смог вставить ссылки на этот пост из соответствующих мест. Иначе все это безвозвратно затеряется в недрах ветки :((

Очень хочу услышать мнение на счет ключа по питанию на DS18B20.BogAD, 30 Апр. 18, 18:23

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

Александр, у меня к Вам остается прежняя просьба - делайте это в отдельном топике с заголовком и небольшим описанием (и фотографиями по мере готовности). Чтобы я смог вставить ссылки на этот пост из соответствующих мест. Иначе все это безвозвратно затеряется в недрах ветки (OldBean, 01 Мая 18, 04:28

Да, несомненно. По возможности. Фото и описание за мной.

В силу обстоятельств, очень далеко от своей любимой "лаборатории". Более 3 000 км...
На съемной площади не сильно то и разгуляешься.
Но... платы траванул (CRATE на переделку, трудноисправимый косяк).
Аппарат ваяется, задумана "клюшка". кожехотрубник на 2" и куб сварен (благо на работе есть доступ к аргону). Испытательный прогон сделан (без автоматики).

Кстати, для ее реализации можно и не ставить дополнительных элементов (ключа). В принципе, у МК цифрового модуля еще много лишних ног остается, а датчики потребляют мало. Поэтому питание каждой однопроводной шины можно осуществить непосредственно с выходов свободных портов. Тогда подавать и снимать питание с каждой шины (датчика) можно будет независимо. У меня сейчас под рукой datasheet на ATMega328P. Поэтому посмотрите сами, на всякий случай, предельные токи портов и на суммарный ток всех портов МК.OldBean, 01 Мая 18, 04:28

Сергей, я сначала так и хотел... Остановило то, что возможна вероятность получить КЗ  по 5 вольтам на линии датчиков. Кругом метал...
Перегрузочная способность портов МК слабенькая. Вроде,  максимальный ток портов — 40 мА. Подпалить порты легко.
Вот и решил поставить ключ MOSFET P-Channel. AO3401A все же держит 4А. Цена копеечная.
Да... порт PB0 подтягиваем к 0, ключ открывается. Отпускаем  - закрывается.

Цена копеечная.BogAD, 01 Мая 18, 11:01

Я не с точки зрения стоимости. Скорее - с точки зрения гибкости модуля - зачем сбрасывать все датчики, если, например, "подглючивает" только один. Впрочем, дело хозяйское... Надеюсь, сбрасывать датчики часто не придется ;)

Развожу печатные платы модулей Lite, остался цифровой модуль. Хочу добавить на плату этого модуля датчик атмосферного давления BMP180 в виде готового модулька GY-68. Смотрю там на платке подтяжки I2C уже распаяны и стабилизатор на 3.3 вольт. Подтяжки надо выпаять наверное, ведь на малинке шина подтянута уже? В этой ветке про это не нашел, может плохо смотрел...

9. Датчик атмосферного давленияOldBean, 09 Янв. 17, 14:29

В датчике ничего выпаивать не надо.

Это я видел. Ниже автор пишет:

Шина I2C использует только 3 провода: SCL, SDA и GND. На ведомых (slave) устройствах никаких подтягивающих резисторов ставить не нужно (!).OldBean, 16 Янв. 17, 02:59

С одним таким датчиком ничего страшного не будет, но вдруг кто то еще пару каких нибудь модулей со своей подтяжкой установить на шину захочет. Ладно, это маловероятно, вопрос мой исчерпан.

Я BMP180 на крейте расположил. Там места вагон.

С одним таким датчиком ничего страшного не будетSergeyMak, 07 Мая 18, 13:22

Если не злоупотреблять, то ничего страшного. Сориентироваться можно следующим образом: номинал малинкиных подтягивающих резисторов - 1.8k, дополнительные резисторы (4.7k) уменьшат общий номинал до 1.3k, тогда нагрузка на порт (притягивание линии к нулю) будет не более 2.5 мА. Такую нагрузку обычные порты спокойно тянут.

Уважаемые коллеги, знатоки МК. Такой вопрос. Заказал себе для запаса еще партию 5 шт МК Atmega 328P-PU, пришли, думаю дай-ка я прочитаю их, хотя бы fuse с помощью малинки. Результат такой

pi@raspberrypi:~ $ sudo avrdude -c usbasp -p m328p
avrdude: error: program enable: target doesn't answer. 1
avrdude: initialization failed, rc=-1
        Double check connections and try again, or use -F to override
        this check.

Хотя ранее этим же программатором прошил все модули этого проекта. Танцы с бубном, другими программами под Win ни к чему не привели. Вспомнил про старый свой LPT-шный программатор. На нем все читается, пишется и стирается. Правда напряжение программирования для этого МК в программе "Phiton ChipProg" по умолчанию выставлено было 12V.
После этого снова пробую всю партию МК на малинке и вот оно чудо

pi@raspberrypi:~ $ sudo avrdude -c usbasp -p m328p
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.00s
avrdude: Device signature = 0x1e950f (probably m328p)
avrdude: safemode: Fuses OK (E:FF, H:D9, L:E7)
avrdude done.  Thank you.


Как это объяснить - я не понимаю?