Jump to content

    
Sign in to follow this  
theilush

Согласование соединения RS-485

Recommended Posts

21 minutes ago, theilush said:

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

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

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

Share this post


Link to post
Share on other sites
26 минут назад, Oymyacon сказал:

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

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

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

Share this post


Link to post
Share on other sites
2 hours ago, Oymyacon said:

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

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

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

Edited by Eddy_Em

Share this post


Link to post
Share on other sites
39 минут назад, Eddy_Em сказал:

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

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

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

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

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

Share this post


Link to post
Share on other sites
5 minutes ago, Сергей Борщ said:

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

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

Share this post


Link to post
Share on other sites
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); //задержка (без нее не успевает отрабоать)
}

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

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

Edited by theilush

Share this post


Link to post
Share on other sites

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

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

Edited by theilush

Share this post


Link to post
Share on other sites
11.07.2020 в 15:44, Сергей Борщ сказал:

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

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

Edited by theilush

Share this post


Link to post
Share on other sites

Вы если будете на 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(), переключающий конвертер в режим приема (это тоже приведет к потери последнего байта).

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

 

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

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

Modbus?

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

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

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

Share this post


Link to post
Share on other sites

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

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

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

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

Share this post


Link to post
Share on other sites

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

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

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

 

slla036d_RS485.pdf

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this