Вопросы по библиотеки libmodbus

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

У меня схема построена так: В момент передачи данных с передатчика данные возвращаются сразу на приемник «ЭХО» и передаются на slave. После slave отвечает.

Получается что в буфере приемника будут появляться два типа данных от мастера и от slave.

Двух проводной RS-485.

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

Нет вы не поняли. Есть физический уровень модбус. По диф. паре передаются данные только в одном направление.

Пример двухпроводной RS485 http://www.modbus.org/docs/Modbus_over_serial_line_V1.pdf стр 22/44. Там показано что передатчик замкнут на приемник, смотреть master.То есть когда на линии D есть данные то данные сразу идут и на линию R.

Если я включу

    modbus_t* my_modbus = modbus_new_rtu("/dev/ttyAPP1", 4800, 'E', 8, 1);
    modbus_set_slave(my_modbus, 0x00);
    modbus_rtu_set_serial_mode(my_modbus,MODBUS_RTU_RS485);
    modbus_rtu_set_rts(my_modbus, MODBUS_RTU_RTS_NONE);

Много лет использую libmodbus - не разу не приходилось получать свою передачу. Этим занимается не программа, а железо. То, что приемник и передатчик условно показаны соединенными на схеме не означает, что они работают одновременно. И железо само определяет направление без всякой программной поддержки.

И железо само определяет направление без всякой программной поддержки

Вот как раз железо и не определяет этого.

Есть еще один вариант 4 проводная RS485. Так вот там выделены линии под передатчик и приемник. И там нет эха.

Этим должна заниматься программа, дергать вывод RTS. В библиотеки libmodbus есть для этого функция «modbus_rtu_set_rts»

Никто не поднимал с помощью libmodbus двухпроводную передачу по RS485 без использования RTS?

Действительно не понимаю, почему у вас физически реализовано эхо!? Еще раз протокол modbus rtu подразумевает наличе crc суммы - т.е ваш slave после получение посылки должен рассчитать эту сумму, откинув последние слово, и сравнить с последним словом - если верно - он должен выполнить запрос или ответить о невозможности выполнения, если нет - то должен вернуть ошибку передачи данных, все согласно протоколу. Т.е ваше эхо засирает канал связи лишними сообщениями - его быть не должно, так как контроль того что пришло обеспеченно протоколом modbus rtu. Если бы вы использовали modbus tcp - то целостность обеспечивал протокол tcp.

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

Под эхом понимаю возврат сигнала мастера. К коду ошибок это не относиться. Да вы правы есть специальные микросхемы типа MAX13487 которые могут блокировать прием на время передачи, на аппаратном уровне. Но у меня стоит дубовая SP485 она не может ни чего, поставить другую не могу. Остается мне только включить вывод RTS установить время срабатывания и начать работать. Для этого мне нужно правильно настроить RTS. Есть пример https://github.com/stephane/libmodbus/blob/master/doc/modbus_rtu_set_rts.txt

modbus_t *ctx;
uint16_t tab_reg[10];

ctx = modbus_new_rtu("/dev/ttyS0", 115200, 'N', 8, 1);
modbus_set_slave(ctx, 1);
modbus_rtu_set_serial_mode(ctx, MODBUS_RTU_RS485);
modbus_rtu_set_rts(ctx, MODBUS_RTU_RTS_UP);

if (modbus_connect(ctx) == -1) {
    fprintf(stderr, "Connexion failed: %s\n", modbus_strerror(errno));
    modbus_free(ctx);
    return -1;
}

rc = modbus_read_registers(ctx, 0, 7, tab_reg);
if (rc == -1) {
    fprintf(stderr, "%s\n", modbus_strerror(errno));
    return -1;
}

modbus_close(ctx);
modbus_free(ctx);

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

и вам просто достаточно игнорировать мастер пакет

А libmodbus позволяет получить два пакета и мастера и слейва?

Я вызвал функцию modbus_read_registers а она вернула мне -1.

вот хз ему вообще должно быть как то пофиг, что в буфер прилетело то он и разбирает, скорее всего он (libmodbus) будет фильтровать это автоматически -это логично, учитывая что ваша проблема вообще не гуглится

вывод ошибки посмотрите

The modbus_read_registers() function shall return the number of read registers if successful. Otherwise it shall return -1 and set errno.

rc = modbus_read_registers(ctx, 0, 10, tab_reg);
if (rc == -1) {
    fprintf(stderr, "%s\n", modbus_strerror(errno));
    return -1;
}

Пишет connection timed out

значит проверять надо выше, почему-то либо порт не открыт либо ваше устройство не ответило

Да там была проблема с сигналом. Когда исправил получил новую ошибку invalid data invalid CRC.

уже интересно ошибка передачи данных - у вас точно устройство исправно или вы уверены что оно считает именно crc modbus - а то этих crc как собак нерезанных

Устройство мной разработано. При приеме данных (слейв) я сначала считаю CRC и если совпадает то смотрю адрес ---> функцию ---> и т.д. Если бы CRC считалось бы неправильно то слейф сказал бы мне об этом.

Заведи DE на RE и этого по идее хватит. 485 и так полудуплекс.

Значит ответ приходит с неправильно рассчитанным crc (либо crc не modbus) или с битыми данными

Мне кажется эта из-за эха.Он ловит свою же посылку начинает разбирать ее а там недостача данных или еще что.

А в IMX287 нету аппаратной возможности подключения RTS. И программную не включили вот сижу мучаюсь пишу драйвер для RS485 :(.

Смотрю протокол не может быть такого. В любом случае цепанитесь picocom или minicom вместо своего мастера, вручную пошлите запрос и посмотрите что придёт назад

Хорошая идея. В buildroot picocom есть?

не помню

Можешь проверить у себя. Замки rx на tx и попробуй связаться со слейвом. У тебя получится эхо и связь.

не могу, просто неначем

Ну неужели библиотека не умеет бороться с эхом.

без понятия, я не уверен что это эхо надо смотреть что назад приходит, хотя если подумать. Разница между запросом и ответом, помимо данных составляет одно поле - размер сообщения, допустим что что пришло эхо тогда если библиотека считает что это ответ то она считает данных на величину которое будет являться адрес первого запрашиваемого элемента, считает все остальное оно будет считать crc - тогда будет ошибка. Заплатка: открыть тот же порт на чтение и забрать данных на величину эхо потом вызвать чтения ответа. Но я посоветовался с коллегой - он говорит что эхо в нормальном варианте устройства быть не должно вообще

Сначала драйвер потом библиотека.

Сегодня завтра допишу драйвер а потом займусь библиотекой

modbus_rtu_set_rts

Она требует поддержки адаптером этого режима? Или в юзерспейссе эмулирует?

Если бы CRC считалось бы неправильно то слейф сказал бы мне об этом.

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

И железо само определяет направление без всякой программной поддержки

FT232 на линию CBUS2 выводит сигнал DE. Можешь от этого оттолкнуться, если допустимо USB юзать.

специальные микросхемы

MAX485 за 5 рублей такое умеет. Причём RE и DE в противофазе - тупо кидаешь на них один сигнал, и эха нет.

Я капец невнимательный.

Сделал драйвер для RTS и модбус заработал :). Эхо мешало ему . теперь эха нет. Пишу программу дальше.