[Oymyacon 0]

21 minutes ago, theilush said:

Данный метод еще не пробовал. Думаю, данный эксперимент проведу в ближайшее время, когда под рукой будет осциллограф.

Зачем осциллограф, когда нужны мультиметр и паяльник, а эти резисторы у Maxim в большинстве даташитов можно увидеть. Это как правило больше 2 кОм, один к питанию, другой - к земле.

Странно, но в даташите на MAX485 их нет ни на одной схеме 

[ViKo 1]

26 минут назад, Oymyacon сказал:

Странно, но в даташите на MAX485 их нет ни на одной схеме

Эти резисторы чувствительность понижают. В одном состоянии. А в другом - улучшают? Что-то здесь не так. Это, чтобы в стабильном состоянии при выключенном передатчике держать. 

Вижу, цепляют резистор со входа драйвера на A выход, добавляют размаху.

[Oymyacon 0]

Там ещё смотреть надо, как эти Danfoss в сеть включены и как сильно эфир забивают.

[Eddy_Em 1]

2 hours ago, Oymyacon said:

а эти резисторы у Maxim в большинстве даташитов можно увидеть. Это как правило больше 2 кОм, один к питанию, другой - к земле.

Что-то не встречал такого для MAX485. Да и зачем, если конвертер сам должен выдерживать нужные уровни?

Кстати, в даташите на MAX485 для линии связи нарисована витая пара. Без соединения земель. Странно как-то: скажем, CAN без соединения земель на длинных линиях как-то не очень-то работает...

Изменено 13 июля, 2020 пользователем Eddy_Em

[Vasily_ 41]

6 часов назад, theilush сказал:

не используя 61

А для кого производитель написал com RS485 ?

[Сергей Борщ 119]

39 минут назад, Eddy_Em сказал:

Да и зачем, если конвертер сам должен выдерживать нужные уровни?

Какой из конвертеров какие уровни должен выдерживать в паузе, когда все передатчики на шине отключены?

11.07.2020 в 07:43, theilush сказал:

Происходит отправка байтового массива, после чего происходит приём. В таком случае данные приходят не стабильно

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

[Eddy_Em 1]

5 minutes ago, Сергей Борщ said:

когда все передатчики на шине отключены?

Точно, это меня CAN с толку сбил… Действительно, в момент отключения одного и ожидания, пока другой ответит, на шине черт-те что твориться может!

[theilush 0]

18 часов назад, ViKo сказал:

А Com RS485 с этой землёй внутри ПЧ не связана?

Нет

15 часов назад, Сергей Борщ сказал:

Какой из конвертеров какие уровни должен выдерживать в паузе, когда все передатчики на шине отключены?

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

Stm32 запрашивает величину тока у каждого ПЧ: адрес ПЧ + функция чтения регистра + номер самого регистра + контрольный пакет данных (CRC). И того массив из 8 бит. Отправляет с помощью аппаратного прерывания:

void send(unsigned char *buf) {
  HAL_GPIO_WritePin(GPIOB, GPIO_PIN_15, GPIO_PIN_SET);
  HAL_UART_Transmit_IT(&huart1, buf, 8); 
}

Далее организован кольцевой буфер на прием сообщений обратно, должно прийти 9 бит, в котором содержится ответ на сообщение.

Так организовано ожидание 9 битов:

void recieve() {
  timme = HAL_GetTick();
  while (uart_available() != 9) if ((HAL_GetTick() - timme) > 350) break; //таймаут
  if (uart_available() == 9) {	//при получении 9 битов записываем их в массив для последующей обработки
		int m = 0;
		while(m != 9) current_msg[m++] = uart_read(); 
	}
  else for (int i =0; i<9; i++) current_msg[i] = '\x00';	//если ничего не пришло, значит обнуляем массив => проблема с соединением
  HAL_Delay(50); //задержка (без нее не успевает отрабоать)
}

Далее идет уже обработка принятого сообщение: расшифровка и принятие действия в зависимости от полученной информации.

Проблем с принятием сообщений у ПЧ не наблюдалось.

Изменено 14 июля, 2020 пользователем theilush

[theilush 0]

