Перейти к содержимому

Open

Фотография
- - - - -

reefcloud - модульная платформа для автоматизации аквариума


  • Авторизуйтесь для ответа в теме
Сообщений в теме: 39

#1 avfv

avfv

    Продвинутый пользователь

  • Пользователи
  • PipPipPip
  • Cообщений: 582
  • Меня зовут:Андрей
  • Откуда:Санкт-Петербург

Отправлено 26 Февраль 2018 - 19:47

Здравствуйте!
 
Казалось бы, все тут уже придумано и сделано. Profilux, контроллеры от Олега и Карена, "Идеальный компьютер"...
Но вот захотелось мне такое оборудование, и я не вижу готовых доступных решений:
 
- Контроль KH и дозатор KH, способный работать в паре с измерителем;
- Контроллер DyMiCo реактора;
- Автоматический инкубатор артемии.
 
Контроль КН и DyMiCo мне сейчас необходимы для нового аквариума.
Делать "как обычно" неинтересно, хочется довести технологию содерижания МА без скиммера и автодолива до ума.
На чем же делать? Готовые решения неадекватно дорогие, да и сама реализация их мне не нравится.
Ардуино/ESP + куча плат как-то несерьезно совсем, промоборудование громоздко и дорого...
 
Делать один большой контроллер для всего бесперспективно, пока закончишь проктировать требования к нему поменяются и так по кругу. Нужен набор базовых модулей,
из которых и будут собираться устройства.
 
Сначала была идея взять за основу связку ESP+MCU, ESP будет заниматься веб интерфейсом и облаком, MCU все остальное + следить, чтобы ESP не зависал. Но, глюки ESP и общая ненадежность связи по WiFi проект похоронили.
Нужна технология, чтобы несколько разнесенных модулей работали как единое устройство. И тут все уже давно придумано - это CAN.
 
В итоге шина CAN + питание входит каждое устройство, проходит через несколько базовых плат, и выходит из него. Получается очень похоже на DeviceNet.
Всего планируется два вида плат: базовый модуль и модуль pH.
 
Функционал базового модуля:
- CAN
- 3-4 драйвера ШД;
- 2-4 низковольтных ключа;
- 4 датчика Холла;
- 4 оптопары;
- RGB светодиод;
- Фоторезистор;
- немного GPIO;
 
- 8Mb SDRAM;
- 8-16Mb SPI Flash - буфер для обновления прошивки и хранилище логов;
- Батарейка и кварц для часов;
 
- USB для начальной настройки шины CAN;
- Ethernet для связи с внешним миром. Задействован будет на одном модуле;
- WiFi - А надо ли?
 
Модуль pH проще, он не должен работать самостоятельно. Поэтому там только:
- CAN;
- USB;
- 8-16Mb SPI Flash;
- 2 канала для pH/ORP.
 
По софту основная концепция такая: никакого внешнего софта! Каждая плата сама хостит свои веб интерфейсы, модуль в который входит Ethernet работает по сути как
reverse proxy, переадресуя HTTP трафик соответствующему модулю по шине CAN. Облако тоже должно быть просто особым reverse proxy, не знать ничего про контроллеры и по сути
предоставлять только возможность удаленного доступа. 
 
Сейчас хотелось бы обсудить схемотехнику всего этого :)

  • balabollng и dmitryalaytsev это нравится

#2 balabollng

balabollng

    Продвинутый пользователь

  • Пользователи
  • PipPipPip
  • Cообщений: 5 438

Отправлено 26 Февраль 2018 - 20:16

Ура! Облака! :))) 


Мне не важно ваше мнение. Мне важны ваши дела.

#3 bbasil

bbasil

    Штатный зануда

  • Пользователи
  • PipPipPip
  • Cообщений: 3 124
  • Меня зовут:Василий
  • Откуда:Моск.обл., Одинцовский р-н,"КП Опушка" (Кокошкино)

Отправлено 26 Февраль 2018 - 20:18

Честно говоря не "догоняю" идею.

Если каждый модуль хостит свои интерфейсы, то значит у каждого модуля есть некое хранилище где лежит сей веб интерфейс, так?

Если основной модуль выступает неким реверс прокси для запросов к модулю, то модуль помимо хранения интерфейсов имеет еще и некий обработчик запросов ?

Кажется что это слишком расточительно будет - в коненом итоге понадобится к каждому модулю свой mcu

