Спасибо! Да, темный матовый светорассеиватель смотрелся бы гораздо интереснее, но его изготовление нужно заказывать на стороне. Датчик освещенности присутствует - как подметил @ds138.
Здесь уже нужно реализовать трекинг объектов. Соответственно, для этих целей применяется алгоритмы компьютерного зрения. У вас должен быть обученный алгоритм, который сможет распознавать элементы оборудования, с которым вы работаете. Само собой, под эти задачи применяются более производительное аппаратное решение, чем описано в данной статье.
Данный модуль не предназначен для управления светодиодными лентами (и их каналами). Этот модуль рассчитан на управление осветительной нагрузкой в цепи переменного тока.
Orange Pi Zero 2W это хороший выбор и по бюджету и по аппаратной начинке. Реализовал несколько проектов на данной плате и очень доволен её производительностью. Ранее, для реализации своего проекта, пытался использовать Mango Pi с тем же форм фактором и на том же SoC, но программная поддержка железа там была никакая.
PS: Спасибо за упоминание моей статьи и успехов с Вашими проектами!
Почему не использовали временную базу данных? Influxdb например? Она с коробки может читать напрямую из Сименса, опрашивать по modbus и т.п. Так же можно для сбора данных использовать node-red, да и визуализацию можно сделать там же.
Начало реализации системы было в начале 2017 года. К тому моменту я не знал о существовании InfluxDB, да и в нашей АСУ ТП на тот момент не использовались решения от SIEMENS. Касательно Node-RED: да, это классное решение для эксплуатации системы людьми, далекими от написания кода, но мне проще и быстрее было написать код модуля, чем дополнительно интегрировать данный инструмент в систему. На тот момент систему планировалось использовать как локальный диагностический инструмент, и о каком-либо масштабном использовании речи не шло.
Очень много туда на визуализацию данных. Есть много готовых продуктов,: grafana, Apache superset.
Я не любитель сторонних зависимостей в своих проектах, несмотря на то что они упрощают разработку и сокращают время на её реализацию.
Зачем для сбора modbus использовать контроллер? Есть адаптеры ethernet что могут работать в режиме виртуального com порта.
если коротко, то контроллер устанавливался на перспективу.
P.S. так же вашу систему никто кроме Вас не может ни развивать, ни поддерживать, для собственника это не очень хорошо.
Если под "собственником" вы имеете в виду компанию, то компания не ставила целей для разработки данной системы, все реализовано на голой инициативе. У меня сложилось устойчивое ощущение, судя по действиям "ближайшего" руководства, что у собственников была одна политика: "Крутитесь как хотите, только не морочьте нам голову своими проблемами". И как я уже говорил ранее, система была создана исключительно на энтузиазме, без каких-либо надежд на интеграцию в бизнес-процессы.
Круто, классно, молодец!)))
С уважением, Ваш коллега по АСУ ТП)
Спасибо большое за оценку, и я очень рад, что моё "творчество" читают коллеги).
К сожалению, о дальнейшей судьбе данного устройства мне ничего не известно, так как я больше не являюсь сотрудником этой компании.
Обидно, когда разработка пропадает.
Здесь ничего страшного нет, я получил интересный опыт в процессе реализации, а тем, кому данная идея интересна, могут безвозмездно воспользоваться исходниками данного проекта, - для этих целей и опубликована данная статья.
износ самого измеряющего колеса будет сказываться на результатах измерения выше
Возможно вы не совсем поняли суть описанного в статье устройства. Данное устройство является переносным инструментом, который используется для диагностики во время плановых остановок оборудования. Да и в процессе измерений, нагрузка на измерительное колесо настолько незначительная, что и речи не может быть о каком-то катастрофическом износе, который бы привёл бы к большой погрешности измерений.
Да и в описанном вами кейсе, в сравнении с моим, абсолютно разные конструкции и условия применения измерительного энкрдера.
Согласен, но в данном случае это никак не влияет на точность работы системы. Что касается дребезга контактов геркона, данное событие маловероятно, а если посмотрите исходный код микро ПО контроллера, то сможете убедиться, что и эта потенциальная проблема учтена.
Можно любой датчик поставить индукционный/оптический/etc, но с герконом проще и удобнее: прилепил магнит сбоку исследуемого валика и всё. Скорость вращения валика очень низкая, поэтому "подлипания" геркона, если они имеют место быть, никаким образом не сказываются на замер.
Микронная точность здесь явно не нужна. Точность измерения зависит от механики устройства.
Как верифицировались измерения?
Здесь я совсем не понял вопроса. Что значит "верифицировать" измерения? На этапе наладки, устройство тестируется на ошибки измерений и доводится к требуемым параметрам, если есть какие-либо отклонения.
Примите мои сожаления по этому поводу :).
Спасибо! Да, темный матовый светорассеиватель смотрелся бы гораздо интереснее, но его изготовление нужно заказывать на стороне. Датчик освещенности присутствует - как подметил @ds138.
Что-то подобное я уже делал, только для реализации применил более дешёвый одноплатник. Видео.
Ага, и заставить пользователя не двигаться, чтобы маркер всегда оставался на объекте)
Здесь уже нужно реализовать трекинг объектов. Соответственно, для этих целей применяется алгоритмы компьютерного зрения. У вас должен быть обученный алгоритм, который сможет распознавать элементы оборудования, с которым вы работаете. Само собой, под эти задачи применяются более производительное аппаратное решение, чем описано в данной статье.
Выводятся данные ШИМ и скорости. Монитор крепиться к очкам, но в планах улучшить устройство и разместить его в шлеме.
Статья о реализации AR монитора доступна по ссылке.
В предыдущей статье было показано. Там фото и видео работы.
Вот вторя статья, которая описывает реализацию базовых функций.
Я не понял вашего вопроса. Данная статья как раз и описывает аппаратную реализацию устройства.
Данный модуль не предназначен для управления светодиодными лентами (и их каналами). Этот модуль рассчитан на управление осветительной нагрузкой в цепи переменного тока.
Orange Pi Zero 2W это хороший выбор и по бюджету и по аппаратной начинке. Реализовал несколько проектов на данной плате и очень доволен её производительностью. Ранее, для реализации своего проекта, пытался использовать Mango Pi с тем же форм фактором и на том же SoC, но программная поддержка железа там была никакая.
PS: Спасибо за упоминание моей статьи и успехов с Вашими проектами!
Начало реализации системы было в начале 2017 года. К тому моменту я не знал о существовании InfluxDB, да и в нашей АСУ ТП на тот момент не использовались решения от SIEMENS. Касательно Node-RED: да, это классное решение для эксплуатации системы людьми, далекими от написания кода, но мне проще и быстрее было написать код модуля, чем дополнительно интегрировать данный инструмент в систему. На тот момент систему планировалось использовать как локальный диагностический инструмент, и о каком-либо масштабном использовании речи не шло.
Я не любитель сторонних зависимостей в своих проектах, несмотря на то что они упрощают разработку и сокращают время на её реализацию.
Я уже отвечал: https://habr.com/ru/companies/timeweb/articles/844552/comments/#comment_27413094
если коротко, то контроллер устанавливался на перспективу.
Если под "собственником" вы имеете в виду компанию, то компания не ставила целей для разработки данной системы, все реализовано на голой инициативе. У меня сложилось устойчивое ощущение, судя по действиям "ближайшего" руководства, что у собственников была одна политика: "Крутитесь как хотите, только не морочьте нам голову своими проблемами". И как я уже говорил ранее, система была создана исключительно на энтузиазме, без каких-либо надежд на интеграцию в бизнес-процессы.
Спасибо большое за оценку, и я очень рад, что моё "творчество" читают коллеги).
К сожалению, о дальнейшей судьбе данного устройства мне ничего не известно, так как я больше не являюсь сотрудником этой компании.
Здесь ничего страшного нет, я получил интересный опыт в процессе реализации, а тем, кому данная идея интересна, могут безвозмездно воспользоваться исходниками данного проекта, - для этих целей и опубликована данная статья.
Пластиковые колеса - это просто демонстрация моего концепта механики. В дальнейшем "заказчик" устройства планировал изготовить их из металла.
Возможно вы не совсем поняли суть описанного в статье устройства. Данное устройство является переносным инструментом, который используется для диагностики во время плановых остановок оборудования. Да и в процессе измерений, нагрузка на измерительное колесо настолько незначительная, что и речи не может быть о каком-то катастрофическом износе, который бы привёл бы к большой погрешности измерений.
Да и в описанном вами кейсе, в сравнении с моим, абсолютно разные конструкции и условия применения измерительного энкрдера.
Согласен, но в данном случае это никак не влияет на точность работы системы. Что касается дребезга контактов геркона, данное событие маловероятно, а если посмотрите исходный код микро ПО контроллера, то сможете убедиться, что и эта потенциальная проблема учтена.
По своему опыту скажу, что это точно не относится к той компании, где я работал.
Можно любой датчик поставить индукционный/оптический/etc, но с герконом проще и удобнее: прилепил магнит сбоку исследуемого валика и всё. Скорость вращения валика очень низкая, поэтому "подлипания" геркона, если они имеют место быть, никаким образом не сказываются на замер.
Микронная точность здесь явно не нужна. Точность измерения зависит от механики устройства.
Здесь я совсем не понял вопроса. Что значит "верифицировать" измерения? На этапе наладки, устройство тестируется на ошибки измерений и доводится к требуемым параметрам, если есть какие-либо отклонения.