VISA Bytes at Serial Port не выполняет своих функций

[AlexOskar]

Проблема в том, что инструмент VISA Bytes at Serial Port не видит количество байтов в этом самом порту! При подключении к VISA Read подает на неё 0. Хотя при этом информация в порте есть и при замене инструмента VISA Bytes at Serial Port на константу она считывается как надо. В чем может быть причина такой проблемы? Использовать константу не получится из-за особенностей ВИ.

[Kosist]

При подаче константы VISA будет ждать нужное количество байтов на протяжении некоторого времени (таймаута). Поэтому не факт, что у Вас моментально на момент чтения находятся в буффере байты - может там сначала ничего нет, а через пару миллисекунд уже есть данные. И если в буффере ничего нет, функция VISA Bytes at Serial Port выдает ноль, и функция VISA Read ничего уже не ждет.
Меня функция VISA Bytes at Serial Port не подводила, честно говоря...
А проверить просто - читайте при помощи константы, и считывайте при помощи VISA Bytes at Serial Port количество байтов (перед чтением) на индикатор. Должны увидеть количество байтов, которое возвращает VISA Bytes at Serial Port.

[Borjomy_1]

Потому что VISA Read ожидает поступления заданного количества байт. А Bytes At Port - показывает текущее состояние. Вывод - на момент вызова функции в буфере нет данных.
Попробуйте в Панели управления/система и т.д в настройках порта установить размер FIFO = 1 (это уменьшит задержки на доставку байта из порта в буфер, но никак не гарантирует, что программа будет всегда правильно работать).
Но вообще это принципиально неправильно использовать Bytes At Port.

Использовать константу не получится из-за особенностей ВИ.

Почему? Правильно написанный протокол обмена дает возможность так или иначе определить размер посылки.

[dadreamer]

AlexOskar, таймаут операций чтения/записи делаете скажем 50-100 мс и анализируете кластер error out после VISA Read. Таким образом можно избежать использования VISA Bytes At Serial Port. Это в простом случае, когда не хотите заморачиваться с протоколом. Но лучше сделать так, как сказал Borjomy_1.

[Vitekkz88]

Borjomy_1 писал(а):Но вообще это принципиально неправильно использовать Bytes At Port.

Borjomy_1, почему? Что неправильного то?
Задача вычитки заранее неизвестного количества байт достаточно распространенная. Конкатенация принятых байт до некоторого размера и парсинг - это более профессиональный подход, нежели на каждую отдельную команду хардкодить определенный размер данных для чтения.
Пример: прибор самостоятельно отправляет служебную информацию в порт. Возможно такое? Легко! Всё, сели в калошу с константами.
Практика показывает, что размеры длин пакетов меняются несколько раз в процессе разработки. Далее, гораздо проще однажды определить заголовок пакета и позицию байта с длинной, чтоб потом его использовать везде. В крайнем случае, в коде надо будет поправить позицию байта длинны для корректного парсинга и всё. Если протокол сторонний(например от прибора информацию вычитываем), то тем более следует постоянно слушать порт и выгребать всё, что приходит, а затем анализировать. Исключение: прибор отправляет мусор в порт, а на запрос отвечает валидными данными. Отправил валидные данные и дальше мусор шпарит.
А хардкодить размер вычитываемых данных - это для попсовых и "тепличных" задач. Шаг влево, шаг вправо - программа не работает, нужны правки.

[Borjomy_1]

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

Когда прибор отправляет мусор в порт, сам прибор надо отправлять в мусор. А программисту, который написало ПО для него, руки выдергивать.

Если протокол сторонний(например от прибора информацию вычитываем), то тем более следует постоянно слушать порт и выгребать всё, что приходит, а затем анализировать.

Надо внимательно читать описание протокола. ИМХО в 100% случаев порт слушать через Bytes At Port БЕЗГРАМОТНО. Если так хочется анализировать внавал, читайте по 1 байту.

