com-порт... :)

← →
Volodymyr (2003-06-18 20:14) [0]

трабл...

одна программа, две машины... работа с прибором через com-порт (вернее, два прибора)... программа работает только на прием данных... суть проблемы - на одной машине постоянно выбивает прием, процесс абсолютно случайный :(. единственное, что замечено - при повторной инициализации порта - установка только номера порта и включение (активация формы), все востанавливается... asyncpro 2.5, win98, D3...

отаке...

p.s. вопрос про 4 com-порта еше в силе :)

← →
-=Vlad=- (2003-06-24 17:52) [1]

AsyncProfessional конечно уважаемая в мире компонента, но все не без греха. При подобных глюках в первую очередь необходимо нарекать на вражеские компоненты. Посему попробуйте написать работу с компортом сами, не сложно, доки в нете навалом. Если леньки самим писать то попробуйте поставить AsyncPRO 3.x или лучше 4.x. Больше сказать не могу т.к. не совсем понимаю чо означает "выбивает прием", подробней плиз.
Удачи.
З.Ы. О вкусах не спорят, но пора переходить на D повыше :-)

← →
Volodymyr (2003-06-24 18:52) [2]

спасибо за ответ...

"выбивает прием" - идет постоянная передача текущих координат 10-байтовыми посылками ~ 1 посылка в 1мс (так реализовано внутри микроконтроллера в приборе). при приеме только пересчитываются координаты и индицируются на "индикатор"... все остальное - простая математика... "выбивание приема" - внешне прекращается смена индикации... никаких событий при этом не инициализируется (повесил обработчики на все что есть)... единственное, более определенное - обнуляется номер порта, жестко установленный как com1, внутри программы никаких изменений параметров установки нет!

проверено на остальных компоненетах и своем приеме :) - фигня та же...

p.s. а D3 - ну нравится он мне :)

← →
-=Vlad=- (2003-06-25 14:18) [3]

Сразу куча вопросов. По порядку.
1. Ваш приборщик передает данные через RS-232 интерфейс? Если да какая то у него странная скорость.
2. Как вы настраиваете свой порт, т.е. BaudRate, ByteSize и т.п.
3. У приборчика есть протокол обмена данными, или он просто прет данные по порту.

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

← →
Vovchik (2003-06-26 16:45) [4]

Кажется отвечать вопросом на вопрос не очень красиво :-)
Прошу прощения.
Но я столкнуля с одной проблемой.
Дали такое задание (кажется аналогичное с Вашим) есть контрольный прибор к которому подключается модем. Мне необходимо написать программу которая будет подключатся к этому модему и считывать с него буквально 20 цифирок. В чём беда никогда таким не занимался. Посоветовали использвовать компоненты Async Pro (очень много о них слышал, но работающую версию так и не нашёл). Если не тяжело намыльте ссыоочку где их взять. Пишу на D5. Может ещё поделитесь какимито советами. Спасибо

← →
-=Vlad=- (2003-06-27 10:34) [5]

Всех кого интерисует работа с портами просто необходимо пойти сюда http://delphi.vitpc.com/mastering/ports1.htm

← →
Volodymyr (2003-07-01 20:56) [6]

сорри за задержку... действительно, про аппаратный буфер я и не подумал, спасибо.
по остальным:
RS-232, 115200, 8 данных, 1 стоповый, без проверки четности...
соответствие по параметрам полное... за протоколом ловится стартовый байт, после него отсчитываются 9 байт данных... любой "внеочередной" стартовый байт сбрасывает прием в начало...

← →
Германн (2003-07-02 05:14) [7]

Ну вот все было просто и понятно (кроме сабжа, есс-но), Но тут появилась фраза - любой "внеочередной" стартовый байт сбрасывает прием в начало. И сразу вопросы:
1. А что такое "стартовый байт"?
2. А что такое "внеочередной стартовый байт"?
3. Как вышеупомянутый "ловится" и как "после него отсчитываются"?

← →
Nucl (2003-07-02 09:19) [8]

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

← →
-=Vlad=- (2003-07-02 11:17) [9]

Полностью согласен с Nucl, пишите данные в файл и анализируйте их обработку вашей программой. Если данные не соответсвуют протоколу, то проблема с настойками порта, иначе проблема в коде обработчиков. Если первое то - я так понимаю, что он (прибор) построен на основе какого то микроконтролера, не поленитесь найдите доку по этому микроконтролеру и почитайте по его последовательный порт. У меня на практике был прибор на сименсе уже не помню номиналы, долго я сним мучался пока не выловил что скорость у него не 14400 как было сказано в паспорте а 10000, да именно 10000 и и я ставил BaudRate:=10000; Кстати кто сможет мне тупому объяснить как такое может работать???? Я так понимаю что в юартовском контролере стоит делитель частоты, и программируя скорость порта мы программируем число в этом делителе (Порты я программировал на и на асме, посему представляю что из себя представляет порт).
Если второе то - если не помогает подъем/опуск RTS то ошибка скорее всего в обработке, ищи там. Отладка программ самое приятное в работе программиста ;-)))
Удачи

← →
Alex M.A. (2003-07-02 16:54) [10]

Если я правильно понял, имеет место быть логическая синхронизация потока данных... т.е. стартовый байт посылки... проблемы
1. при такой организации, данные обычно передают в hex-формате ascii-символами, а старт-символ выбирается не из диапазона [0..9,A..F] (например, "$"), чтобы заведомо исключить вероятность появления старт-символа в теле посылки
2. при такой высокой скорости обмена, просто необходимо формировать и проверять контрольную сумму посылки... в противном случае, могут быть проблемы с обработкой полученных данных, при возникновении помех на линии... а они, при таких скоростях, не редкость...
3. при высоких скоростях обмена, работу с портом все-таки лучше вынести в отдельный поток... личное мнение...
4. при инициализации порта, буфер приемника лучше сделать потолще...

P.S. компонентами работы с портами не использую... видел, пробовал, но... имхо, проблем больше, чем результата... ручками, ручками...

← →
Volodymyr (2003-07-02 17:57) [11]

вах!
что на контроллер AT90S8515, что на машину писал я. физически и по параметрам передачи интерфейс відержан. сигнал красивый - сам на осцилограф писал. эт я просто так :).

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

всем спасибо!

← →
Tano (2003-07-02 17:57) [12]

Я постараюсь пофантазоровать...
Может быть в момент появления внеочередного стартового байта (это я понял, только тебе нужно быть уверенным, что никакие теоретически допустимые данные с ним не совпадают) у тебя возникает рекурсивный вызов или в подпрограмме - обработчике, где проверяется стартовый возникает рекурсия. Короче, непредсказуемость принятых данных порождает переполнение стека.
Я писал извраты на нестандартной частоте (правда без сторонних компонент, только API), все жестко работает, если корректен алгоритм.

2 -=Vlad=- (02.07.03 11:17)
В контроллер загоняется делитель частоты, равный (115200 div 10000) - это для стандартного RS-232. Вследствии того, что импульсы имеют некоторую длительность и пакеты разделены стопами, приемник и передатчик могут понять друг друга, если только накопленное за 8(6,7)бит отклонение не превысит 70%/кажись/ бита.

← →
Tano (2003-07-02 18:03) [13]

Я опоздал на несколько секунд.....

Пересядь на D6+sp2 и жить станет горрррраздо легче! (совет)

← →
ksa2002 (2003-07-03 05:54) [14]

НАрод сам писал обрботчик для com порта ,если есть проблемы могу помочь :)

com-порт... :) Найти похожие ветки