При объединении 61ой клемм с землей stm32 происходит хаус: на приеме происходят непонятные вещи (сначала примет от одного ПЧ, от всех остальных не получит, потом в хаотичном порядке поменяется), но как только подключу конвертер и подтяну землю через st-link, сразу все нормально начинает работать. Отключу от клемм 61 землю тоже работает. Оставлю только 3 ПЧ и stm32  без общей земли тоже работает.

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

Изменено 14 июля, 2020 пользователем theilush

[theilush 0]

11.07.2020 в 15:44, Сергей Борщ сказал:

А замерьте напряжение на линиях RS485 с переходником, улучшающим ситуацию и без него. Есть подозрение, что в этом переходнике есть растягивающие резисторы, сохраняющие состояние единицы на шине в паузах между передачами. Тогда для улучшения ситуации вам будет достаточно подтянуть линию A к +5 В, а линию B - к земле через резисторы ни 4.7 ... 1 кОм.

Сделал, как советовал Сергей: А подтянул к +5 В, В - к земле через резисторы в 1 кОм. Также все клеммы 61 соединил с землей stm32, конвертер отключен. Работает стабильно. Подожду несколько часов, посмотрим: появятся ли ошибки.

Изменено 14 июля, 2020 пользователем theilush

[Eddy_Em 1]

Вы если будете на STM32 работать с RS-485 через DMA на передачу, наверняка столкнетесь с тем, когда нужно переключить USART в режим приема. Делать это в прерывании по окончанию передачи данных DMA нельзя: последний символ будет потерян. Поэтому я организовал эдакий конечный автомат:

void usart_proc(){
    switch(st){
        case SENDING:
            if(txrdy) st = WAITING;
        break;
        case WAITING:
            if(USARTX->ISR & USART_ISR_TC){ // last byte done -> Rx
                _485_Rx();
            }
        break;
        default:
        break;
    }
}

Сейчас, кстати, косяк в своем коде заметил: я использовал USART1, поэтому не заметил, что в коде для DMA на USART2 остался макрос RS485_RX(), переключающий конвертер в режим приема (это тоже приведет к потери последнего байта).

[k155la3 26]

ps. надо проверить что все трансиверы 485 исправны полностью (из-за одного "подпаленного" может случиться такой балет). 

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

[Сергей Борщ 119]

 

7 часов назад, theilush сказал:

Stm32 запрашивает величину тока у каждого ПЧ: адрес ПЧ + функция чтения регистра + номер самого регистра + контрольный пакет данных (CRC).

Modbus?

7 часов назад, theilush сказал:

Так организовано ожидание 9 битов:

Наверное не битов, а байтов? Алгоритм какой-то уж больно простой. Любой шум в паузе приведен к приему ошибочного байта и этот байт испортит весь прием, даже если следом будут идти правильные данные со всеми защитными интервалами. 

[jcxz 184]

Я бы ещё посмотрел - какие драйверы линии RS-485 используются во всех устройствах висящих на данной шине RS-485? Судя из контекста топика: в устройстве ТС RS-485 - гальванически не развязанный, а значит его быстрей всего это не касается. Но в других устройствах на шине могут присутствовать устройства с оптической развязкой. Для таких устройств нужно какое-то время на переключение приём-передача (в дешёвых оптопарах оно может достигать даже миллисекунд (насколько помню)). Поэтому - если такое удалённое устройство что-то отправляло вашему устройству, то после завершения приёма этих данных, вашему девайсу сразу переключаться на передачу нельзя, надо выдержать минимальную паузу, требующуюся для переключения передача-приём в удалённом устройстве.

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

Поэтому лучше всегда (по возможности) использовать кодонезависимые протоколы обмена.

Также проблемы могут быть если на шине RS-485 присутствуют устройства с неверно установленной скоростью обмена. Не участвующие в обмене, а просто висящие на линии. Но которые в какой-то момент вдруг часть приходящего к ним на вход мусора могут воспринимать как валидный кадр, адресованный ему (так как также имеют слабый протокол обмена). И ответить на него. Сам сталкивался с такими ситуациями.

[iliusmaster 5]

Прочитайте стандарт на линию RS-485.Там все четко написано про формирование уровней. 

Сейчас на рынке присутствуют микросхемы как с встроенной схемой формирования уровней так и без. Подробности - внутри "даташита" производителя. 

Пока предлагаю ознакомиться с прикрепленным файлом, страница 11.

 

slla036d_RS485.pdf