Ошибка Modbus: [Недействительное сообщение] Получено неполное сообщение, ожидается не менее 2 байтов (получено 0)

Во-первых, позвольте мне сказать, что мне приятно ответить на такой хорошо сформулированный вопрос. Не все тратят столько усилий на объяснение того, что они сделали и как они это сделали. Ваш вопрос - плюс один сразу после того, как вы закончите его читать.

Теперь о твоей проблеме. Вы пропустили один очень важный шаг в руководстве, которому вы следовали. Как вы говорите, Modbus полудуплексный ¹, у вас только два провода, и только одно устройство может разговаривать по шине, поэтому вам нужен способ взять под контроль шину, так сказать . В вашем кабеле USB-RS485 / 422 это делается автоматически для вас аппаратным обеспечением кабеля (в частности, ваш кабель использует широко распространенный чип FTDI с сигналом TXEN -TX enable-, см. здесь для получения более подробной информации), поэтому вы заметили, что кабель работает хорошо. С другой стороны, ваш крошечный трансивер за 3 доллара - бедный брат, и у него даже нет UART, это просто несимметричный преобразователь в дифференциальный. Вот почему вам нужно предоставить сигнал DE / ~ RE (Drive Enable / Not Read Enable), чтобы бедняга знал, когда ему разрешено взять под контроль шину.

Это предупреждение, которое вы не взяли из учебника:

ВАЖНО: перед записью значений в модуль RS-485 контакты DE и RE должны быть ВЫСОКИМИ.

Это кажется достаточно простым, но если подумать, как работает Modbus ... на самом деле это не так просто. Эта строка кода:

rr = client.read_input_registers(1, 2, unit=3)

должен делать много вещей, если вы хотите успешно взаимодействовать с полудуплексом RS485: взять под контроль шину (в ваших настройках установить высокий уровень сигнала RE / ~ DE), отправить кадр запроса Modbus с запросом двух регистров на UNIT ID 3, сразу после окончания записи запроса (по прошествии 3,5 символов) отпустите управление шиной (теперь устанавливая RE / ~ DE low) и считайте ответ от ведомого.

Как я объясняю в ссылке, о которой я уже упоминал выше, есть несколько решений этой проблемы. Я предпочитаю (я больше разбираюсь в оборудовании) передает сигнал управления направлением шины аппаратно (лучший способ - иметь трансивер, в котором эта функция реализована аппаратно, например this one, но по ссылке вы также найдете решение DIY с использованием таймера 555). Теперь, если вы предпочитаете делать это программным способом, у вас есть несколько вариантов. Вы можете настроить pymodbus для переключения строки управления в соответствии с потребностями Modbus (в цитированном мной ответе есть несколько ссылок) или, если вы предпочитаете более нестандартное решение используйте libmodbus.

Если вы выберете этот последний вариант, вы можете найти все подробности о том, как собрать и установить lidmodbus с полудуплексной поддержкой, используя контакты GPIO на Rpi, и если вы хотите остаться на Python, установите wrapper и протестируйте базовый пример. Также есть несколько снимков экрана осциллографа, чтобы увидеть разницу между переключением линии с помощью программного обеспечения и оборудования. Для большинства домашних целей или любителей вы должны иметь возможность использовать переключение программного обеспечения, но я бы не стал доверять ему для промышленных или более важных приложений.

В завершение, думаю, стоит ответить на все ваши вопросы по очереди:

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

Ну и да, и нет, и возможно ... Как вы читали выше, проблема не в pymodbus. Это просто ожидает, что вы или ваше оборудование позаботитесь о не столь незначительных деталях управления доступом к шине. Я думаю, что большинство людей используют такую ​​библиотеку для Modbus TCP, поэтому для большинства пользователей это никогда не проблема. В общем сценарии Modbus, когда у вас есть ПЛК, который общается с другим устройством через Modbus RTU по каналу RS485, проблема решается с помощью оборудования, поэтому вам также не придется беспокоиться об этом.

Я знаю, что некоторые люди говорят о том, что Raspberry Pi имеет 3,3 В на контактах и ​​не работает с 5-вольтовыми контактами. Несмотря на это, похоже, что все учебники игнорируют этот факт и работают. - Или они просто притворяются, что это работает? В спецификациях TTL указано, что все выше 2,5 В будет считаться ВЫСОКИМ. Итак, в ТЕОРИИ 3,3 В должно быть в порядке, как и предполагают учебники.

Правильно, MAX485 datahseet указывает пороговые значения для VIH и VOL, и если вы используйте 5 В для питания ваших трансиверов, разные логические уровни не будут проблемой (в этом конкретном случае обратите внимание, что это не общее утверждение, другие устройства могут выйти из строя или в конечном итоге выйти из строя, если вы смешаете логические уровни).

