Работа с последовательным портом RS-232 из 1С (зацените мою статью) #154118

subj. Точный адрес:

респект. Статья очень понравилась.

Мне до такого ещё расти и расти:(.

Апну разок (тут кто-то спрашивал код ВК).

Респект - так вроде говорится ?

Тока вот не очень понял - читает с "файла" каждые 500 мили секунд по строке ? Т.е. файл буферизирует то, что идет в COM порт ? Если в порт будет чаще писаться  -скажем каждые 200 мили секунд, то что будет ?

Может объяснишь мне когда я подрубаю сканер к COM порту и инициализирую штатную scanopos то проц у меня на 100 процентов :)

Нет, пытается читать. Если там ничего нет, то всякий раз будет прочитано 0 символов. Я не знаю че там в штатной (говорят, она глючная, а исходника, чтобы посмотреть - нет). Попробуй мою ВК, она действует аналогично (генерирует то же самое событие).

>Если в порт будет чаще писаться  -скажем каждые 200 мили секунд, то что будет ? Система Windows буферизует файловый ввод-вывод. Я проверял свою компоненту так: брал большой текстовый файл и непрерывно посылал его в COM-порт. Добился, чтобы работало.

стилистику критиковать можно?

угу.

И что именно нарушено?

"Интересно наблюдать, как автор, начавший писать от третьего лица ("Автор считает"), ко второй странице съезжает на "Мы будем использовать", а через еще пару абзацев, окончательно отчаявшись, говорит: "возьмите вот это и вызовите вон то".

Спасибо, позже зазырю что у меня получилось. :-) Со статьей я отчасти не согласен: "русский прекрасно обойдется чем-то вроде "Это используется так-то и так-то". " Пассивные глаголы же запрещены? (С.Кинг). А вот модальные глаголы (повелительное наклонение) вполне, я думаю, рулят в техническом описании.

Но если читать реже чам писать в порт, то какая то часть данных будет пропадать при переполнении буфера ?

Да, там буфер 64К кажется... Отдельные куски тогда пропадут. Вообще, протокол RS-232 не страдает излишней надежностью, и может, например, искажать данные.

(+16) Искажает данные больших пакетов (рано или поздно сбивается синхронизация). Поэтому программист должен разбивать на пакеты разумной длины, и снабжать их контрольной суммой для проверки целостности.

Это я все эхолот думаю прикрутить. Так то с чтением проблем не возникло. Но если на природе подрубать - надо либо ноут армейский , либо... Это у меня идея вертится писать маршруты шлубин и потом рельеф 3D рисовать

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

У меня сбивалась, когда я посылал длинный текст. После N килобайт нормального текста шли символы с нарушенной кодировкой. Причем это было так стабильно.

про многопоточность - фигня какая-то написана. Ибо: 1) таймер к многопоточности никакогоотношения не имеет 2) в данном случае мьютексы вообще не в тему, так как предназначены для синхронизации межпроцессного взаимодействия. Оформление кода не соответствует стандартам, мягко говоря. Ошибка: в Init создается cp:= T_ComPort.Create; в Done cp не разрушается, налицо утечка. В целом - молодец, но учиться на этой компоненте новичкам - не советую.

Не из-за сбоя синхро. Когда происходит сбой синхро, винда возвращает соответствующую ошибку. Ошибка буферирования или где-то ещё.

Спасибо. А где стандарты оформления заценить? Я про них даже не слышал. Код вроде везде лесенкой, а что еще нужно? Почему новичкам нельзя? Это для них писано. Таймер для многопопточности имеет отношение!!! Ведь обработчик таймера - крутится в отдельном потоке, не так ли? У меня был сбой на длинных текстах (терялись куски текста), когда таймер уже сработал, а текст из порта еще не прочитался. Подозреваю, что там возник второй поток, и они параллельно начали выполняться.

Вот это что ли? Я думаю реально будет привести в соотв.

