Если я не ошибаюсь, вы правильно определяете свой вывод GPIO, но никогда не переключаете его высоко и низко.Чтобы получить сигнал DE / ~ RE на вашей микросхеме RS485, вы должны взять высокий уровень GPIO перед записью на шину и низкий уровень сразу после того, как сможете прочитать ответ с вашего счетчика.
К сожалению,Боюсь, что вы пытаетесь сделать это невозможно с pyModbus из коробки.Вы можете посмотреть по этой ссылке:
https://github.com/riptideio/pymodbus/issues/33
Возможно, вы сможете настроить pyModbus и использовать альтернативные функции RTS на вашем Pi (см. Здесь: https://github.com/mholling/rpirtscts),но я не думаю, что этот путь значительно повысит надежность.
Как я уже писал здесь: RS485: неподходящий ioctl для устройства , вам лучше выбрать аппаратное решение.Если вы не можете получить новое оборудование, вы всегда можете попробовать решение с таймером 555. По крайней мере, для временного исправления.
Удачи, и обязательно опубликуйте свой прогресс или любые дальнейшие идеи.
РЕДАКТИРОВАТЬ: Решение с использованием libmodbus вместо
Предложение использовать libmodbus было очень успешным. Выполните следующие шагиесли вы хотите попробовать его (протестировано с Raspberry Pi 3B):
1) Клонируйте вилку libmodbus с поддержкой GPIO для вашего Pi:
git clone https://github.com/dhruvvyas90/libmodbus
2) Настройте, скомпилируйте и установите библиотеку libmodbus (те же команды, что и для основного репо):
./autogen.sh && ./configure --prefix=/usr && make && sudo make install
3) Перейдите в папку rpi-test и скомпилируйте пример:
gcc -o test -I/usr/include/modbus test.c -lmodbus
4) Запустите проверку, вам нужно изменить разрешения или выполнить sudo: sudo ./test
То, что вы получаете, на самом деле намного лучше, чем я ожидал, и, вероятно, достаточно хорошо для большинства аппаратных средств Modbus:
Синим цветом вы видитеTX от UART Pi (контакт № 8 на разъеме) и желтым цветом вы получите свой DE / ~ RE (контакт № 11, GPIO17), который следует подключить к вашему чипу RS485.Как вы можете видеть, задержка составляет 0,6 мс от конца кадра данных Modbus до тех пор, пока шина не освободится для ответа ведомого устройства.На скорости, которую я использовал (9600 бит / с), минимальная задержка, необходимая для соответствия спецификации Modbus, составляет около 3 мс (3,5 символа), поэтому она должна подойти для большинства ситуаций.
Единственное, что ожидает, будетдобавить все эти функции GPIO в оболочку pylibmodbus, но это должно быть довольно просто.Я планирую использовать эту библиотеку из Python очень скоро в полевых условиях с моим компьютером Pocket Chip для работы в качестве портативного тестера Modbus, поэтому, если вам или кому-либо еще удастся найти время, я буду более чем рад его протестировать.
Как только у меня будет больше времени, я попробую libmodbus вместе с моим последовательным портом FTDI и сделаю несколько захватов области для сравнения аппаратной и программной сигнализации.
Я забыл упомянуть, чтоединственными изменениями, которые я внес в test.c, были:
Строка 13: #define UART_PORT "/dev/serial0"
Строка 14: #define BAUD_RATE 9600
Первое, только имявстроенный последовательный порт на моем Пи, а второй - скорость, которую я всегда использую для тестирования.
РЕДАКТИРОВАТЬ: Сигнализация между программным и аппаратным обеспечением
Как и было обещано, я протестировал предложенное решение с libmodbus , но вместо встроенного UART на Raspberry Pi я заставил его работать вместе с моим USB-адаптером FTDI, чтобы сравнить время, необходимое для освобождения шины.
Вы можете видеть, как TXEN (пурпурная трасса) достигает низкого уровня примерно через 250 микросекунд после стоп-битав то время как GPIO на Pi (синим цветом) занимает более или менее то же самое время, что и при захвате выше (500-600 микросекунд).
Итак, в ожидании более подробного тестирования, мой вывод libmodbus делает большую работу для UART, где у вас нет сигнала включения TX.Я думаю, что для большинства сценариев должна быть надежная связь Modbus.