Я намеренно еще не подключил резисторы к проводам tx / rx для повышения / понижения. Учебники их не предлагают.

Скорее всего, вам не потребуется подключать к шине согласующие резисторы для собственного проекта. Для длинных автобусов (на заводе или предприятии, где устройства могут находиться на расстоянии сотен метров друг от друга) вы, вероятно, будете беспокоиться об этой проблеме. В вашем крошечном трансивере уже есть согласующие резисторы, поэтому лучше не добавлять сопротивление. Для вашего кабеля у меня не хватило терпения найти руководство (не знаю, есть ли оно; у меня есть аналогичный кабель, и единственный способ быть уверенным - снять крышку и заглянуть под его колпак).

Как только вы все настроите и запустите, обратите внимание, что на вашем клиенте:

print(rr)

Должно быть:

print(rr.registers)

Если вы хотите, это показать прочитанные вами значения.

Как и предполагал Маркос Г. выше, я модифицировал pymodbus для управления выбранным GPIO.

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

программное решение, изменяющее pymodbus

Найдите файл «sync.py» в папке «client», чтобы изменить клиентскую / главную сторону вашей установки.

Я модифицирую клиент / мастер здесь, так как на этой стороне у меня «плохое» оборудование RS485. Если у вас есть две из этих «плохих» аппаратных вещей, вам может потребоваться изменить и серверную часть.

Файл sync.py, вероятно, можно найти в

~ / .local / lib / python3.5 / сайт-пакеты / pymodbus / клиент

Это может варьироваться в зависимости от используемой версии Python. У меня сейчас 3,5. Часть «~ /» означает, что он находится в вашей домашней папке. Точка перед "local" делает файл стандартным скрытым. В терминале вы также можете использовать команду «ls -al» для отображения скрытых файлов. Графический пользовательский интерфейс вашего дистрибутива Linux наверняка также сможет каким-то образом отображать скрытые файлы.

В начале файла "sync.py" добавьте следующий код:

import RPi.GPIO as GPIO
pin_de_re = 7
GPIO.setwarnings(False)
GPIO.setmode(GPIO.BOARD)
GPIO.setup(pin_de_re, GPIO.OUT, initial=GPIO.HIGH)

Это может выглядеть примерно так:

more imports ...

from pymodbus.transaction import ModbusSocketFramer, ModbusBinaryFramer
from pymodbus.transaction import ModbusAsciiFramer, ModbusRtuFramer
from pymodbus.client.common import ModbusClientMixin

import RPi.GPIO as GPIO
pin_de_re = 7
GPIO.setwarnings(False)
GPIO.setmode(GPIO.BOARD)
GPIO.setup(pin_de_re, GPIO.OUT, initial=GPIO.HIGH)

# --------------------------------------------------------------------------- #
# Logging
# --------------------------------------------------------------------------- #
import logging
_logger = logging.getLogger(__name__)

...more code

Установите пин-код по своему усмотрению. У меня контрольный контакт GPIO4 - это контакт 7 в Raspberry Pi / BananaPi.

Затем вы прокручиваете вниз и находите раздел под названием

# --------------------------------------------------------------------------- #
# Modbus Serial Client Transport Implementation
# --------------------------------------------------------------------------- #

Я изменяю этот раздел, так как использую Modbus RTU и, следовательно, последовательный порт для передачи данных.

