Modbus master RTU - Telegram - Дисплей HD44780. Прошу помощи.

[Serg_Grn]

Происходит что-то из ряда вон невероятное...
В проекте ESP32, работает как Modbus master RTU. Читает со слейва input reg. - 12 шт., holding reg - 10 шт., адреса подряд, начиная с нулевого.
Запись в holding reg - по команде.
Значения регистров получаю в Телеграм, т.е. я отправляю команду из телеграм и в ответ получаю значения всех holding reg., отправляю другую команду - значения всех input reg, по третьей команде в holding reg записываются константы.

Фокус в том, что всё это нормально работает пока в проекте есть дисплей HD44780 (на него я вывожу любые регистры). Но стоит из проекта убрать дисплей, как часть регистров отваливается - они постоянно равны 0. И не просто часть, а вполне конкретные номера регистров.
А именно, адреса регистров, которые всё время равны нулю:
Holding reg.: 5,6,7,8,9
Input reg: 0,1,2,3,4,11
При этом по остальным регистрам обмен идёт правильно! Я пробовал от слейва различные значения передавать: двух, трёхзначные числа, отрицательные значения... Всегда всё одинаково - именно эти адреса регистров в нуле, остальные работают.
И стоит добавить в проект дисплей, вывести на него часть регистров, как всё налаживается и все регистры работают!

Прошу участия, по возможности, так как сам я просто в ступоре от таких чудес...

Прикладываю проект с дисплеем, в котором все работает, и проект без дисплея (с пометкой error), в котором часть регистров не работает.
https://drive.google.com/drive/folders/ ... sp=sharing

[AlexCrane]

[ref]Serg_Grn[/ref], Видимо экран в качестве тормоза (задержки) основного цикла (loop) работает.

[Serg_Grn]

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

Сама по себе картина удивляет, такого раньше не встречал..)

[Sancho]

[ref]Serg_Grn[/ref], а кто у Вас в слэйвах?
Подключите его к opc инсат, вставьте один регистр или все, но в режиме последний в групповом запросе - будет читать по одному, посмотрите время опроса.

[Serg_Grn]

а кто у Вас в слэйвах?

В слейвах HMI панель, вот эта
http://www.raut-automatic.kiev.ua/operp ... 21-ru.html
И я подключал слейвом Овен ПЛК110-60-М, просто для проверки - обмен шёл нормально. Единственное, я не помню когда подключал Овен, был ли дисплей в проекте...

По ОРС вообще отдельный ребус!
Вчера потратили часа два на попытки опросить в качестве слейва OPC (Insat Modbus Universal MasterOPC Server 32), итог: мастер его опрашивает, в орс видно запросы, видно ответы, которые орс отправляет обратно, но при этом мастер не читает ни одного регистра - все регистры по нулям! Но! Если я пишу holding регистры (10 шт, от нулевого), то слейв орс их успешно получает!
Т.е. с ОРС чтение не работает вообще, хотя пакеты идут, а запись работает.


Время опроса в ОРС посмотрю.

Отправлено спустя 58 минут 36 секунд:

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

Я не совсем понял, опросить HMI панель орс сервером?

[Serg_Grn]

По проблеме отсутствия обмена с орс сервером по rs485, проблема решена.
А заключалась она в питании платы-преобразователя RS-485 TTL, вот такой:

RS485-TTL-Module-1.jpg

В описании платы сказано, что питать её можно от 3,3 до 5 В, но на самом деле при питании 3,3 В она не работает с некоторыми железяками с RS485. Поэтому, кто планирует пользовать такую плату, питание только 5В. Ну и делитель на резюках, если мк с уровнем 3,3В.

[Serg_Grn]

По проблеме с отсутствием ответов от слейва, кажется решение найдено, но насколько оно верно не знаю, судить специалистам...
Как я понимаю проблему, судя по наблюдениям: очень маленькая пауза между полученным ответом от слейва и отправкой следующего запроса, из-за этого некоторые слейв устройства не отвечают на часть запросов.
В результате ковыряний в коде, в функции _modbusMasterSendTxBuffer() строка delay(10) была перемещена на одну строку вверх - перед Serial2.write, чтоб она формировала задержку запроса слейву.
Итог: все регистры читаются.
[spoiler]

RTU_delay(10).jpg

[/spoiler]

[AlexCrane]

[ref]Serg_Grn[/ref], Delay (10) в том месте где она стоит по дефолту не понятно ее назначение, т.к. Serial2.flush() все равно ожидает окончания передачи исходящих данных.

[Serg_Grn]

Delay (10) в том месте где она стоит по дефолту не понятно ее назначение, т.к. Serial2.flush() все равно ожидает окончания передачи исходящих данных.

Согласен, поэтому Delay(10) переместили на одну строку вверх, а не просто добавили ещё одну строку Delay.
Не знаю насколько это правильно, но сделали так