[AlexandrY 3]

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

А я что, спорю?

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

[Owl_Andrew 0]

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

 

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

 

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

Изменено 25 июля, 2018 пользователем Owl Electronics

[syoma 1]

Вставлю свое ИМХО, как потенциальный заказчик. Мне в систему нужен какой-то блочек на дин рейку, который бы добавлял удаленный доступ к моей системе управления. В саму систему вводить удаленный доступ не хочу и часто она прекрасно работает и без него, но заказчикам иногда хочется добавить удаленную диагностику и мониторинг. Грубо говоря хочется такой функционал (в порядке убывания приоритетов)

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

- Ессно часы реального времени для логов с автоматической синхронизацией через NTP

- Пара релюшек, чтобы дергать питание системы удаленно

- Режим HMI - встроенный настраиваемый Вебсервер с возможностью доступа как по сети, так и локально через Wi-Fi/Bluetooth, например с телефона/планшета.

- соответствие промышленным EMC стандартам, работа от -20 до +50°C.

- размер - примерно с 2 коробки сигарет, питание +24В или ~220В.

- Возможность дублирования интернет канала - RJ485/Wi-Fi/3G.

- Возможно, но не факт, что для интернет-части понадобятся и другие протоколы - Modbus TCP, MQTT и т.д. , так, чтобы можно было присобачить эту коробочку и под другие системы мониторинга, а не только вашу.

 

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

[mantech 57]

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

 

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

[syoma 1]

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

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

[mantech 57]

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

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

[syoma 1]

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

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

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

[mantech 57]

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

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

[Atridies 0]

IoT протоколы это просто более высокий прикладной уровень. Выше HTTP.

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

 

И о каких "всех задачах" речь? Задача - чисто инженерная заморочка.

Если взглянуть на себя как на обывателя, то у меня нет задач.

Если дивайс простой как IKEA-вская лампочка то беру, если это SCADA хоть и в виде WEB страницы, то нафиг не надо.

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

Подумав немного как это сделать вы придете к выводу, что дивайс должен быть нереально универсальным.

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

Верно?

[AlexandrY 3]

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

Верно?

Я себе IoT представляю как интернет, т.е. сеть сетей.

Выход в публичный интернет не обязателен.

И каждый дивайс может работать и как клиент и как сервер.

Вот у меня часы и смартфон. И тот и другой собирают данные, и сами по себе, и друг у друга.

Они вероятно будут "серваки" на вашем слэнге.

 

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

А чё, есть уже на 485 экcпандеры типа таких - https://www.microchip.com/ParamChartSearch/...x?branchID=1941?

Миф как раз в том что 485 c модбасом проще CAN-а.

На самом деле трудно найти что-то более простое чем CAN для связи микроконтроллеров по полевой шине.

 

[mantech 57]

А чё, есть уже на 485 экcпандеры типа таких - https://www.microchip.com/ParamChartSearch/...x?branchID=1941?

Миф как раз в том что 485 c модбасом проще CAN-а.

На самом деле трудно найти что-то более простое чем CAN для связи микроконтроллеров по полевой шине.

 

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

 

Кроме того, что в 2 раза дешевле, и во много раз проще в программировании хоста...

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

Изменено 26 июля, 2018 пользователем mantech

[AlexandrY 3]

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

I2C экспандеры хороши на коротких дистанциях.

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

 

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

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

Многоканальный аналоговый измеритель лучше было бы делать распределенным и на CAN расширителях.

 

 

[syoma 1]

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

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

 

[AlexandrY 3]

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

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

Но по логике труднее делать то, что сильнее ограничено в ресурсах, т.е. встраиваемую систему.

[syoma 1]

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

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