Ничего себе ошибка буферирования - буквы в абракадабру превращаются. :-) Причем стабильно.

Значит, накосячил где-то :))) При правильной настройке ком-порта ошибки синхронизации не возникают, если нет сбоев аппаратной части. Конечно, если не передавать мегабайты нулей или единиц, как я и писал.

Обычно используют стандарты Борланда, на русском чето похожее можно почитать тут: "Почему новичкам нельзя? Это для них писано." потому что написана криво и статья и компонента.

(27+) TTimer - просто обертка вокруг SetTimer/KillTimer и WM_TIMER. Выполняется в том же потоке. Кроме того: The WM_TIMER message is a low-priority message. The GetMessage and PeekMessage functions post this message only when no other higher-priority messages are in the thread's message queue. Запросто можешь терять данные из порта, WM_TIMER имеет приоритет как у WM_PAINT, кажись.

А глобальный хук будет отслеживать эти события ?

+ не WM_TIMER конечно, а изменения в файле...

Я же не буду сканером 64 килобайта в порт писать? А это значит, что ЛЮБЫЕ штрихкоды будут прочитаны, даже при низком приоритете потока WM_TIMER, даже если комп будет длительное время загружен!!!

>потому что написана криво и статья и компонента А ты сам не криво щас пишешь? Предлагаю на 100 баксов поспорить, что при 100% загруженности 1С в течение N минут штрихкод будет все равно получен, когда 1С освободится (возникнет Idle Time).

мне пох. Не реагируй столь бурно. Рекомендую все же почитать о нормальных методах работы с СОМ-портами, а не изобретать велосипед.

В буфер-то Windows читает с максимальным приоритетом (более того - через аппаратное прерывание)! А из буфера я могу забирать данные как угодно редко.

"Нормальные методы" - это приоритет потоку побольше поставить? На #$% я видел такие "нормальные методы" - они ведут к . Поток и таймер в данном случае одно#$%ственны. В случае потока - приоритет надо ему выставить минимальный, и обязательно делать sleep между чтениями. 500 - для примера, возможно другое значение слипа.

"Поток и таймер в данном случае одно#$%ственны" - в сад. Ты и в 1С пишешь по принципу: "у нас в документе не может быть больше десяти строчек, если будет - напишем другой модуль"? Переименуй тогда свою тему: "Работа с последовательным портом RS-232 из 1С (зацените мою статью) ТОЛЬКО ДЛЯ СКАНЕРА ШТРИХ-КОДА, В ДРУГИХ СЛУЧАЯХ БУДЕТ ГЛЮЧИТЬ"

Извини, но ты щас туфту городишь. Если я и сделаю потоком, как ты говоришь, то обязательно - с теми же паузами (sleep) по 500 мс, и с минимальным приоритетом. А иначе подстава. Непрерывное чтение RS-232, да еще и с высоким приоритетом, ДЕЛАЮТ ТОЛЬКО ДЯТЛЫ (я это официально утверждаю и готов поспорить на бабки, что все будет работать, если конечно поток данных разумный для данного протокола, и не переполняет буфер 64К).

Уважаемые. Если просто сканер то ставьте в разрыв. Дешево и сердито. В противногм случае многопоточность и степпинги с таймингами Вас затопчут :)

Дятлы клювом задолбят. Он у них железный. :-)

Сканер в разрыв - это зло, потому что пользователь будет всякий раз обращаться к клавиатуре, и нажимать лишнюю клавишу перед считыванием ш/к. Это очень неудобно и в разы замедляет работу оператора, например, на складе.

А зачем ему обращаться к клавиатуре ? У меня курсор в поле ввода сам заново позиционируется после считывания . :)

ты выясни наконец-то что такое таймер, а то, извини, туфту несешь. "приоритет потоку побольше поставить", "Непрерывное чтение RS-232, да еще и с высоким приоритетом" - это ты изобрел сам, я такого не говорил.

