subj.

http://kb.mista.ru/

Точный адрес:
Работа с последовательным (COM, RS-232) портом из 1С:Предприятие 7.7 и 8.0

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

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

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

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

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

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

(5) Нет, пытается читать. Если там ничего нет, то всякий раз будет прочитано 0 символов.

(6) Я не знаю че там в штатной (говорят, она глючная, а исходника, чтобы посмотреть - нет).

Попробуй мою ВК, она действует аналогично (генерирует то же самое событие).

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

Я проверял свою компоненту так: брал большой текстовый файл и непрерывно посылал его в COM-порт. Добился, чтобы работало.

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

(9) угу.

(10) http://rsdn.ru/article/authors/HowNotTowrite.xml#EZA

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

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

(13) Спасибо, позже зазырю что у меня получилось. :-)

Со статьей я отчасти не согласен:

"русский прекрасно обойдется чем-то вроде "Это используется так-то и так-то". "

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

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

(15) Да, там буфер 64К кажется...
Отдельные куски тогда пропадут.

Вообще, протокол RS-232 не страдает излишней надежностью, и может, например, искажать данные.

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

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

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

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

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

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

(21) Спасибо.

А где стандарты оформления заценить? Я про них даже не слышал. Код вроде везде лесенкой, а что еще нужно?

Почему новичкам нельзя? Это для них писано.

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

Вот это что ли? Я думаю реально будет привести в соотв.
http://www.delphikingdom.com/asp/viewitem.asp?catalogid=802&mode=print

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

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

(23) Обычно используют стандарты Борланда, на русском чето похожее можно почитать тут: http://www.delphiplus.org/articles/delphi/source_code_standards/index.html
"Почему новичкам нельзя? Это для них писано." потому что написана криво и статья и компонента.

(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, кажись.

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

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

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

(27)>потому что написана криво и статья и компонента

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

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

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

(33) "Нормальные методы" - это приоритет потоку побольше поставить? На #$% я видел такие "нормальные методы" - они ведут к (6).

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

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

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

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

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

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

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

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

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

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

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

Мдя...

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

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

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

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

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

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

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

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


А когда чел выходит покурить на балкон он может прыгнуть с него. Все равно он из квартиры будет выходить :)

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

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

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

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

(56) А как ты думаешь, что я поюзал в (0)?

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

(51) MSComm не бесплатна.

Вечерком переделаю на поток - так будет интереснее.

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

Видео, я думаю, через COM-порт никто захватывать не будет.

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

О как .:)  Вот совсем недавно (в конце 2005 года) для автоматизации розничного магазина необходимо было реализовать механизм штрих кодирования.Так знакомые попросили. Для наименьшего гемороя все через типовую торговлю. Был сканерок пприкуплен com и принтер этикеток.   При работе в штатном режиме(scaopos) проц грузился на 100 процентов :). По какой причине ХЗ.Желания небыло разбираться.В протоколизации, в потоках . А может вобще дело было не в этом. :) Поменял на разрыв добавил пару строк кода в типовую и люди были счастлвы. Все работает . Причем ручками никто не тыкает. Все разошлись. :)

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

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

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

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

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

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