Как управлять портом RS422 в режиме 485?

[IlyaPodbolotov]

Имеется компьютер Advantech со встроенным Com port RS485/422, на прицеле I7041D. По схеме объединить ножки 1 и 4 как Data-; 2 и 3 как Data+ (Правильно?). Но передача идет одновременно с приемом. Если DTS установить до отсылки в приложении Delphi то не успеваю принять ответ, переключаясь после отсылки сообщения. DCON Utilites тоже модуль не видят.

[Никита]

История древняя как мамонты... СОМ-порты advantech не умеют автоматически управлять направлением приема-передачи. В свое время долго с этим возились, закончилось покупкой преобразователя 232/485, вышло в разы дешевле трудозатрат на эти пляски с бубном. Отпишите, что за оборудование и что за программа, попробую вспомнить :)

[IlyaPodbolotov]

Никита, буду благодарен! Не только ради мелочной экономии, а простого способа исправления типичных объектов управления на компьтерно-адамовой связке. Протокол D-CON для просмотра 3 входных и установки 5 выходных сигналов и является узким местом в красивой развитой системе визуализации химического процесса. Приложение выполнено в Delphi с компонентом ASYNC TPORT, но может быть взять иной компонент, где легче организовывать направление обмена?

[Никита]

В DOSе еще реализуемо. Можно рискнуть в линуксе, если есть люди, готовые работать с модулями ядра.
В винде, особенно XP или Win7 - только ради секаса можно попробовать, но и то на уровне прямой работы с API.
Никаких компонент. Отдельный поток с возможностью управления приоритетом и "ручной" опрос. Ес-но есть шансы что все ресурсы будут работать на этот порт :)
Вот почти официальная позиция Advantech по этому вопросу:

When working under Windows 95, we found it's very difficult to control the RTS switch timing correctly cause Windows is a multi-task system. So it's almost impossible to get correct response from RS-485 device. For the RS-422/485 port on our CPU card, it's the same problem.
To solve this problem, our R&D develop a DLL driver that can switch the RTS signal correctly. Attached comtest2.zip is the and a VB 5.0 example to show how to use the functions in this DLL. Please notice that, due to the Tx+/Rx+ is looped back to TX-/RX- on COMpad-85 connector for RS-485 connection, the readback string will contain the command string & reply string. You need to fliter the command string in your program. This program works under Windows 95 only, not Windows NT.

К сожалению я на их сайте этого архива уже не нашел, да и 95 от NT сильно в этой части отличаются. С другой стороны ссылаются на GenieDAQ который якобы в настройках порта позволяет установить управление сигналом RTS и GenieDAQ у меня под NT4 работал. (Правда недолго, ибо сама по себе его функциональность весьма убога).
В общем в DCON еще шансы есть (если больше заняться нечем), а вот что-нибудь типа Modbus/RTU, для которого времена принципиальны - лучше даже не пробовать.
Еще раз озвучу свою точку зрения - за зарплату программиста на написание и отладку этого драйвера можно купить пару-тройку преобразователей с автоматическим управлением потоком, а если еще и накладные и налоги посчитать и упущенную прибыль - то все десять.
ИМХО, для компьютерно-адамовой связки наиболее кошерным является именно RS-232 и ADAM-4520, ну или современные USB-шные аналоги, а еще лучше Ethernet<->485, не помню номенклатуру адамов, но думаю найти несложно. Все попытки запустить в этом режиме родной порт - это самоделки со всеми вытекающими. Десять лет назад над этим бились профессор и два доцента, плюс несметное количество студентов и аспирантов. Окончательно победить не удалось. Иногда при каких-то условиях связь была, но полагаться на нее на объектах я бы не стал.

Да, кстати, благодарить-то не за что - у меня толком не заработало, так что готового решения нет. :)

[Степа]

СОМ-порты advantech не умеют автоматически управлять направлением приема-передачи.

Странно... Сколько пользовался - никогда проблем не было.
Единственная проблема с продукцией Advantech, с которой уже удалось столкнуться - деградация преобразователей ADAM 4520 со временем. Новый работает на 115200 без шуму и пыли, пятилетней выдержки /даже пролежавший запаяным в пленку на складе/ - может начать фордыбачиться уже на 19200: если ответ приходит достаточно быстро, то перед ответом на стороне RS232 проходят один-два мусорных байта. На более низких скоростях или при длительной паузе между "запрос-ответ" пока проблем не замечено.
А так - могучие порты. На испытаниях прекрасно отработали со скоростями до 115200 на линию длиной несколько десятков метров из пары обычных монтажных проводов /витухи тогда не случилось под рукой/ безо всяких терминаторов и прочего согласования. MOXA в этом плане пожиже будут, на ту линию карточка MOXA CP-132 вообще работать отказалась.