Как по мне, так логичнее было-бы сделать на централном контроллере просто  web2can...



#4 avfv

avfv

    Продвинутый пользователь

  • Пользователи
  • PipPipPip
  • Cообщений: 582
  • Меня зовут:Андрей
  • Откуда:Санкт-Петербург

Отправлено 26 Февраль 2018 - 21:03

Да, веб-интерфейсы пакуются в romfs архив и линкуются вместе с прошивкой.

 

В этом есть некоторая избыточность, конечно. Можно использовать минимальные MCU, а софт хранить в облаке, запускать на PC... Проблемы тут в том, что облако вообще живет само по себе, софт на PC просто теряется или вдруг не работает после обновления ОС (да и самих ОС уже 4-5 видов). 

Можно облегчить подчиненные MCU, выделив один центральный. Тоже плохо - нужно как-то загружать на этот центральный модуль интерфейсы, обновлять синхронно с прошивками.

 

Я буду ставить STM32F4 с флэшем 1-2Mb, хватит на несколько интерфейсов даже если использовать Angular, а VUE еще компактнее. Нужно ли экономить на спичках?

 

Простой пример, зачем это нужно:

есть три модуля дозаторов

- просто DC моторчик, управляется ключом - в интерфейсе задаем время включения для дозирования 1 мл;

- простой драйвер ШД 8825 - задаем режим микрошага и сколько шагов на 1 мл;

- продвинутый драйвер ШД L6470 - задаем микрошаг, ток, действия при пропуске шагов...

Зачем центральному модулю знать все это? Он посылает им одинаковые CAN сообщения.



#5 bbasil

bbasil

    Штатный зануда

  • Пользователи
  • PipPipPip
  • Cообщений: 3 124
  • Меня зовут:Василий
  • Откуда:Моск.обл., Одинцовский р-н,"КП Опушка" (Кокошкино)

Отправлено 26 Февраль 2018 - 23:10

"не определенный артикль на старофранцузком", ну будьте вы уже инженером, а не программистом :)))

любой измеритель чего либо выдает вам некое измеренное значение,  mcu должен уметь получить сие значение ( что очень просто, шины данных стандартизованны) и преобразовать его в управляющий сигнал на gpio, то есть знать функцию y=f(x)(где х сигнал, y -значение), математика нам говорит, что с достаточной степенью точности любую функция можно разложить в ряд   Тейлора (https://ru.wikipedia...iki/Ряд_Тейлора)

ТО, на измерительный модуль необходимо и достаточно добавить всего-лишь eeprom(256 байт за глаза) где будут записаны члены ряда Тейлора, а mcu остается всего лишь их прочитать, обсчитать и выдать управляющий сигнал на gpio :)

 

И никаких angular, vue и пр лабуды :)


  • BorisKramer это нравится

#6 PriZ

PriZ

    Продвинутый пользователь

  • Пользователи
  • PipPipPip
  • Cообщений: 632
  • Откуда:Пушкино

Отправлено 27 Февраль 2018 - 00:55

 

Но вот захотелось мне такое оборудование, и я не вижу готовых доступных решений:
 
- Контроль KH и дозатор KH, способный работать в паре с измерителем;
 

 

https://www.sewatec....standalone.html



#7 Gum

Gum

    Продвинутый пользователь

  • Пользователи
  • PipPipPip
  • Cообщений: 367

Отправлено 27 Февраль 2018 - 03:15

Я правильно понимаю, что устроенно это так:

Комп берет показание с PH датчика и ORP датчика и в зависимости от их показаний запускает помпы?



#8 avfv

avfv

    Продвинутый пользователь

  • Пользователи
  • PipPipPip
  • Cообщений: 582
  • Меня зовут:Андрей
  • Откуда:Санкт-Петербург

Отправлено 27 Февраль 2018 - 09:44

Если уж выбирать готовое решение, то изначальный KH Director, который и скопировала GHL, смотрится куда выгоднее. По крайней мере, точность измерения там не зарезана в угоду экономии титранта. Инженеры из GHL или не потрудились почитать что-нибудь про автоматизацию химических анализов, или решили что "и так сойдет".



#9 avfv

avfv

    Продвинутый пользователь

  • Пользователи
  • PipPipPip
  • Cообщений: 582
  • Меня зовут:Андрей
  • Откуда:Санкт-Петербург

Отправлено 27 Февраль 2018 - 09:51

