Ненадежная связь с низким уровнем битрейта на Леонардо

Я использую Arduino Leonardo (точнее, этот продукт) для связи с сервомоторами) с помощью RS485.

Все работает нормально, пока я не опускаюсь ниже скорости передачи в бодах или 115200 бит / с. Если я опущусь ниже, как 57600 или 9600, я начну получать неправильно сформированные пакеты от своих двигателей: 4 первых байта обычно верны, но конец пакета содержит некогерентные данные, а контрольная сумма явно неверна.

Я использую библиотеку IndustrialShields (мой поставщик ПЛК/Arduino) для RS485, и я не вижу никаких упоминаний об этой проблеме. Я использую полудуплексную связь с U2X, если я правильно понимаю исходный код библиотеки.

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

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

Есть ли крайний случай, о котором я не знаю? Извините за отсутствие подробностей, я не уверен, что еще могу сказать.

, 👍-1

Обсуждение

Вы используете полудуплексный или полный дуплексный режим?, @Majenko

Полудуплексный с U2X. Отредактировано, чтобы добавить некоторые детали., @Hugal31

115200 имеет наименьшую погрешность. Вы видите знак минус перед ним? ;-) Хорошо, теперь серьезно: как вы настраиваете сервоприводы для более низких скоростей передачи в бодах? Как вы записываете данные в регистр скорости передачи данных? Сколько сервоприводов вы используете? Вы устанавливаете регистр BR на всех из них? Вы их связали цепочкой или используете контроллер для каждого двигателя? Ваш код также был бы полезен. И, если вы приковали их цепочкой, как вы поняли связь с обратной связью? Изображение вашей настройки также может показать нам сделанные вами подключения. Переключение направления на половинный дуплекс может быть проблематичным ( @Majenko ! )., @Peter Paul Kiefer

Я использую 3 двигателя с последовательным подключением и 1 контроллер. Я могу записать в регистр скорости передачи данных, используя протокол сервоприводов (http://emanual.robotis.com/docs/en/dxl/protocol1/). К счастью, они все еще правильно передают мои пакеты, так что я могу переключить их обратно на более высокую скорость передачи данных. Насколько я понимаю, обратная связь обрабатывается по времени, я жду 2 миллисекунды каждый раз, когда ожидаю ответа сервоприводов. Они настроены на ожидание 200 мкс после окончания пакета, прежде чем ответить. Я мог бы связать свой код, но между моей настройкой Arduino() и циклом() и библиотекой, которую я использую для связи, много кода., @Hugal31

Ах, теперь у меня есть представление о том, что происходит. Направление задается самим сервоприводом. Вы упомянули, что используете U2X с половинным дуплексом. Я знаю U2X как режим, в котором скорость передачи данных удваивается. Возможно ли, чтобы скорость передачи данных удваивалась, когда сервопривод отвечает на ваше сообщение, но не когда вы отправляете на сервопривод. Я не выяснил, где вы можете переключиться на поведение U2X, и я также не уверен, что U2X означает то, что я предполагаю. Но теория идеально соответствовала бы вашим наблюдениям. Отправка работает, но вы получили странные данные (например, неверную скорость передачи данных)., @Peter Paul Kiefer

Конечно, вы можете сказать, почему он работает со скоростью 115200 бод. Я не знаю. Возможно, U2X отключен от 115200 и выше. ?? У вас есть осциллограф, чтобы проверить, ошибаюсь я или нет?, @Peter Paul Kiefer

У меня с собой нет осциллографа. Я попытаюсь отключить U2X в исходном коде библиотеки, если найду, где (вероятно, в avr/cores/industrialshields/HardwareSerial.cpp, в библиотеке http://apps.industrialshields.com/main/arduino/boards/industrialshields-boards-avr-1.0.0.tar.bz2). Я только что переключился на другую тему, поэтому не смогу протестировать раньше, чем через несколько дней :/ Спасибо вам за внимание!, @Hugal31


1 ответ

Лучший ответ:

1

Я подозреваю, что виной всему интерфейс RS-485 в вашем сервоприводе. Ничего общего с Arduino, вашей коммуникацией или программным обеспечением.

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

  • В сервоприводе есть какой-то контроллер, который взаимодействует по шине
  • Этот контроллер может или не может напрямую управлять указателем направления на своем интерфейсе

Именно последнее имеет решающее значение. Существует способ подключения MAX485, который автоматически управляет выводом направления - сразу же после того, как вы начнете отправлять данные, он переведет их в режим TX. Проблема возникает при переключении обратно в режим RX - есть несколько способов сделать это:

  1. Вскоре после отправки последнего бита определенного значения (0 или 1) (поток битов сохраняет заряженный конденсатор)
  2. Через определенное время после начала общения.

Первый метод обычно более надежен при нескольких скоростях передачи в бодах, но может быть чувствителен к значениям отправленных байтов - если он полагается на 1, отправляемый для поддержания заряда конденсатора, и отправляется количество байтов 0, он не увидит 1, который поддерживает режим передачи открытым, и он может закрыться преждевременно.

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

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

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

,
Смотрите также: