Обработка необычного ответа из ведомого регистра - добавлен дополнительный «FF» от производителя - PullRequest
1 голос
/ 17 июня 2019

Я успешно подключаюсь к микроконтроллеру через RS485 (переходник USB-RS485 через COM-порт Windows).Я написал небольшую программу, использующую minimalmodbus для обработки связи по протоколу Modbus RTU, и она отлично работает.

Микроконтроллер, с которым я общаюсь, также имеет контакты TTL, и производитель сделал что-то очень странное.Они добавляют гекс ('FF') x 3 перед ответом юнита.Как вы можете себе представить, это вызывает у меня кучу головных болей, когда я пытаюсь разобраться, как справляться с ответами.Я изменяю различные разделы библиотеки minimalmodbus (копия, установленная для локальной разработки), пытаясь заставить ее принять полный ответ, а затем убрать первые три шестнадцатеричных символа 'FF', чтобы получить правильную полезную нагрузку.Пока что я неудачник.Я думаю, что этот производитель сделал это, чтобы использовать 3 x 'FF' в качестве механизма синхронизации, и они предоставляют USB-ключ, который имеет этот фильтр 'FF', доступный в качестве опции.Моя программа будет работать с использованием этого фильтра FF.Однако я хочу использовать свои собственные устройства и библиотеку minimalmodbus, поэтому мне интересно, как убрать эти ведущие символы 'FF'.У кого-нибудь есть мысли?@jonasberg

Я пытаюсь изменить разделы разветвленной библиотеки minimalmodbus, установленной в процессе разработки pip3`.Лучшее, что я получил на данный момент, - это странный ответ, но его стоит упомянуть.Я посылаю read_register аск hex(225) и получаю обратно десятичное значение 2500. Аналогично, если я делаю hex(220), я возвращаюсь 2000, и отправка hex(224) дает мне 2400 в качестве ответа.Я подумал, что, возможно, устройство повторяет запросы, поэтому сейчас пробую варианты, касающиеся функции игнорирования эха в minimalmodbus, но пока безуспешно.

Мой код работает нормально при правильном использовании, поэтому я не думаю, что это поможет в этой ситуации.Мне действительно нужно удалить первые три 'FF' (шестнадцатеричные) значения, изменив пакет minimalmodbus.

Я получаю различные ошибки в зависимости от того, что я изменил.Первоначальной ошибкой была ошибка контрольной суммы:

'Checksum error in {} mode: {!r} instead of {!r} . The response is: {!r} (plain response: {!r})'

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

1 Ответ

0 голосов
/ 17 июня 2019

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

Напомним: у вашего микро есть два порта, на RS485 все работает как положено, но на другом UART, работающем с уровнями TTL, вы видите три старших байта 0xFF, прикрепленных ко всем ответам Modbus (хотя вы запрашиваете с помощью обычного Modbus, так что в кадры, которые вы отправляете, не содержат начальных байтов 0xFF).

Пока все хорошо, я надеюсь. Теперь мне не понятно, что ты хочешь делать. Хотите ли вы обмениваться данными с обоими портами, используя одну и ту же библиотеку minimalmodbus, или вам нужны только две отдельные библиотеки, по одной на каждый порт.

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

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

Это то, что я хотел бы сделать: из исходной minimalmodbus строки смены библиотеки 909 (в функции _communicate) читать:

        answer = self.serial.read(number_of_bytes_to_read)[3:]

Если я неправильно понял, и это совсем не то, что вам нужно, напишите комментарий, и я съем свою шляпу.

...