В этом разделе вы должны найти определение «отправить»:

    def _send(self, request):
        """ Sends data on the underlying socket

Внутри этой функции найдите строку:

            size = self.socket.write(request)

И примите это с помощью булавки:

            _logger.debug("GPIO - Setting pin high")
            GPIO.output(pin_de_re, 1)
            time.sleep(.300)
            size = self.socket.write(request)
            time.sleep(.300)
            _logger.debug("GPIO - Setting pin low")
            GPIO.output(pin_de_re, 0)

Причина, по которой я использую строки "_logger.debug (" GPIO - Установка высокого / низкого уровня вывода ") ', заключается в том, что я затем вижу в журнале в терминале, что программа выполняет эти действия, и я могу быть уверен, что они выполненный. Если они не отображаются в журнале, я сделал это не в том месте - или что-то еще ...

Причина использования time.sleep (.300) заключается в том, чтобы дать оборудованию время для работы. .300 составляет 0,3 секунды. Большое количество в этом контексте.

Когда я использую вышеуказанное решение, я получаю следующие журналы.

Подчиненный / сервер:

2019-07-07 23:08:43,532 MainThread      DEBUG    sync           :45       Client Connected [/dev/ttyUSB0:/dev/ttyUSB0]
2019-07-07 23:08:43,533 MainThread      DEBUG    sync           :522      Started thread to serve client
2019-07-07 23:08:47,534 MainThread      DEBUG    rtu_framer     :232      Frame check failed, ignoring!!
2019-07-07 23:08:47,535 MainThread      DEBUG    rtu_framer     :128      Resetting frame - Current Frame in buffer - 0x3 0x4 0x0 0x1 0x0 0x82
2019-07-07 23:08:59,543 MainThread      DEBUG    rtu_framer     :180      Getting Frame - 0x4 0x0 0x1 0x0 0x2
2019-07-07 23:08:59,544 MainThread      DEBUG    factory        :137      Factory Request[ReadInputRegistersRequest: 4]
2019-07-07 23:08:59,544 MainThread      DEBUG    rtu_framer     :115      Frame advanced, resetting header!!
2019-07-07 23:08:59,544 MainThread      DEBUG    context        :64       validate: fc-[4] address-2: count-2
2019-07-07 23:08:59,544 MainThread      DEBUG    context        :78       getValues fc-[4] address-2: count-2
2019-07-07 23:08:59,545 MainThread      DEBUG    sync           :143      send: [ReadRegisterResponse (2)]- b'030404000500050846'

Мастер / клиент:

ModbusSerialClient(rtu baud[115200])
2019-07-07 23:08:55,839 MainThread      DEBUG    pymodbus_sync_client_example_2019.07.05-1319:165      ===================================
2019-07-07 23:08:55,840 MainThread      DEBUG    pymodbus_sync_client_example_2019.07.05-1319:166      Read input registers
2019-07-07 23:08:55,841 MainThread      DEBUG    pymodbus_sync_client_example_2019.07.05-1319:167      
2019-07-07 23:08:55,842 MainThread      DEBUG    transaction    :111      Current transaction state - IDLE
2019-07-07 23:08:55,842 MainThread      DEBUG    transaction    :116      Running transaction 1
2019-07-07 23:08:55,843 MainThread      DEBUG    transaction    :215      SEND: 0x3 0x4 0x0 0x1 0x0 0x2 0x21 0xe9
2019-07-07 23:08:55,843 MainThread      DEBUG    sync           :79       New Transaction state 'SENDING'
2019-07-07 23:08:55,844 MainThread      DEBUG    sync           :538      GPIO - Setting pin high
2019-07-07 23:08:55,845 MainThread      DEBUG    sync           :541      GPIO - Setting pin low
2019-07-07 23:08:55,845 MainThread      DEBUG    transaction    :224      Changing transaction state from 'SENDING' to 'WAITING FOR REPLY'
2019-07-07 23:08:59,516 MainThread      DEBUG    transaction    :300      Changing transaction state from 'WAITING FOR REPLY' to 'PROCESSING REPLY'
2019-07-07 23:08:59,518 MainThread      DEBUG    transaction    :229      RECV: 0x3 0x4 0x4 0x0 0x5 0x0 0x5 0x8 0x46
2019-07-07 23:08:59,519 MainThread      DEBUG    rtu_framer     :180      Getting Frame - 0x4 0x4 0x0 0x5 0x0 0x5
2019-07-07 23:08:59,519 MainThread      DEBUG    factory        :266      Factory Response[ReadInputRegistersResponse: 4]
2019-07-07 23:08:59,520 MainThread      DEBUG    rtu_framer     :115      Frame advanced, resetting header!!
2019-07-07 23:08:59,521 MainThread      DEBUG    transaction    :379      Adding transaction 3
2019-07-07 23:08:59,522 MainThread      DEBUG    transaction    :390      Getting transaction 3
2019-07-07 23:08:59,522 MainThread      DEBUG    transaction    :189      Changing transaction state from 'PROCESSING REPLY' to 'TRANSACTION_COMPLETE'
ReadRegisterResponse (2)

Коробка передач МОЖЕТ БЫТЬ не всегда, но она точно определяет причину проблемы и, следовательно, возможные решения.

Я пока не знаю, что у меня получится. Более стабильное железо точно.

Что касается модификации pymodbus или другого программного обеспечения в связи с этой проблемой, я хотел бы процитировать из следующий пост в другой угрозе:

Любой, кто запускает Modbus в многозадачной ОС, такой как Linux или Windows, никогда не сможет удовлетворить требованиям спецификации последовательного порта, это не обсуждается, задача обычно составляет 10 мс, поэтому выполнение требований по времени 3,5 мкс просто не подходит и никогда не будет .

Аппаратное решение предпочтительнее.

Благодаря Маркосу Г.