По поводу картинки. А вы в курсе, что обновление информации для Bytes At Port может происходить с интервалом до 50 мс? Не, не знали? А то, что посылка 1 байта занимает меньше 100мкс, т.е задержка в 10мс означает, что ловить 1 байт и 100 будете одинаковое время? И получите фатальное ограничение групповой скорости обмена.

[Vitekkz88]

Borjomy_1 писал(а):Надо внимательно читать описание протокола. ИМХО в 100% случаев порт слушать через Bytes At Port БЕЗГРАМОТНО. Если так хочется анализировать внавал, читайте по 1 байту. По поводу картинки. А вы в курсе, что обновление информации для Bytes At Port может происходить с интервалом до 50 мс? Не, не знали? А то, что посылка 1 байта занимает меньше 100мкс, т.е задержка в 10мс означает, что ловить 1 байт и 100 будете одинаковое время? И получите фатальное ограничение групповой скорости обмена.

Зря вы так. Данные копятся в буфере порта. Читать данные нужно пачками, а не по одному байту. Либо копить данные в течении N мс и выдавать на обработку. А не обрабатывать каждый приходящий пакет.

[Borjomy_1]

Зря вы так. Данные копятся в буфере порта. Читать данные нужно пачками, а не по одному байту. Либо копить данные в течении N мс и выдавать на обработку. А не обрабатывать каждый приходящий пакет.

В таком случае непонятно, что мешает вычитывать из буфера четко по 100 байт например. Частота выдачи известна пакетов(надеюсь). В вашем внутреннем буфере все равно поток склеенный. Вы и так и так не синхронизируетесь с прибором по посылам.

[Vitekkz88]

Borjomy_1 писал(а):В таком случае непонятно, что мешает вычитывать из буфера четко по 100 байт например. Частота выдачи известна пакетов(надеюсь). В вашем внутреннем буфере все равно поток склеенный. Вы и так и так не синхронизируетесь с прибором по посылам.

Таймаут, обработка ошибок, бесконечное ожидание 100 байт, которые могут не набраться.
Вы от меня что хотите то?
Я задал простой вопрос: "почему неправильно использовать Bytes At Port?"
Ответ: иногда это приводит к простою цикла вычитывания данных. Всё. Тут важен баланс.
Тем не менее, это не является какой-то принципиальной неправильностью. Повторяюсь, задача: подключиться к прибору и вычитывать всё, что от него приходит.
Решение: использование Bytes At Port с последующей конкатенацией полученных байт. Вы терминалом для COM-порта когда-нибудь пользовались? Там никто не требует указания количества ожидаемых байт на порте. Предполагаю, что там механизм взаимодействия построен на опросе буфера порта через определенную задержку(каждые N мс). И данные валят по мере поступления.
Меня устраивает баланс между регулировкой времени опроса порта и накоплением данных.

[dadreamer]

Это же всё неоднократно обсуждалось. Зачем опять делать то же самое.
http://labviewportal.org/viewtopic.php?p=65830#p65830
http://labviewportal.org/viewtopic.php?p=65865#p65865

[Vitekkz88]

dadreamer, можно в двух словах? Там читать не перечитать.
Почему Bytes At Port использовать - лажа? А то у меня работает и всё хорошо, а оказывается я фигню напрограммировал...У меня от железки идёт поток данных, boudrate 115200(и выше). Цель: получать все сообщения, парсить, отображать. Мои простои в N мс. до фонаря. Главное чтоб вычитывал и выводил на экран более-менее быстро.
Второй вопрос: каким образом работают терминалы? Я предположил, что так же с опросом буфера по некоторому таймауту. Возможно побайтно конечно же, но сомнения меня терзают.

[dadreamer]

