Система диспетчеризации и автоматизации, Идея проекта Опции

[AlexandrY]

Если хотите продавать всякие игрушки, и пр шняги для "блондинок" и тех, у кого интеллект опустился до уровня бабуина, что имеет место быть в сегодняшних реалиях, и поднять бабок на этом с каждым годом можно все больше и больше, тут я не спорю, но ТС и его контроллеры нацелены на несколько иную аудиторию, ближе к промавтоматике, и тут ваш подход не сработает...

А я что, спорю?
Я и говорю, автор хотел бытовую шнягу, а получилось как всегда - промавтоматика.

[Owl Electronics]

Если хотите продавать всякие игрушки, и пр шняги для "блондинок" и тех, у кого интеллект опустился до уровня бабуина, что имеет место быть в сегодняшних реалиях, и поднять бабок на этом с каждым годом можно все больше и больше, тут я не спорю, но ТС и его контроллеры нацелены на несколько иную аудиторию, ближе к промавтоматике, и тут ваш подход не сработает...

В принципе, вы правы, только вот надо сначала понять, есть ли она- аудитория, "близкая к промавтоматике", или же придется в итоге делать конкретный уклон в какую-то сторону.

И да, пару дней назад пришел запрос на потестить образец от фирмы, занимающейся промышленными установками для очистки воздуха. Ну, хотя бы теперь некий ориентир есть.

Сообщение отредактировал Owl Electronics - Jul 25 2018, 12:02

[syoma]

Вставлю свое ИМХО, как потенциальный заказчик. Мне в систему нужен какой-то блочек на дин рейку, который бы добавлял удаленный доступ к моей системе управления. В саму систему вводить удаленный доступ не хочу и часто она прекрасно работает и без него, но заказчикам иногда хочется добавить удаленную диагностику и мониторинг. Грубо говоря хочется такой функционал (в порядке убывания приоритетов)
- Подключение к контроллерной шине по CANopen и запись всего, что происходит в локальный лог с автоматической выгрузкой на сервер. Запись должна вестись и при отсутствии интернета. Возможность инициировать SDO трафик для чтения/записи параметров контроллера (т.е. обычный CANopen стек на Linux)
- Ессно часы реального времени для логов с автоматической синхронизацией через NTP
- Пара релюшек, чтобы дергать питание системы удаленно
- Режим HMI - встроенный настраиваемый Вебсервер с возможностью доступа как по сети, так и локально через Wi-Fi/Bluetooth, например с телефона/планшета.
- соответствие промышленным EMC стандартам, работа от -20 до +50°C.
- размер - примерно с 2 коробки сигарет, питание +24В или ~220В.
- Возможность дублирования интернет канала - RJ485/Wi-Fi/3G.
- Возможно, но не факт, что для интернет-части понадобятся и другие протоколы - Modbus TCP, MQTT и т.д. , так, чтобы можно было присобачить эту коробочку и под другие системы мониторинга, а не только вашу.

Честно говоря думал под это дело тупо взять Малину, да приспособить ее под данные нужды, но с софтом заморачиваться не хочется.

[mantech]

- Подключение к контроллерной шине по CANopen и запись всего, что происходит в локальный лог с автоматической выгрузкой на сервер. Запись должна вестись и при отсутствии интернета. Возможность инициировать SDO трафик для чтения/записи параметров контроллера (т.е. обычный CANopen стек на Linux)

Ну вот, апологеты кана засветились, вот чем рс485 с модбасом не подошли? Это используется в машине, "модно, стильно молодежно" или в чем фишка? Объясню, не понимаю зачем усложнять задачу моструозным стеком, или просто аля "в малине уже было, дак что и не использовать"

[syoma]

Ну вот, апологеты кана засветились, вот чем рс485 с модбасом не подошли? Это используется в машине, "модно, стильно молодежно" или в чем фишка? Объясню, не понимаю зачем усложнять задачу моструозным стеком, или просто аля "в малине уже было, дак что и не использовать"

Ну CiA 417, например. Довольно популярный публичный стандарт, почему бы не использовать?

[mantech]

Ну CiA 417, например. Довольно популярный публичный стандарт, почему бы не использовать?

Да много популярных стандартов есть, просто очень часто стал видеть, что используют протоколы с исходниками по километру, в тех случаях, когда прекрасно справляется простейший модбас с исходником на 2 экрана текста... Причем в большинстве своем те, кто используют этих монстров, даже не представляют, как это написано и работает, соотв. о надежности чужой либы и правильности ее "прикручивания" к своему проекту говорить особо не приходится, просто, как "черный ящик"...