С каких пор аппаратный интерфейс называется протоколом? И как он самый (т. е. интерфейс) может искажать данные?

А если кабель пяток метров использовать  - наводки будут данные искажать ?

>>Сканер в разрыв - это зло, потому что пользователь будет всякий раз обращаться к клавиатуре, и нажимать лишнюю клавишу перед считыванием ш/к. Мдя...

Сорри я был не прав. Да, интерфейс. У меня искажал на больших объемах. Причем, стабильно. Как-не знаю.

Если на RS232 повесить преобразователь в RS485 то и на 2 км. наводок не будет. А комп будет видеть все тот-же неискажающий данные RS232.

Все равно события в 1С имеют минимальный приоритет - Idle. А я ориентируюсь именно на события 1С. Простое чтение из файла можно организовать намного проще.

+47. А вот горбатый протокол обработки данных сможет их исказить до неузнаваемости.

(41, 45) Оператору по любому много лишних нажатий. Особенно прикол, когда поправила строку документа, и еще раз считала. Угадай, что при этом будет. Правильно, звонок программисту "У меня не работает ваша 1С".

Чем видоузный MSComm не устраивает? Оберни в оберточку пригодную для 1С и получишь полностью событийно управляемые возможности.

Событие он не умеет 1С-ное генерировать. Вообще можно читать и писать "COM2" например как обычный файл.

(41, 45) Оператору по любому много лишних нажатий. Особенно прикол, когда поправила строку документа, и еще раз считала. Угадай, что при этом будет. Правильно, звонок программисту "У меня не работает ваша 1С". А когда чел выходит покурить на балкон он может прыгнуть с него. Все равно он из квартиры будет выходить :)

Предлагаю автора отправить в глубокий космос.

Зуб перестал болеть?

Кто он? А ты зачем. Юзай создание внешних компонент.

Я не понимаю чем тебя не устраивает COM-сканер? Он НАМНОГО удобнее для оператора. А если кто-то не умеет с ними работать, то он ДЯТЕЛ С БОЛЬШИМ КЛЮВОМ. А как ты думаешь, что я поюзал в ?

он=mscomm В данном случае он не нужен - достаточно простого чтения из файла или записи в файл, т.к. в Windows COM-порт - это файл.

MSComm не бесплатна.

Вечерком переделаю на поток - так будет интереснее. Через таймер, как сейчас, тоже будет работать на не переполняющих буфер 64К потоках данных. Видео, я думаю, через COM-порт никто захватывать не будет.

53) Я не понимаю чем тебя не устраивает COM-сканер? Он НАМНОГО удобнее для оператора. А если кто-то не умеет с ними работать, то он ДЯТЕЛ С БОЛЬШИМ КЛЮВОМ. О как .:)  Вот совсем недавно (в конце 2005 года) для автоматизации розничного магазина необходимо было реализовать механизм штрих кодирования.Так знакомые попросили. Для наименьшего гемороя все через типовую торговлю. Был сканерок пприкуплен com и принтер этикеток.   При работе в штатном режиме(scaopos) проц грузился на 100 процентов :). По какой причине ХЗ.Желания небыло разбираться.В протоколизации, в потоках . А может вобще дело было не в этом. :) Поменял на разрыв добавил пару строк кода в типовую и люди были счастлвы. Все работает . Причем ручками никто не тыкает. Все разошлись. :)

Я поддерживаю romix-a, что сканер в разрыв это чепуха. А для нормальной работы не надо было использовать 1С-ский scanopos. Уже давно известно, что это глючная байда.

Да.Когда дойдет до перепайки контактов.Свистните. :)

Ты сейчас с кем разговариваешь?

Это у вас что . Часы. А за спиной что. Батарейки.

Во-во, тут ты прав. Для организации работы сканера в 1С не надо разбираться в протоколах и потоках. :)

Вроде замена для scanopos.dll в инете давно лежит? (специально для тех кто не умеет программировать).