Комп берет показание с PH датчика и ORP датчика и в зависимости от их показаний запускает помпы?

Если мы о работе DyMiCo, то примерно так. Для запуска протоки можно использовать не только абсолютное значение ORP, но и "nitrate knee" - резкий скачок ORP вниз когда нитрат уже закончился. Точный алгоритм работы еще предстоит разработать, тем более он будет зависеть от реализации самого реактора.



#10 Gum

Gum

    Продвинутый пользователь

  • Пользователи
  • PipPipPip
  • Cообщений: 367

Отправлено 27 Февраль 2018 - 10:03

Если это только PH, ORP датчики и несколько помп, тогда зачем такие сложности с модулями, CAN и т.д. Казалось бы, собрали все это на одной есп и решили задачу. Или я чего то не понимаю?



#11 avfv

avfv

    Продвинутый пользователь

  • Пользователи
  • PipPipPip
  • Cообщений: 582
  • Меня зовут:Андрей
  • Откуда:Санкт-Петербург

Отправлено 27 Февраль 2018 - 10:20

Ну это смотря что считать сложным. Для меня сложно собирать вместе кучу китайских платок на макетках, а потом поддерживать этого паука. А если разводить свою плату, то зачем вообще ESP с его фирменными глюками?

 

У модульности есть еще одно преимущество. Можно очень просто дублировать датчики, особенно это как раз pH и ORP касается, без радикальной переделки всего.



#12 avfv

avfv

    Продвинутый пользователь

  • Пользователи
  • PipPipPip
  • Cообщений: 582
  • Меня зовут:Андрей
  • Откуда:Санкт-Петербург

Отправлено 27 Февраль 2018 - 10:36

can1.png

 

Начал рисовать контроллер CAN, пока вижу две альтернативы - MCP2517FD или сразу брать STM32H7 базовым контроллером. H7 всем хорош, но он очень новый и купить трудно, по сути сейчас продают сэмплы. Хотя его использование заманчиво все упрощает, можно сразу выкинуть два корпуса и не писать драйвер для MCP2517FD.



#13 balabollng

balabollng

    Продвинутый пользователь

  • Пользователи
  • PipPipPip
  • Cообщений: 5 438

Отправлено 27 Февраль 2018 - 11:05

Если это только PH, ORP датчики и несколько помп, тогда зачем такие сложности с модулями, CAN и т.д. Казалось бы, собрали все это на одной есп и решили задачу. Или я чего то не понимаю?

 

ESP это не панацея. Более того, ESP8266 это скорее геморрой. А ESP32 пока не получила подтверждения надежности. Так что разделение ролей железа до сих пор является актуальной задачей. До момента подтверждения обратного.

 

Желание же экономить, никогда до добра не доводило.


Мне не важно ваше мнение. Мне важны ваши дела.

#14 lexx8691

lexx8691

    Продвинутый пользователь

  • Пользователи
  • PipPipPip
  • Cообщений: 5 998
  • Меня зовут:Алексей
  • Откуда:Новосибирская обл. р. п. Чаны.

Отправлено 27 Февраль 2018 - 11:17

Мне STM больше нравится.


  • balabollng это нравится

#15 BorisKramer

BorisKramer

    Продвинутый пользователь

  • Пользователи
  • PipPipPip
  • Cообщений: 2 586
  • Откуда:New-York - Peterburg

Отправлено 27 Февраль 2018 - 11:22

"не определенный артикль на старофранцузком", ну будьте вы уже инженером, а не программистом :)))
любой измеритель чего либо выдает вам некое измеренное значение, mcu должен уметь получить сие значение ( что очень просто, шины данных стандартизованны) и преобразовать его в управляющий сигнал на gpio, то есть знать функцию y=f(x)(где х сигнал, y -значение), математика нам говорит, что с достаточной степенью точности любую функция можно разложить в ряд Тейлора (https://ru.wikipedia...iki/Ряд_Тейлора)
ТО, на измерительный модуль необходимо и достаточно добавить всего-лишь eeprom(256 байт за глаза) где будут записаны члены ряда Тейлора, а mcu остается всего лишь их прочитать, обсчитать и выдать управляющий сигнал на gpio :)

И никаких angular, vue и пр лабуды :)


Инженеру несложно научиться писать программы. Можно даже научиться писать их хорошо. Программисту никогда не научиться делать инжиниринг. Даже плохо.

#16 BorisKramer

