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

В качестве драйвера RS485 использую MAX487. На выходе A сигнал нормальный, а вот на B, вместо инверсии A присутствует сигнал повторяющий A, но с гораздо меньшей амплитудой. В чем может быть дело?

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

[_VoRoN_ 0]

В качестве драйвера RS485 использую MAX487. На выходе A сигнал нормальный, а вот на B, вместо инверсии A присутствует сигнал повторяющий A, но с гораздо меньшей амплитудой. В чем может быть дело?

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

 

Схема собрана по образу и подобию вашей. Дело значит обстоит так (в пред. посте я перепутал): на выходе A сигнал очень слабый и представляет собой инверсию входного, сигнал на выходе B повторяет сигнал на A, но с нормальной амплитудой.

Растяжки стоят в соответствии с вашей схемой.

[rezident 0]

Дело значит обстоит так (в пред. посте я перепутал): на выходе A сигнал очень слабый и представляет собой инверсию входного, сигнал на выходе B повторяет сигнал на A, но с нормальной амплитудой.

Растяжки стоят в соответствии с вашей схемой.

Если вы запамятовали, то напоминаю, что сигнал на выходе драйвера дифференциальный и наблюдать его нужно не относительно GND, а непосредственно между сигналами A и B. Например, на сигнал A щуп осциллографа, а на сигнал B землю щупа осциллографа. При лог.1 на входе драйвера на выходе должно быть A > B, при лог. 0 на входе B > A.

[_VoRoN_ 0]

Дело значит обстоит так (в пред. посте я перепутал): на выходе A сигнал очень слабый и представляет собой инверсию входного, сигнал на выходе B повторяет сигнал на A, но с нормальной амплитудой.

Растяжки стоят в соответствии с вашей схемой.

Если вы запамятовали, то напоминаю, что сигнал на выходе драйвера дифференциальный и наблюдать его нужно не относительно GND, а непосредственно между сигналами A и B. Например, на сигнал A щуп осциллографа, а на сигнал B землю щупа осциллографа. При лог.1 на входе драйвера на выходе должно быть A > B, при лог. 0 на входе B > A.

 

Да нет, я не забыл, просто запутался :)

 

Схема нормально работает на 9600 и 38400, однако на на 115200 проявляется потеря данных ~10%.

[_VoRoN_ 0]

Все, зарубили идею, а ведь почти получилось :( Для переключения использовать МК - распоряжение начальства. Теперь все с начала...

[zltigo 1]

Для переключения использовать МК - распоряжение начальства. Теперь все с начала...

Зачем сначала :-) диод-резистор-кондер заменяются на MK :-)

 

До тех пор пока не разберется с длительностью фрейма - изображает одновибратор. После разборок

- чеко управляет передатчиком.

Изменено 29 июля, 2006 пользователем zltigo

[Laptop 0]

Как приятно получить чёткие ответы (и множество) на вопрос который стоит передо мной, но я его не задавал. :)

А я с RTS воюю. На Delfi проблемы с формированием задержки. У меня правда плюс. Я делаю и то и это. Ну а под своё изделие я уж как-нибудь подстроюсь. :)

 

Кстати может у кого грамотный компонент есть для Delfi под COM порт.

Конечно есть, еще с 3-ей Дельфи:)

поиском нашел свежую ссылку:

TurboPower Async Professional

http://sourceforge.net/projects/tpapro/

[defunct 0]

Применение AVR не является возможным. Использование UART, видимо, было бы лучшим вариантом, но увы...

 

Класс, а чего ж тогда Вы вопрос задаете именно в этом форуме? Есть ведь и другие..

 

По сабжу, надежней чем "кондер-резистор-диод" Ваш конвертер с C4051 не станет. Если уж МК так почему именно такой плохой выбор? Ведь и AtTiny11/12/13, PIC12F625 запросто справятся с тривиальной задачей формирования задержки в N ms. А для того чтобы разрешить ваш вопрос достаточно удерживать линию в состоянии передачи не долее чем реакция вашего "отвечающего" девайса (вот это и как раз и будут те самые N ms).

[_VoRoN_ 0]

Применение AVR не является возможным. Использование UART, видимо, было бы лучшим вариантом, но увы...

 

Класс, а чего ж тогда Вы вопрос задаете именно в этом форуме? Есть ведь и другие..

 

По сабжу, надежней чем "кондер-резистор-диод" Ваш конвертер с C4051 не станет. Если уж МК так почему именно такой плохой выбор? Ведь и AtTiny11/12/13, PIC12F625 запросто справятся с тривиальной задачей формирования задержки в N ms. А для того чтобы разрешить ваш вопрос достаточно удерживать линию в состоянии передачи не долее чем реакция вашего "отвечающего" девайса (вот это и как раз и будут те самые N ms).

 

Да, с выбором контроллера вы определенно правы :) На 9600 работает четко, на 38400 - через раз, а вот на 115200 вообще отказывается. Судя по осцилограмме, просто не успевает переключаться в начале, до начала информационного бита, и съедает его добрую часть. Дальше по пакету все нормально.

[Леонид Иванович 0]

А я с RTS воюю. На Delfi проблемы с формированием задержки. У меня правда плюс. Я делаю и то и это. Ну а под своё изделие я уж как-нибудь подстроюсь. :)

Кстати может у кого грамотный компонент есть для Delfi под COM порт.

 

Правильнее сказать, не на Delphi проблемы с формированием задержки, а под Windows. Можно формировать так:

 

var

HighT:Double; //Hi-res. timer period, uS

 

procedure CalibT;

var F:Int64;

begin

QueryPerformanceFrequency(F);

if F=0 then F:=1;

HighT:=1000000.0/F;

end;

 

procedure Delay(Tm:Integer); //uS

var F1,F2:Int64;

begin

QueryPerformanceCounter(F1);

F1:=Round(F1+Tm/HighT);

repeat QueryPerformanceCounter(F2) until F2>F1;

end;

 

Но все эти программные задержки под Win на уровне юзера - фикция. Вставьте царапнутый CD в привод и наслаждайтесь полным зависоном десяток секунд :)

 

Что касается RTS, то в Async Professional под не-NT Win он переключается по концу посылки, который определяется прямым чтением регистра UART. Под NT Win используется режим RTS_TOGGLE, реализованный в стандартом драйвере COM-порта. Только работает он тормознуто.

[_artem_ 0]

Я недавно экспериментировал с этим - получал вроде бы гарантированную задержку по переключению RTS. Если применик держать все время в работаюшем положении а после передачи фрейма сразу же принимать данные то по окончанию последнего байта можно и деактивизировать RTS.

Во всех посылках байта переключение rts случалось по концу посылки без 50 миллисекундной неопределенности виндоза (посредством esccommfucntion ). Можно и по таймингу делать - но момент начала передачи байта железкой неизвестен .

 

Можно также использовать мультимедийный таймер - 1 миллисекунда разрешения получается, хотя некоторые говорят что может доходить и до трех .

[Леонид Иванович 0]

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

 

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

[goodwin 0]

Сам правда не пробовал, но в FTDI чипах USB-COM есть специальный аппаратный управляющий сигнал для переключения передатчика... По моему - самое простое решение. И питать 485-ый драйвер есть чем...

[_VoRoN_ 0]

Если кто знает, посоветуйте пожалуйста толковый компонент под С++ Builder 6 или Delphi 7 для работы с COM портом

[otrog 0]

Если кто знает, посоветуйте пожалуйста толковый компонент под С++ Builder 6 или Delphi 7 для работы с COM портом

Использовал "TMS Async32". Впечатления положительные.

http://www.tmssoftware.com/