Приложение выполнено в Delphi с компонентом ASYNC TPORT, но может быть взять иной компонент, где легче организовывать направление обмена?

Лучше всего - непосредственно на API, безо всяких компонентов. Так будет быстрее и надежнее всего.
Протокол DCON несложный /когда делал имитатор для собственных целей, так, для удобства, уместил все запросы и ответы с описаниями нормальным читабельным шрифтом на страницу; если с учетом запросов для аналоговых блоков - будет на двух страничках/.

[Никита]

Странно... Сколько пользовался - никогда проблем не было

Степа, уточню - речь о встроенных портах промкомпьютеров и панельных ПК от Advantech, работающих в режиме 422/485. Все платы контроллеров портов, адамы и прочее железо специально созданное под 485-й функцию управления направлением имеет.
Расскажите, с чем работали без проблем, будем посмотреть...

Лучше всего - непосредственно на API, безо всяких компонентов. Так будет быстрее и надежнее всего.
Протокол DCON несложный /когда делал имитатор для собственных целей, так, для удобства, уместил все запросы и ответы с описаниями нормальным читабельным шрифтом на страницу; если с учетом запросов для аналоговых блоков - будет на двух страничках/.

Беда не в протоколе, беда в том что направление приема/передачи в этих портах управляется сигналом RTS, если мне не изменяет память. А квант времени операционки 20 мс и когда программа эти 20 мс получит - предсказать можно только вероятностно и то если самостоятельно задавать приоритет процесса.

[Степа]

речь о встроенных портах промкомпьютеров и панельных ПК от Advantech

Встроенные я всегда запускал в режиме RS-232 через преобразователь: врожденная паранойя. На платах портов видно защитные оптроны, а на встроенных портах - нет. Да и выгорит защита на плате - поменял плату и всего делов /если не считать того, что причину выгорания надо будет найти/. А выгорит на встроенном порту /если, конечно, она там есть/ - уже все, картина Репина "Приплыли" /особенно, если порты используются все или в используемом ПО нельзя заменить используемый порт/. А если защиты нет, то ситуация становится еще хуже...

И по поводу квантов времени. Насколько мне память подсказывает, то поток с приоритетом выше нормального заметно больше времени получает. Т.е. загнать всю работу с портами в поток с наивысшим приоритетом /задание приоритета потоку вполне рядовая процедура, никакого шаманства не требуется/ и... Или поставить порт в режим RS-232 и пользоваться преобразователем, так даже проще будет, не надо будет заморачиваться с сигналом управления.

[Никита]

Встроенные я всегда запускал в режиме RS-232 через преобразователь

Ну так в этом-то и был вопрос. Кстати первый раз я с этой проблемой столкнулся на MIC-2000, там вроде как на одном из двух портов 232-го нет вообще, только 422 и 485, переключаются джамперами, на другом наобоорот - только 232.

На платах портов видно защитные оптроны, а на встроенных портах - нет

Еще одна причина не связываться со встроенными портами :)

Насколько мне память подсказывает, то поток с приоритетом выше нормального заметно больше времени получает. Т.е. загнать всю работу с портами в поток с наивысшим приоритетом /задание приоритета потоку вполне рядовая процедура, никакого шаманства не требуется/ и...

Не совсем так - времени получает по столько же, но чаще. Поэтому гарантировать что приложение получит, скажем, три кванта подряд - на отправить-подождать-принять, невозможно. Может будут, а может и нет, в общем мероприятие рискованное. А уж синхронизировать выделение времени операционкой с процессорами модулей вообще невозможно.
Плюс, большую часть этих выделенных квантов поток будет бездействовать, что быстродействие остального отнюдь не увеличивает. Еще момент - насколько можно задирать приоритет? В принципе, вспоминая Delphi - был эксперимент с приоритетами - задрать можно до такой степени что остальным не хватает времени, в т.ч. системным модулям для общения с мышью, отображения и свопинга, т.е. создается полное впечатление мертво висящей машины. В этом случае, думаю, с портом можно будет нормально работать, опять же без гарантии что в нужный момент не проскочит какой-то другой процесс, но тут другой вопрос - а зачем тогда это надо?
Да и опрос модулей в приложении это малая часть айсберга - есть же еще OPC-серверы, сторонние программы, да даже упомянутая родная утилита с этим портом работать не хочет. Драйвер нужно новый лепить для порта, а смысла в этом особого нет. MIC тот же изначально позиционируется как управляющий компьютер (читай контроллер), на котором винде делать нечего. А в ДОСе притормозить программу до получения данных проблем особых нет. Странно что такой же подход у адвантеха к панельным ПК, тут как раз картинки важнее но увы..