BorisKramer

    Продвинутый пользователь

  • Пользователи
  • PipPipPip
  • Cообщений: 2 586
  • Откуда:New-York - Peterburg

Отправлено 27 Февраль 2018 - 11:24

can1.png

Начал рисовать контроллер CAN, пока вижу две альтернативы - MCP2517FD или сразу брать STM32H7 базовым контроллером. H7 всем хорош, но он очень новый и купить трудно, по сути сейчас продают сэмплы. Хотя его использование заманчиво все упрощает, можно сразу выкинуть два корпуса и не писать драйвер для MCP2517FD.


Смотрите для чего больше готовых библиотек. Вам не реализовать самостоятельно полноценные протоколы типа canopen. Ну или делать просто общение примитивным протоколом используя can чисто как несущий канал.

#17 balabollng

balabollng

    Продвинутый пользователь

  • Пользователи
  • PipPipPip
  • Cообщений: 5 438

Отправлено 27 Февраль 2018 - 11:32

В общем же, конечно, во-первых, нужно определиться с требуемыми функциями. Поставить приоритеты. И только после этого определяться с железом. Уж этого барахла хватает. Любой китаец с глубоко средним образованием может собрать железку на заказ. Было бы только понимание, что нужно. А вот за софтом китайцы бегают неустанно. Именно тут 90% проблем и юзерфрендли. 

 

Так что, по приоритету:

1. Функции;

2. Прототип;

3. Железо. 


Мне не важно ваше мнение. Мне важны ваши дела.

#18 avfv

avfv

    Продвинутый пользователь

  • Пользователи
  • PipPipPip
  • Cообщений: 582
  • Меня зовут:Андрей
  • Откуда:Санкт-Петербург

Отправлено 27 Февраль 2018 - 12:28

Смотрите для чего больше готовых библиотек. Вам не реализовать самостоятельно полноценные протоколы типа canopen. Ну или делать просто общение примитивным протоколом используя can чисто как несущий канал.

 

canopen мне не нужен. Максимум что-нибудь легковесное вроде UAVCAN, а лучше всего не мудрить и общаться просто сообщениями. Сложные протоколы поверх CAN решают ведь по сути две задачи - позволяют работать в одной сети оборудованию многих поставщиков, и повышают порог вхождения для конкурентов. Мне это все не нужно.



#19 avfv

avfv

    Продвинутый пользователь

  • Пользователи
  • PipPipPip
  • Cообщений: 582
  • Меня зовут:Андрей
  • Откуда:Санкт-Петербург

Отправлено 27 Февраль 2018 - 12:52

В общем же, конечно, во-первых, нужно определиться с требуемыми функциями. Поставить приоритеты. И только после этого определяться с железом. Именно тут 90% проблем и юзерфрендли. 

Так я определился. Это несложно, у меня ведь нет задачи сделать супер-облако с магазином приложений, да так чтобы все захотели там быть, да еще и на моих условиях. Собственно, концепция "весь нужный софт внутри устройства" не нова и уже обкатана - роутеры, 3g модемы, TrueSpectrum, SSLAC. Собственно, что я хочу добавить - это соединять устройства не глючным WiFi, а надежным CAN, да агрегатор их интерфейсов на одной страничке, чтобы управлять проще было.

 

А прототип вот сейчас делаю. Базовые вещи вроде lwIP, RNDIS на дискавери завелись, дальше нужно уже реальное железо.



#20 BorisKramer

BorisKramer

    Продвинутый пользователь

  • Пользователи
  • PipPipPip
  • Cообщений: 2 586
  • Откуда:New-York - Peterburg

Отправлено 27 Февраль 2018 - 12:58

canopen мне не нужен. Максимум что-нибудь легковесное вроде UAVCAN, а лучше всего не мудрить и общаться просто сообщениями. Сложные протоколы поверх CAN решают ведь по сути две задачи - позволяют работать в одной сети оборудованию многих поставщиков, и повышают порог вхождения для конкурентов. Мне это все не нужно.

Порог вхождения они не повышают, так как куча библиотек бесплатных.

Сложность протоколов типы canopen обуславливается идеологией самоидентификации.

Если вам достаточно руками прописать в модуле адрес то все просто. А если надо чтобы адрес пристроился сам то нужны полноценные протоколы.






Количество пользователей, читающих эту тему: 0

0 пользователей, 0 гостей, 0 анонимных