reefcloud - модульная платформа для автоматизации аквариума
#1
Отправлено 26 Февраль 2018 - 19:47
- balabollng и dmitryalaytsev это нравится
#2
Отправлено 26 Февраль 2018 - 20:16
Ура! Облака! ))
#3
Отправлено 26 Февраль 2018 - 20:18
Честно говоря не "догоняю" идею.
Если каждый модуль хостит свои интерфейсы, то значит у каждого модуля есть некое хранилище где лежит сей веб интерфейс, так?
Если основной модуль выступает неким реверс прокси для запросов к модулю, то модуль помимо хранения интерфейсов имеет еще и некий обработчик запросов ?
Кажется что это слишком расточительно будет - в коненом итоге понадобится к каждому модулю свой mcu
Как по мне, так логичнее было-бы сделать на централном контроллере просто web2can...
#4
Отправлено 26 Февраль 2018 - 21:03
Да, веб-интерфейсы пакуются в romfs архив и линкуются вместе с прошивкой.
В этом есть некоторая избыточность, конечно. Можно использовать минимальные MCU, а софт хранить в облаке, запускать на PC... Проблемы тут в том, что облако вообще живет само по себе, софт на PC просто теряется или вдруг не работает после обновления ОС (да и самих ОС уже 4-5 видов).
Можно облегчить подчиненные MCU, выделив один центральный. Тоже плохо - нужно как-то загружать на этот центральный модуль интерфейсы, обновлять синхронно с прошивками.
Я буду ставить STM32F4 с флэшем 1-2Mb, хватит на несколько интерфейсов даже если использовать Angular, а VUE еще компактнее. Нужно ли экономить на спичках?
Простой пример, зачем это нужно:
есть три модуля дозаторов
- просто DC моторчик, управляется ключом - в интерфейсе задаем время включения для дозирования 1 мл;
- простой драйвер ШД 8825 - задаем режим микрошага и сколько шагов на 1 мл;
- продвинутый драйвер ШД L6470 - задаем микрошаг, ток, действия при пропуске шагов...
Зачем центральному модулю знать все это? Он посылает им одинаковые CAN сообщения.
#5
Отправлено 26 Февраль 2018 - 23:10
"не определенный артикль на старофранцузком", ну будьте вы уже инженером, а не программистом ))
любой измеритель чего либо выдает вам некое измеренное значение, mcu должен уметь получить сие значение ( что очень просто, шины данных стандартизованны) и преобразовать его в управляющий сигнал на gpio, то есть знать функцию y=f(x)(где х сигнал, y -значение), математика нам говорит, что с достаточной степенью точности любую функция можно разложить в ряд Тейлора (https://ru.wikipedia...iki/Ряд_Тейлора)
ТО, на измерительный модуль необходимо и достаточно добавить всего-лишь eeprom(256 байт за глаза) где будут записаны члены ряда Тейлора, а mcu остается всего лишь их прочитать, обсчитать и выдать управляющий сигнал на gpio
И никаких angular, vue и пр лабуды
- BorisKramer это нравится
#6
Отправлено 27 Февраль 2018 - 00:55
Но вот захотелось мне такое оборудование, и я не вижу готовых доступных решений:- Контроль KH и дозатор KH, способный работать в паре с измерителем;
https://www.sewatec....standalone.html
#7
Отправлено 27 Февраль 2018 - 03:15
Я правильно понимаю, что устроенно это так:
Комп берет показание с PH датчика и ORP датчика и в зависимости от их показаний запускает помпы?
#8
Отправлено 27 Февраль 2018 - 09:44
Если уж выбирать готовое решение, то изначальный KH Director, который и скопировала GHL, смотрится куда выгоднее. По крайней мере, точность измерения там не зарезана в угоду экономии титранта. Инженеры из GHL или не потрудились почитать что-нибудь про автоматизацию химических анализов, или решили что "и так сойдет".
#9
Отправлено 27 Февраль 2018 - 09:51
Комп берет показание с PH датчика и ORP датчика и в зависимости от их показаний запускает помпы?
Если мы о работе DyMiCo, то примерно так. Для запуска протоки можно использовать не только абсолютное значение ORP, но и "nitrate knee" - резкий скачок ORP вниз когда нитрат уже закончился. Точный алгоритм работы еще предстоит разработать, тем более он будет зависеть от реализации самого реактора.
#10
Отправлено 27 Февраль 2018 - 10:03
Если это только PH, ORP датчики и несколько помп, тогда зачем такие сложности с модулями, CAN и т.д. Казалось бы, собрали все это на одной есп и решили задачу. Или я чего то не понимаю?
#11
Отправлено 27 Февраль 2018 - 10:20
Ну это смотря что считать сложным. Для меня сложно собирать вместе кучу китайских платок на макетках, а потом поддерживать этого паука. А если разводить свою плату, то зачем вообще ESP с его фирменными глюками?
У модульности есть еще одно преимущество. Можно очень просто дублировать датчики, особенно это как раз pH и ORP касается, без радикальной переделки всего.
#12
Отправлено 27 Февраль 2018 - 10:36
Начал рисовать контроллер CAN, пока вижу две альтернативы - MCP2517FD или сразу брать STM32H7 базовым контроллером. H7 всем хорош, но он очень новый и купить трудно, по сути сейчас продают сэмплы. Хотя его использование заманчиво все упрощает, можно сразу выкинуть два корпуса и не писать драйвер для MCP2517FD.
#13
Отправлено 27 Февраль 2018 - 11:05
Если это только PH, ORP датчики и несколько помп, тогда зачем такие сложности с модулями, CAN и т.д. Казалось бы, собрали все это на одной есп и решили задачу. Или я чего то не понимаю?
ESP это не панацея. Более того, ESP8266 это скорее геморрой. А ESP32 пока не получила подтверждения надежности. Так что разделение ролей железа до сих пор является актуальной задачей. До момента подтверждения обратного.
Желание же экономить, никогда до добра не доводило.
#14
Отправлено 27 Февраль 2018 - 11:17
Мне STM больше нравится.
- balabollng это нравится
#15
Отправлено 27 Февраль 2018 - 11:22
"не определенный артикль на старофранцузком", ну будьте вы уже инженером, а не программистом ))
любой измеритель чего либо выдает вам некое измеренное значение, mcu должен уметь получить сие значение ( что очень просто, шины данных стандартизованны) и преобразовать его в управляющий сигнал на gpio, то есть знать функцию y=f(x)(где х сигнал, y -значение), математика нам говорит, что с достаточной степенью точности любую функция можно разложить в ряд Тейлора (https://ru.wikipedia...iki/Ряд_Тейлора)
ТО, на измерительный модуль необходимо и достаточно добавить всего-лишь eeprom(256 байт за глаза) где будут записаны члены ряда Тейлора, а mcu остается всего лишь их прочитать, обсчитать и выдать управляющий сигнал на gpio
И никаких angular, vue и пр лабуды
Инженеру несложно научиться писать программы. Можно даже научиться писать их хорошо. Программисту никогда не научиться делать инжиниринг. Даже плохо.
#16
Отправлено 27 Февраль 2018 - 11:24
can1.png
Начал рисовать контроллер CAN, пока вижу две альтернативы - MCP2517FD или сразу брать STM32H7 базовым контроллером. H7 всем хорош, но он очень новый и купить трудно, по сути сейчас продают сэмплы. Хотя его использование заманчиво все упрощает, можно сразу выкинуть два корпуса и не писать драйвер для MCP2517FD.
Смотрите для чего больше готовых библиотек. Вам не реализовать самостоятельно полноценные протоколы типа canopen. Ну или делать просто общение примитивным протоколом используя can чисто как несущий канал.
#17
Отправлено 27 Февраль 2018 - 11:32
В общем же, конечно, во-первых, нужно определиться с требуемыми функциями. Поставить приоритеты. И только после этого определяться с железом. Уж этого барахла хватает. Любой китаец с глубоко средним образованием может собрать железку на заказ. Было бы только понимание, что нужно. А вот за софтом китайцы бегают неустанно. Именно тут 90% проблем и юзерфрендли.
Так что, по приоритету:
1. Функции;
2. Прототип;
3. Железо.
#18
Отправлено 27 Февраль 2018 - 12:28
Смотрите для чего больше готовых библиотек. Вам не реализовать самостоятельно полноценные протоколы типа canopen. Ну или делать просто общение примитивным протоколом используя can чисто как несущий канал.
canopen мне не нужен. Максимум что-нибудь легковесное вроде UAVCAN, а лучше всего не мудрить и общаться просто сообщениями. Сложные протоколы поверх CAN решают ведь по сути две задачи - позволяют работать в одной сети оборудованию многих поставщиков, и повышают порог вхождения для конкурентов. Мне это все не нужно.
#19
Отправлено 27 Февраль 2018 - 12:52
В общем же, конечно, во-первых, нужно определиться с требуемыми функциями. Поставить приоритеты. И только после этого определяться с железом. Именно тут 90% проблем и юзерфрендли.
Так я определился. Это несложно, у меня ведь нет задачи сделать супер-облако с магазином приложений, да так чтобы все захотели там быть, да еще и на моих условиях. Собственно, концепция "весь нужный софт внутри устройства" не нова и уже обкатана - роутеры, 3g модемы, TrueSpectrum, SSLAC. Собственно, что я хочу добавить - это соединять устройства не глючным WiFi, а надежным CAN, да агрегатор их интерфейсов на одной страничке, чтобы управлять проще было.
А прототип вот сейчас делаю. Базовые вещи вроде lwIP, RNDIS на дискавери завелись, дальше нужно уже реальное железо.
#20
Отправлено 27 Февраль 2018 - 12:58
canopen мне не нужен. Максимум что-нибудь легковесное вроде UAVCAN, а лучше всего не мудрить и общаться просто сообщениями. Сложные протоколы поверх CAN решают ведь по сути две задачи - позволяют работать в одной сети оборудованию многих поставщиков, и повышают порог вхождения для конкурентов. Мне это все не нужно.
Порог вхождения они не повышают, так как куча библиотек бесплатных.
Сложность протоколов типы canopen обуславливается идеологией самоидентификации.
Если вам достаточно руками прописать в модуле адрес то все просто. А если надо чтобы адрес пристроился сам то нужны полноценные протоколы.
Количество пользователей, читающих эту тему: 0
0 пользователей, 0 гостей, 0 анонимных