[syoma]

Да много популярных стандартов есть, просто очень часто стал видеть, что используют протоколы с исходниками по километру, в тех случаях, когда прекрасно справляется простейший модбас с исходником на 2 экрана текста... Причем в большинстве своем те, кто используют этих монстров, даже не представляют, как это написано и работает, соотв. о надежности чужой либы и правильности ее "прикручивания" к своему проекту говорить особо не приходится, просто, как "черный ящик"...

Ну вот для меня данное устройство, предложенное автором и удовлетворяющее моим требованиям и есть тот черный ящик, который я бы с удовольствием прикрутил к своему проекту. Какая там будет CANopen либа мне до лампочки, если оно зависнет, то тоже ничего критичного с моим проектом не произойдет.
А возможные проблемы с интеграцией монструозного стека на Линуксе оказываются и не такими уж проблемными, если учесть, что этот же самый стек уже работает не в одном десятке проектов и баги достаточно хорошо вылизаны либо известны. Но это не относится к данной теме.

[mantech]

Какая там будет CANopen либа мне до лампочки, если оно зависнет, то тоже ничего критичного с моим проектом не произойдет.

С таким подходом покупаете любую китайскую шнягу или самый дешевый роутер, пишете чего-нить на питоне или что там еще модно и оно как-то будет работать

[Atridies]

IoT протоколы это просто более высокий прикладной уровень. Выше HTTP.
Могут показаться искусственными только если быть не в курсе их приложений и условий работы.

И о каких "всех задачах" речь? Задача - чисто инженерная заморочка.
Если взглянуть на себя как на обывателя, то у меня нет задач.
Если дивайс простой как IKEA-вская лампочка то беру, если это SCADA хоть и в виде WEB страницы, то нафиг не надо.
Критерии просты - минимум времени, отсутствие сопутствующих затрат (например проводов), геймификация, структурирование деятельности без умственного напряжения (нет нужды читать инструкции).
Подумав немного как это сделать вы придете к выводу, что дивайс должен быть нереально универсальным.

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

[AlexandrY]

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

Я себе IoT представляю как интернет, т.е. сеть сетей.
Выход в публичный интернет не обязателен.
И каждый дивайс может работать и как клиент и как сервер.
Вот у меня часы и смартфон. И тот и другой собирают данные, и сами по себе, и друг у друга.
Они вероятно будут "серваки" на вашем слэнге.

Ну вот, апологеты кана засветились, вот чем рс485 с модбасом не подошли?

А чё, есть уже на 485 экcпандеры типа таких - https://www.microchip.com/ParamChartSearch/...x?branchID=1941?
Миф как раз в том что 485 c модбасом проще CAN-а.
На самом деле трудно найти что-то более простое чем CAN для связи микроконтроллеров по полевой шине.

[mantech]

А чё, есть уже на 485 экcпандеры типа таких - https://www.microchip.com/ParamChartSearch/...x?branchID=1941?
Миф как раз в том что 485 c модбасом проще CAN-а.
На самом деле трудно найти что-то более простое чем CAN для связи микроконтроллеров по полевой шине.

Ну и чем они лучше вот этих - https://www.microchip.com/wwwproducts/en/MCP23008

Кроме того, что в 2 раза дешевле, и во много раз проще в программировании хоста...
А вообще "тупые" экспандеры мало кто использует, ибо трафик на шине от них ужасный.

Сообщение отредактировал mantech - Jul 26 2018, 07:19

[AlexandrY]

А вообще "тупые" экспандеры мало кто использует, ибо трафик на шине от них ужасный.

I2C экспандеры хороши на коротких дистанциях.
Если приглядитесь к фотке, то увидите что верхняя плата подобным образом и сделана.

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

[syoma]

С таким подходом покупаете любую китайскую шнягу или самый дешевый роутер, пишете чего-нить на питоне или что там еще модно и оно как-то будет работать

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

[AlexandrY]

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

Что станет главным по большей части зависит от личных навыков разработчика.
Но по логике труднее делать то, что сильнее ограничено в ресурсах, т.е. встраиваемую систему.

[syoma]

С таким подходом покупаете любую китайскую шнягу или самый дешевый роутер, пишете чего-нить на питоне или что там еще модно и оно как-то будет работать

Но в конце концов мне нужно готовое изделие, которое я могу воткнуть в свое без всяких танцев с питоном, как говорится "plug-and-play". Что-нибудь есть из подходящего на рынке?