Comments 9
Если допустимо время на переключение на другой источник, то наверно можно проще?
Не могу пройти мимо не рассказав про наш велосипед, о котором вы, вероятно, не слышали: UAVCAN. Мы решаем задачи построения распределённых вычислительных систем реального времени на транспорте и в робототехнике, что должно быть вам довольно близко. Например, у нас есть обобщённый интерфейс, заменяющий FreeMASTER, текстовый терминал, и экспорт в матлаб в вашем примере, вот тут есть небольшой (пусть и из другой области) пример на основе CAN (ещё поддерживаются UART, TCP, UDP, etc.): https://github.com/UAVCAN/demos/tree/main/udral_servo
Наша большая проблема (которая делает наше решение непригодным в вашем случае) это отсутствие вменяемого графического интерфейса -- пока всё через консоль (Windows тоже, впрочем, поддерживается), но:
Было бы интересно собрать с вас обратную связь по этому поводу, хотя бы просто в формате общих рассуждений. Если будет возможность и интерес, буду рад пообщаться на эту тему в личке или в телеграме (ссылка в профиле).
Тут главное отличие вашего подхода от моего в том что я делаю системы где в сети только мои устройства и только я один разработчик.
Я свободен менять парадигмы на лету ни с кем не согласовывая и не вводя избыточную функциональность не нужную в данный момент мне.
В моем демо-проекте ведь тоже есть обмен по CAN и также как в UAVCAN он может быть организован схеме publish/subscribe или request/response.
Это же по сути только несколько строчек в приемнике сообщений и в передатчике.
Мне не нужен data structure description language (DSDL) как в UAVCAN, поскольку я свободно все могу описать структурами C-и, мне не нужна универсальность. Я точно знаю на каких программно-аппаратных платформах буду работать на несколько лет вперед. Потому что я сам их делаю.
Если мне нужно некое особенное преставление данных и сериализация данных я просто разрабатываю это на ходу за пару часов и вставляю во все устройства, не пишу по поводу этого никакую документацию и ни с кем не согласовываю. Это значительно проще чем втягиваться в коллективный проект, читать спецификации и пытаться внедрить туда нужные изменения.
У меня есть файл общий для всех устройств CAN_bus_defs.h где я свободно создаю идентификаторы какой угодно структуры. Могу даже часть идентификаторы выделять под данные для быстроты передачи.
Когда же сталкиваюсь с необходимостью интеграции в промышленные системы сторонних производителей то использую стандартные решения типа CANopen, MODBUS, SNMP, MQTT и проч.
Т.е. у меня приоритет скорость разработки за счет сужения фокуса на конкретной функциональности, а не гибкость, переносимость, универсальность, мультиязычность.
Но при этом у меня каждая функция профилирована, я точно знаю сколько времени уйдет на отправку сообщений, какая у меня емкость очередей сообщений, как загружена шина, получаю алярмы если превышаю пропускную способность шины, знаю точно приоритетность сообщений.
Я не хвалю свой способ. Он явно не масштабируемый. Но просто объясняю почему я не участвую в таких коллективных проектах как UAVCAN, у меня на такое просто не хватит сил.
А такие GUI движки как FreeMaster можно найти у любого крупного производителя или поставщика софта для embedded.
Я пробовал: SEGGER SystemView, Micrium μC/Probe, STM32CubeMonitor
Смотрел: https://x2c.lcm.at/, разные плагины для MATLAB/Similink, LabVIEW Real-Time Module.
Но остановился на FreeMaster. Уж больно хорошо его сервер автоматизации вписывается в MATLAB.
Подскажите, а где можно такие симпатишшные провода в силиконовой оплетке прикупить?
Есть очень симпатичные гибкие провода для высоковольтных щупов, 6733-2, фирма Pomona.
Спасибки.
Недавно приобрел три щупа 5243.
Все три штуки пришли с кривыми колпачками, хотя на фото товара они прямые.
Под цветом RED у них подразумевается тёмно-коричневый.
Конструкция хлипкая, непродуманная, паять неудобно, т.к. всё решают доли миллиметра.
Надежды на использование осциллографов с автономным питанием здесь не оправдаются. Они покажут точно такой же шум от синфазных помех как и стационарные осциллографы.Вот бы эту тему пошире раскрыть, с картинками )
Разработка контроллера резервного питания. Технология отладки и тюнинг