1. Лажа, не лажа, а это дополнительная операция, занимающая определённое время. Можно обойтись без этой операции. Кроме того, VISA Read итак организует внутри себя цикл побайтового чтения и склейки данных: http://labviewportal.org/viewtopic.php?p=65914#p65914 Потому совершенно нерационально сооружать поверх VISA Read второй цикл чтения и склейки, также отнимающий определённое время программы. Самый опциональный подход - однократное чтение данных из порта посредством VISA Read при правильно сконфигурированных параметрах порта (терминатор, таймаут и прочее). Borjomy_1 описал порядок действий при приёме данных, имеющих заранее известный формат, и бинарных (сырых) данных. В том случае, когда терминатор по каким-то причинам не может быть использован совсем, используется VISA Read с максимальным количеством байт, которое способен вместить порт (4096 по дефолту). Таким образом, все данные будут извлечены из порта, а кластер ошибки скажет, есть ли ещё данные в порту или нет.
2. Каждый терминал работает так, как его написал разработчик. Поэтому нужно разбирать работу в каждом конкретном случае. Может и так, как вы пишете. Может работать по WinAPI'шным событиям. Может и тупо по 1 байту читать. Если так интересно, берёте логгер/сниффер WinAPI и смотрите, что вызывается.

[Vitekkz88]

dadreamer, Хорошо, с этим разобрались. Но в этом случае получается, что вызывать функцию VISA Read придётся чаще.
Первым запросом читаем длину, вторым запросом читаем сообщение(как в TCP/IP-шном примере). Либо просто вызываем VISA Read, ждем N байт в течении N мс и завершаем работу по таймауту либо по терминатору(которого может и не быть). Но опять же таймаут есть и обработка ошибки. Зато вызвали функцию один раз. Не замерял я быстродействие вызова Bytes At Port, но сдаётся мне что этот вызов не приведёт к катастрофе временного исполнения программы в целом.

[Borjomy_1]

Не замерял я быстродействие вызова Bytes At Port, но сдаётся мне что этот вызов не приведёт к катастрофе временного исполнения программы в целом.

Сам вызов ничего не стоит с точки зрения быстродействия. Но во-первых вы путаете частное с общим, во вторых при приеме данных в буфер значения о количестве байт обновляются не в реальном времени. Эти задержки нелимитированы, тем более, что минимальный дискрет опроса, который вы можете задать в цикле (1мс) в десять раз больше времени передачи 1 байта. Для более высоких скоростей разница еще больше. И тут мы попадаем в зону нечувствительности: либо 0, либо 10 (при непрерывном потоке). Если посылка некратна интервалу опроса, то получается задержка не менее одного цикла. Ваш метод годится для мизерного количества ситуаций и тем более неприемлем для диалогового обмена. Вызов функции VISA Read если в буфере есть данные - ничего не стоит. Повторюсь, что исследования показали, что размер буфера FIFO критически влияет на латентность функции к приему данных. Опять же, если мы даем советы, то начинать надо с фундаментальных вещей, а не "хакерства". Фундаментальная вещь в данном случае состоит в том, что принимающая сторона должна вычитывать посылку целиком, в соответствии со спецификацией. И если вы знаете формат посылки, то работать по таймауту также неправильно. Лично я ВСЕГДА использовал таймаут исключительно для определения: подключен прибор или нет.

[Vitekkz88]

Вызов функции VISA Read если в буфере есть данные - ничего не стоит.

А если их нет в буфере? Посылка не кратна интервалу опроса, ага. Прочитаю с задержкой в N мс.

Ваш метод годится для мизерного количества ситуаций и тем более неприемлем для диалогового обмена.

Этот метод особо не отличается от вашего, типа true-шного метода
Ответ: иногда это приводит к простою цикла вычитывания данных.Больше ничем не отличается.

Фундаментальная вещь в данном случае состоит в том, что принимающая сторона должна вычитывать посылку целиком, в соответствии со спецификацией.

Терминалы и тестовые программы по вашей логике тогда являются "хакерством", да? Ведь они(терминалы и тестовые программы) не руководствуются спецификацией, а просто сливают данные с порта и всё.