Форум » Clipper » Com_read ? » Ответить

Com_read ?

Dima: Имеются электроные весы с возможностью связи с компом по COM порту. Родная скорость обмена 14400 Посылаю в порт нужную команду , в ответ теоретически должен получить 9 байт. Пример в 16 виде 00 00 00 00 00 00 00 77 0D Получив 00 00 77 и преобазовав его в DEC/100 получаю вес 1.19 кг Где OD признак конца передачи. В 8 ,7 ,6 байтах лежит сам вес. Иногда в эти 9 байт попадает не понятно откуда взявшийся мусор. Например мы ждем 00 00 00 00 00 00 00 77 0D а реально получаем 00 00 00 00 АА 00 FF 00 FF FF FF FF 00 77 0D Как с этим бороться ? Считываю так com_read(cport,com_count(cport)) , где cport номер COM порта + дальнейшая обработка на символ конца и тд Как от хлама избавиться , потому как изредка, но бывает что программа считывает не верный вес ?

Ответов - 19

Dima: Может есть какая то другая библиотека для Clipper по работе с портами ?

kia: Dima пишет: Как от хлама избавиться , потому как изредка, но бывает что программа считывает не верный вес ? А не шлют ли весы вместе с весом и статус (вес стабилен/не стабилен)? Если нет такой возможности можно самому смоделировать такой статус например пока три подряд считанных значения веса не будут равны. У меня стабильность веса проверяется по статусу с весов, функции работы с портом - тулсовские, пробовал еще IOLIB.

p519446: У меня обмен идёт не с весами, а с терминалом для считывания бонусных карт по протоколу UNIPOS. Так вот: когда я принимаю от терминала любое сообщение, то в конце идёт контрольный байт, по которому можно проверить, что строка передана именно та, которую я получил. У тебя, как я понял, контрольный байт "от весов" не передается. Но ты сказал, что вес содержится в байтах 6,7 и 8 (самый левый байт имеет номер = 1). Что тогда должно быть в других байтах ? Если ТОЛЬКО нули, то мусор с большой вероятностью можно отсечь именно этим правилом (т.к. он, скорее всего, не будет "выбирать", в какие байты ему записаться). Понятно, что это не решение проблемы, но другого в голове пока нет.


Dima: p519446 пишет: когда я принимаю от терминала любое сообщение, то в конце идёт контрольный байт, Виноват , не правильно я описал , контрольная сумма там есть (склероз) Кстати фирменная прога из 5 снятий только 2 раза снимает вес а 3 раза пишет что ошибка снятия. kia пишет: например пока три подряд считанных значения веса не будут равны. А это идея :) Вообщем пока временно увеличили задержку с 200 мс до 210........

kia: Dima пишет: Вообщем пока временно увеличили задержку с 200 мс до 210........ Проверку стабильности веса все равно делать желательно т.к. всегда есть внешние воздействия на весы (прошел рядом человек/машина/паровоз...) и записался ошибочный вес

p519446: Имхо, можно просто игнорировать любое сообщение от весов, если контрольный байт не совпадает с вычисленным. И не менять задержку (мусор туда всё равно попадать будет). BTW, а там кабель от весов до компа какой длины ? Может, он чересчур длинноват ? ;)

Dima: p519446 пишет: а там кабель от весов до компа какой длины ? да не кабель нормальный ;) метр с лишним не больше.... Всем спасибо , буду думать !!!

Vlad04: Я для работы с платформенными весами я использовал библиотеки Tools для Сlipper5.1 Стабилизацию проверял просто - сравнивал значение получаемое из порта, через какой-то промежуток времени и если оно не менялось то это и есть вес.

Dima: Еще вопросик. Обнаружил что если открыть порт и что то в него пихануть а затем его закрыть Com_close , то на самом деле порт не закрывается и закрывается только тогда когда полностью выходим из программы. Во как Для этого теста использовал PortMon от sysinternals.com В приниципе это вроде ни как не влияет на работу программы но тем не менее не порядок. Как решить ?

suv: а что ты понимаешь под "закрыть порт"? и что значит "он не закрывается"? тулсовые ком-функции у меня тоже иногда врали на фискальном регистраторе) ИНОГДА возможно, они просто глючные ЗЫ. Дима! У меня вроде раньше на нике suv2 был пароль ************* Теперь не пускает!

Dima: suv пишет: а что ты понимаешь под "закрыть порт"? и что значит "он не закрывается"? Грю же чекал этой прогой PortMon от sysinternals.com , там все видно ;) А проверялась моя прога на Clipper и фирменная под Windows для этих весов , так вот она сняла вес и порт закрыла , у меня фиг ;) Все видно по монитору PortMon. PS Ник suv2 поправил ;)

suv: как поправил? где поправил? с каким паролем мне заходить? что тебе от того, что там кто-то что-то показывает? байты продолжают поступать, если ты порт закрыл? и зачем вообще его закрывать - ну совершенно непонятно

Dima: suv Заходи с suv2

p519446: У меня порт также НЕ закрывается до тех пор, пока прогу полностью не завершить. И не "иногда", а ВСЕГДА. И когда кассиры в конце дня хотят запустить какую-то еще "штатную" хрень для обмена через ТОТ ЖЕ com-порт с тем же устройством (терминалом считывания магнитно-чиповых карт), то эта штатная прога НЕ может открыть ком-порт. Может, это не клипперная ф-ция врёт, а виндусовая ДОС-машина (vdm.exe) такая "умная" ? Я в ней еще и не такую странность знаю (когда открытые файлы можно "отложенно грохнуть" в другом окошке -- SUV не даст соврать, тоже натыкался на это...)

PRG_MAN: Народ, а не подкинете любезно примерную структуру проги, которая опрашивает счётную машинку банкнот, а то я сам никогда не пользовался ф-ями COM_*. Ведь кроме открыть-считать-закрыть надо ещё видимо проверять готвоность машинки, начало и конец передачи и т.п.? Заранее благодарен.

Dima: PRG_MAN Для этого нужно иметь протокол обмена этой счетной машинки.

PRG_MAN: Протокол узнаю. Только принципиально это что-то изменит? Не хочется изобретать велосипед

Dima: PRG_MAN пишет: Только принципиально это что-то изменит? Нужно смотреть на протокол обмена. я связывал кассовые аппараты , весы и еще всякое железо и везде были разные подходы в зависимости от протокола обмена.

PRG_MAN: Хорошо.Тогда конкретнее пообщаемся попозже, когда принесут машинку.



полная версия страницы