Комментарии 31
Опишите лучше, как вы Test Fixture делаете и тесты к ним. Про вспомогательное оборудование тоже интересно почитать.
С радостью.
Сами коробки на заводе не делались — они заказывались у сторонних производителей (тот же Ingun).
Вспомогательное оборудование — речь обо всяких программируемых источниках питания (небольшие одноплатные устр-ва с переходником usb-uart), платы с реле (switchboard), всякие штуковины для работы с радиосигналами (анализаторы спектра, снифферы и пр.) Все устр-ва, как я писал, имели стандартный интерфейс — COM-port, и было решено писать весь софт на Python. Удобства более чем очевидны, для понимания работы самих устройств знать не надо было практически ничего, был список команд, которые каждое устр-во понимает, через pyserial отправлялась команда, параллельно вычитывалась реакция устр-ва.
Далее ход тестов, составленный отделом разработки, реализовывался всё на том же Python, а интерфейс к самой коробке был реализован как небольшой web-server, у которого был GUI для оператора, и API для центральной системы, которая все эти тесты гоняла. В итоге получалась очень гибкая, удобная и легко масштабируемая система. Но, как я и сказал, для ручной отладки и оперативного исправления всяких неисправностей очень не хватало подобного COM-port монитора.
Сами коробки на заводе не делались — они заказывались у сторонних производителей (тот же Ingun).
Вспомогательное оборудование — речь обо всяких программируемых источниках питания (небольшие одноплатные устр-ва с переходником usb-uart), платы с реле (switchboard), всякие штуковины для работы с радиосигналами (анализаторы спектра, снифферы и пр.) Все устр-ва, как я писал, имели стандартный интерфейс — COM-port, и было решено писать весь софт на Python. Удобства более чем очевидны, для понимания работы самих устройств знать не надо было практически ничего, был список команд, которые каждое устр-во понимает, через pyserial отправлялась команда, параллельно вычитывалась реакция устр-ва.
Далее ход тестов, составленный отделом разработки, реализовывался всё на том же Python, а интерфейс к самой коробке был реализован как небольшой web-server, у которого был GUI для оператора, и API для центральной системы, которая все эти тесты гоняла. В итоге получалась очень гибкая, удобная и легко масштабируемая система. Но, как я и сказал, для ручной отладки и оперативного исправления всяких неисправностей очень не хватало подобного COM-port монитора.
Почему не взяли Labview — это же стандартая среда для данного применения?
Чрезмерно дорогое решение, если не ошибаюсь, не кросс-платформенное, и, боюсь, никак его не интегрировать с какой-нибудь Web-системой
ИМХО тогда у вас что-то не то с тестовой системой. То ли она легаси — т. е вы поддерживаете много старых стендов, то ли что-то непонятное. Слишком сложно получается и все на UART. Как-то я не понимаю нобходимость Веб-сервера, если задача тестового стенда — оператор нажал на кнопку старт — провести тестирование — создать протокол. Все вроде.
Cами коробки на заводе не делались — они заказывались у сторонних производителей (тот же Ingun).
Было бы неплохо узнать подробности — т.е. это т.н. bed of nails — это все надо заказывать, как готовую коробку со всеми иглами под конкретную плату или можно отдельно коробку, отдельно иглы и потом самому собирать?
Честно говоря, из статьи не совсем понятно, какую именно проблему решал автор. Что не так с многочисленными usb-uart девайсами, которые на али стоят меньше 100р./штуку и которые можно прицепить хоть сотню к одному ПК?
Если точки мониторинга/управления разбросаны на большие расстояния, можно использовать решение типа TCP2UART bridge + tibbo.
Та хоспади, NodeMCU и всего делов. TCP/IP поддерживает, WiFi есть, UART есть, стоит три копейки, программируется скриптами за пол часа.
Может, я выразился несколько смазанно.
Типичная ситуация: к одному компу, ассоциированному (физически и логически) с конкретным Test Fixture, присоединены несколько устр-в (в т.ч. и тестируемое устр-во, DUT — device under test). Скажем, одно из вспомогательных устройств — просто генератор RF. Шлём ему команду «излучи чего-то там на 835 МГц». Он отвечает «ОК». При этом я хочу одновременно видеть реакцию моего DUT, что он действительно принял этот сигнал. И желательно, чтобы мне не приходилось каждый раз определять, на каком порту сидит мой генератор, а на каком — DUT. Система должна сама об этом позаботиться. И автоматически загрузить список команд для каждого типа устройства. И желательно, чтобы всё это интегрировалось в общую систему тестирования, интерфейс которой оформлен через Web. Ну, и там ещё всякие мелочи.
Просто честно: удобство и эргономика в производстве очень часто имеет свой денежный эквивалент. Удобный стул для пайщицы или качественный монитор для программера — это не роскошь, а средство увеличения эффективности труда. Где-то подобными соображениями я и руководствовался
Типичная ситуация: к одному компу, ассоциированному (физически и логически) с конкретным Test Fixture, присоединены несколько устр-в (в т.ч. и тестируемое устр-во, DUT — device under test). Скажем, одно из вспомогательных устройств — просто генератор RF. Шлём ему команду «излучи чего-то там на 835 МГц». Он отвечает «ОК». При этом я хочу одновременно видеть реакцию моего DUT, что он действительно принял этот сигнал. И желательно, чтобы мне не приходилось каждый раз определять, на каком порту сидит мой генератор, а на каком — DUT. Система должна сама об этом позаботиться. И автоматически загрузить список команд для каждого типа устройства. И желательно, чтобы всё это интегрировалось в общую систему тестирования, интерфейс которой оформлен через Web. Ну, и там ещё всякие мелочи.
Просто честно: удобство и эргономика в производстве очень часто имеет свой денежный эквивалент. Удобный стул для пайщицы или качественный монитор для программера — это не роскошь, а средство увеличения эффективности труда. Где-то подобными соображениями я и руководствовался
А можете рассказать, каким образом определяется тип устройства и номер среди однотипных? Мне кажется это не тривиальным, особенно если учесть свойство Windows по разному нумеровать новые COM порты.
Если честно, на всех подобных устройствах был распаян, если я не ошибаюсь, cp2102 USB UART adapter, и в него можно было с помощью фирменной утилитки прошить имя устройства (любую произвольную строку). Я в меньшей степени электронщик, я больше программированием занимаюсь. Так вот, под python есть библиотечка infini что-то там, позволяет читать registry в windows, оттуда и сопоставляем имя порта (скажем, COM13), и название устройства (например, PowerSupply1). А в Linux и того проще, там в б-ке pyserial есть метод get_usb_description. И это было супер удобно
С Linux все еще проще: т.к. каждый cp2102 имеет свой уникальный серийный номер, то с помощью правил в /etc/udev/rules.d Вы можете ему присвоить любое удобное Вам имя в системе. Это имя будет жестко привязано к конкретному устройству по его серийному номеру вне зависимости от порядка подключения и тд. Кстати, если верить документации silabs, Device Serial Number Вы можете перепрошить так же, как и Product Description String.
Верно, и именно этим я воспользовался для того, чтобы автоматически загрузить в интерфейс список предопределённых команд, и связать это устройство с его индивидуальным блоком в интерфейсе. К тому же, у каждого пользователя могут быть свои предпочтения в списке команд, и этим легко управлять — при логине загружается список команд именно того устройства, которое пользователь определил.
Так же легко потом делать шейринг таким спискам.
Там есть возможность записи последовательностей команд (наподобие записи макросов, как были в Visual Studio или в Selenium IDE), их прогонки и пр.
Одним из преимуществ подобной системы (именно для производства) в том, что в неё можно добавить любые фичи «на месте», особенно если они требуются для комнадной работы: скажем, пересылать новичку списки команд в зазипованном файле по мейлу, которые ему потом надо будет импортировать в тот же Docklight или подобные утилиты — не совсем удобно.
Я там планировал добавить возможность логирования всего трафика, бегущего через порты, для последующего анализа. Опять же, в условиях производства, где работают тысячи устройств одновременно, можно начинать обрабатывать подобные массивы данных для поиска всяких проблем. Но и для рядового пользователя/инженера/тестера это просто удобный инструмент для отладки COM-порта на самом «низком» уровне
Так же легко потом делать шейринг таким спискам.
Там есть возможность записи последовательностей команд (наподобие записи макросов, как были в Visual Studio или в Selenium IDE), их прогонки и пр.
Одним из преимуществ подобной системы (именно для производства) в том, что в неё можно добавить любые фичи «на месте», особенно если они требуются для комнадной работы: скажем, пересылать новичку списки команд в зазипованном файле по мейлу, которые ему потом надо будет импортировать в тот же Docklight или подобные утилиты — не совсем удобно.
Я там планировал добавить возможность логирования всего трафика, бегущего через порты, для последующего анализа. Опять же, в условиях производства, где работают тысячи устройств одновременно, можно начинать обрабатывать подобные массивы данных для поиска всяких проблем. Но и для рядового пользователя/инженера/тестера это просто удобный инструмент для отладки COM-порта на самом «низком» уровне
Слишком сложно. Ну, или я не понял задачу.
Железо вроде moxa запросто туннелирует rs232/422/485 в ethernet.
Если надо буферизовать, можно хоть на raspberry.
я правильно понимаю, что postgres, mongo db и redis живут в сервисе, у которого 0 rps и пара сущностей в модельках?)
Правильно :) Ведь это всего-лишь демо.
Правда, моделей пока что ок. 20-ти, и, опять же, был бы рад идеям (ну, или назовём это feature-request).
Кстати, попользуйтесь, может, увидите в этом некое удобство, заодно и сможете подкинуть пару идей ;)
Опять же, будет интерес у публики — допилю, доведу до ума хотя бы внешний вид
Правда, моделей пока что ок. 20-ти, и, опять же, был бы рад идеям (ну, или назовём это feature-request).
Кстати, попользуйтесь, может, увидите в этом некое удобство, заодно и сможете подкинуть пару идей ;)
Опять же, будет интерес у публики — допилю, доведу до ума хотя бы внешний вид
Вместо Raspberry Pi pf за такие же деньги можно купить б.у. ноутбук. Но это будет полноценное устройство с клавиатурой, экраном, неумирающим от частой записи HDD и любой полноценной ОС. Да, вместо 2Вт он будет потреблять 10-15, но часто это не критично.
В подобной конфигурации ноутбук неудобен и громоздок. Нет нужды в клавиатуре и экране. Там нужен просто несложный компьютер, к которому через USB подключаются все наши устройства, а через сеть с этим компом можно ими управлять. Raspberry там был бы идеален, но начальник побаивался переводить всю инфраструктуру на Linux
А чего именно в Linux так побаивается Ваш начальник?
НЛО прилетело и опубликовало эту надпись здесь
Как и на любом производстве, особенно если речь идёт о сравнительно небольшой компании, всегда очень остро стоит проблема непрерывности процесса. Т.е., взять тройку ребят и посадить их за долгосрочную разработку — это значит, их надо отрвать от сиюминутных насущных проблем производства (повторюсьм завод не очень большой, ресурсы несколько ограничены, людей взять неоткуда). Кстати, переход на Python, а не, скажем, LabView, позволил подготовиться к движению в любом направлении (Python-аппликации во многих случаях очень легко переводятся с одной платформы на другую).
Скажем, одной из таких проблем была необходимость гарантировать рабочие драйвера для всего зоопарка устройств, с которыми работали. Проблемы легаси, отсутствие унификации многих схем и процессов создавали серьёзные препятствия для быстрой и безболезненной миграции с одной схемы на другую
Скажем, одной из таких проблем была необходимость гарантировать рабочие драйвера для всего зоопарка устройств, с которыми работали. Проблемы легаси, отсутствие унификации многих схем и процессов создавали серьёзные препятствия для быстрой и безболезненной миграции с одной схемы на другую
НЛО прилетело и опубликовало эту надпись здесь
-Raspberry это headless режим. Да, можно подключить экран, но это совсем другие размеры и деньги. И все равно нет ни мыши ни клавиатуры.
-На ноутбук я могу поставить Windows и просто скопировать туда тонну готовых программ. Например, для настройки одного устройства я написал конфигуратор на Qt под Windows. Даже не представляю, насколько будет трудно собрать его под Raspberry.
Понятно, что для какого нибудь законченного устройства, например, вендинговый автомат, то лучше использовать Raspberry или MiniITX плату. Но если вы хотите сделать систему домашнего видеонаблюдения, то сойдет и ноутбук, закинутый в кладовку.
-На ноутбук я могу поставить Windows и просто скопировать туда тонну готовых программ. Например, для настройки одного устройства я написал конфигуратор на Qt под Windows. Даже не представляю, насколько будет трудно собрать его под Raspberry.
Понятно, что для какого нибудь законченного устройства, например, вендинговый автомат, то лучше использовать Raspberry или MiniITX плату. Но если вы хотите сделать систему домашнего видеонаблюдения, то сойдет и ноутбук, закинутый в кладовку.
Прошу прощения, а зачем к Raspberry вообще что-то подключать? Она прекрасно видится через вайфай. Никаких проводов. Просто сидите за своим компом и рулите ей. Чем не вариант?
НЛО прилетело и опубликовало эту надпись здесь
Включение при подаче питания можно сделать щелкая контакты кнопки с помощью ардуины. Возможно даже сработает большой электролит параллельно кнопке.
Обычно сервера для наблюдения, хостинга и т.п. делаются под Linux Server, там проблемы с обновлениями нет.
Откуда взялось «не долговечен если 24\7»? У меня ноут годами работает как роутер и сервер. Только пыль иногда продуваю, потому что в комнате пыли много.
Обычно сервера для наблюдения, хостинга и т.п. делаются под Linux Server, там проблемы с обновлениями нет.
Откуда взялось «не долговечен если 24\7»? У меня ноут годами работает как роутер и сервер. Только пыль иногда продуваю, потому что в комнате пыли много.
Прошу прощения, возможно не догоняю, но мне не совсем понятно, с чем вообще была связана проблема послать и принять что-то по UART? С СОМ-портами работать весьма просто, что с виртуальными через мост usb-uart, что с реальными на древних компах. Зачем Вам потребовалась какая-то специальная программа типа Docklight, как-то осталось не очень понятным. Я сам сейчас делаю похожий проект. Нужно испытывать различную электронику при высоких температурах (желательно 160 градусов, но хорошо если будет работать и при 130). Контроллер управляет бытовой электрической печкой (купил в Ашане), устанавливает напряжение питания испытуемого устройства от 2 до 5 вольт, с измерением тока потребления и защитой, подаёт два испытательных аналоговых сигнала и вяжется с устройством по uart. Сделал всё на одном esp32 DevKit v.1 плюс небольшой кучке рассыпухи (тиристоры, операционники и т.п.). Рулится всё тоже через веб-страничку. На компе запускается небольшой серверок написанный на яве (я питон не очень люблю) через него работает страничка в броузере плюс он же вяжется с esp32 по вайфаю. Дико удобно. Печка может стоять в любом месте лаборатории не загромождая стол.
Да, конечно, я не спорю, что для отдельного разработчика вполне сойдёт и терминал — кому что удобнее. Но когда речь идёт о производственной линии, возникает необходимость в удобной графической оболочке, с централизованным и унифицированным доступом и возможностью заточить любую функцию под цех/линию/компанию. Особенно, в случае, если часто возникает необходимость в частом ручном повторении рутинных операций, которые так и «напрашиваются» на автоматизацию.
Многие недоумевают, почему и зачем это делалось. Повторюсь, кроме желания поиграться и покодить, подобная система особенно удобна в производственных условиях, где часто возникают неполадки и необходимо вручную пощупать устройства. Довольно расточительно тратить время на повторяющиеся операции, типа сопоставления имён устройств и соотв. им системных портов. Или ручных загрузок файлов со списками команд для каждого устройства. Если речь идёт об одном компьютере, который стоит у вас на столе, к которому подключены максимум с десяток таких устройств, и ты легко держишь в уме их всех, то да — моя система лишь даёт небольшие преимущества при удалённой работе и возможности запускать Agent хоть на Raspberry, хоть на Windows. Но когда речь заходит о сотне-другой подобных тестовых стендов (стенд — имеется в виду Test Fixture и его индивидуальном компьютере), а на каждом стенде по 5-10 устройств, то при всём желании, запомнить все порты и ассоциированные с ними устройства с их спецификой — это уже слишком. Вот я и строю нечто, что позволит минимизировать подобные неэффективности и даст возможность вносить изменения любому пользователю системы на свой вкус
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Удалённое управление UART'ом через Web