LabVIEW Portal

Select, Kosist справедливо замечает: "а что Вы сейчас собственно пытаетесь достичь?" Им и мной было выдано достаточно примеров как организовать раздачу получаемых данных по индикаторам и как организовать приём данных. Что там у вас не сростается не понятно. Неужели из примеров трудно выхватить суть и применить для себя.

Повторяюсь, во все строки в отключенном в Termination значения считываются с поканальной разбивкой и это нормально !но 1 раз в момент запуска, далее это уже история результата при запуске и при отображений параметра значения при его аппаратном изменении не происходит.
Леды моргают, но это всего лишь их отработка времени итераций а не как результат считывания обновленных данных
При включенном Termination, индикации отображается только канал один активный канал и так же его история.
Для наглядности аппаратно переставил сенсор на 2 канал (см. последний screen).
Если хотите, я сделаю видеоролик.

Select, сделайте ролик, потому как сейчас непонятно, что не работает. Может Вам прибор просто не шлет данные? Тогда это проблемы прибора, а не парсинга...

Всё же не понимаю, что происходит. Начнём сначала. Запусти вариант ABC (4).vi, пусть запишутся 4-5 полных пакета (4-5 по 10 каналов). Скорее всего это будет не 3-4 элемента массива, а больше. Запомни их в индикаторе, сделай Save программы и выложи её сюда. Запомнить в индикаторе это значить сделать их по умолчанию, т.е. правой клавишей мыши по индикатору Data Operations/Make Current Value Default.

В моём посте "Вчера, 21:33" левый Snippet. Выкладываю то, что должно быть.

Все проблемы в игноре терминал символа. Смотри пример

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

Юрий,
Сделал, время цикла установил в 500 ms, в соответствии с рекомендациями datasheet на железо.
------------
И еще, мне не совсем понятна здесь логика.
Весь код должен непрерывно в цикле выполнять чтение и очистку буфера, в варианте АВС(4) происходит считывание только в момент первого обращения, далее просто ждет останова. Аппаратное изменение параметров во время работы не отображается в индикации что-то я не вкурю такую логику. На выставленных здесь видеороликах в своем первичном коде это продемонстрировано.
Здесь последнем АВС(4) я подключил на 0 и 4 каналы сенсоры с одинаковым толерансом.

-----------
Kosist,
Данные с боарда приходят 1 раз без потерь (172 byts a port ) Termination (OF).
Когда его включаю в индикаторах 1 строка, при этом буфер с каждым циклом растет, при этом во всех индикаторах отображается только значения 0 канала и так же выдается значение только то, которое пришло при запуске.

Select, Очистка буфера UART происходит при считывании этого буфера виайкой VISA Read. Пришло, например 10 байт Bytes at Port выдал значение 10. Подали это значение 10 на VISA Read он взял из буфера 10 байт. Не скопировал, именно взял. Т.е. в буфере ничего не осталось. Если бы подали на VISA Read значение 7, то было бы взято 7 байт, а 3 остались бы в буфере. И при следующей итерации Bytes at Port показал бы значение 3. А, если за это время итерации пришли бы, скажем, ещё 5 байт, то Bytes at Port показал бы не 3, а 8.
Select, <Сделал, время цикла установил в 500 ms, в соответствии с рекомендациями datasheet на железо.>
Для чего это? Что бы засинхронизировать работу железа и цикла программы? Ну как программа может повлиять на железо не понимаю. А эксперимент в результате свел к нулю. Поставь milliseconds to wait как и было 5 мс, а, может, и меньше и повтори опыт. Только по умолчанию делай не строковый индикатор read buffer, а весь массив. Для этого правой кнопкой мыши щёлкай не по индикатору read buffer, а по внешней рамки массива.

Юрий,
Ok,
Здесь же вывел общий стоковый индикатор с максимальным наполнением в серии итераций 44 баит , возможно это о чем -то скажет.
Думаю что имеет смысл в подстройке к аппаратной частоте MCU. Он по логике опрашивает состояние каналов и далее отправляет результат в eprom>...UART?

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

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

Такой класс устройств - печатающие в терминальный порт. В данном случае в виртуальный RS-232.
У нас весы есть такого типа.
Алгоритм приема у меня такой:
1. Определение старта посылки - это пауза
2. Чтение определенного количества символов или до терминального символа - в данном случае \r\n\r\n
3. Если количество символов совпадает и есть терминальный символ - то парсинг
Возможны варианты: посылка начата не сначала, посылка оборвалась, каналы пришли не по порядку.
Еще замечание. Строка параметра CH0:0001\t0.000V содержит номер канала, значение в ранге 0-4096 соответствующее 0-3,3В, значение с плавающей запятой, единицы измерения
Думаю у Вас нет проблем с парсингом, а есть проблема с формированием правильной посылки.
В моем примере сокращенный прием с имитацией (очереди). Нужно убрать имитацию.
Цикла опроса как такового нет, есть таймаут после приема. При большом таймауте будут отбрасываться предыдущие посылки, которые уже прошли или начались.
В примере цикл сбора (Producer Loop). Данные собираются в массивы. Через локальные переменные можно передавать в цикл отображения или в этом цикле разнести из массивов по индикаторам.

to: Blackman, Поясните пожалуйста в вашем примере, почему останавливаем for loop при длине строки в два символа? И еще, а почему 11 итераций, ведь каналов 10? Или имеется ввиду одинадцатая итерация и есть оставшиеся два символа "\r\n" завершающие всю посылку. А вообще красивое решение, мне понравилось.

[quote=="Select"]Хочу растащить строки из общего стокового стринг индикатора на отдельные, с отображением в реальном времени принимаемых аппаратных значений. [/quote]
Это у Вас уже реализовано, в моем примере. Только данные нужно читать быстро, т.к. у Вас каждые 500 мс приходят данные по 10 каналам, значит нужно читать хотя бы каждые 50 мс один канал. Ибо доска прочитает данные по всем 10 каналам раз в 500 мс, и потом если будете читать каждые 50 мс то как раз прочитаете все значения. Можно и быстрее читать.
Поймите наконец базу - как работает терминирующий символ. Если при открытии ссылки на порт указано использование терминирующего символа, то VISA Read выдаст данные когда получит этот терминирующий символ. Таким образом, не нужно постоянно проверять начало/конец посылки, драйвер это обрабатывает сам. И это происходит лишь в коде, т.е. доске с которой общается программа "до лампочки" как эти данные читаются. А это значит, что доска будет посылать одинаковые данные независимо от метода чтения - вопрос может быть лишь в том, как быстро Вы эти данные читаете. Если будете читать построчно и медленно - то само собой, данные будут старые. А если читать быстро построчно - то актуальные. Если все каналы целиком - то тоже актуальные, но нужно дополнительно их парсить, т.к. Вы не знаете где начало/конец посылки автоматически.
Можно читать и без терминирующего символа. Юрий Вам предоставил пример. Все что нужно сделать - это добавить на лицевую панель индикаторы, и распарсить массив данных в отдельные индикаторы. Можете хоть кейс-структурой, хоть массивом ссылок как у меня. В чем проблема-то? Это ведь общее программирование, работа с полями, с парсингом строк. У Вас в посылке есть и номер канала, и данные в нормальном формате - слепите наконец два примера в кучу, и будет счастье ))) Потому что я лично уже не понимаю в чем конкретно Ваша проблема, все уже решено - Вам остается только выбрать решение, и его использовать.