Форум: Техническая поддержка

Здравствуйте! Есть LTR-EU-2-5 с LTR24-1 на борту. Возможно ли подать на вход SYNC LTR-EU-2-5 синхроимпульсы и программно опрашивать DGIN 1 на наличие высокого уровня? Работаю в Labview. Не смог разобраться по руководству как это реализовать.

Режим программного опроса состояния входов DIGIN1, DIGIN2 разъёма SYNC возможен на уровне процессора Blackfin (при его самостоятельном программировании). Реализован ли такой опрос в библиотеках верхнего уровня подскажут коллеги. Но, в любом случае, использовать асинхронный программный опрос для целей синхронизации неправильно, поскольку точность по времени синхронизации будет зависима от нестабильного времени реакции операционной системы. Правильней было бы использовать режим вставки меток синхронизации по фронту/спаду на  DIGIN1 и DIGIN2 и с программным приёмом меток синхронизации вместе с отсчётами данных.

Здравствуйте.
Штатной функции для опроса этих входов нет (ни в библиотеках, ни в штатной прошивке Blackfin). Эти входы штатным образом можно использовать только для генерации специальный меток ("Старт" и/или "Секунда") по фронту или спаду сигнала на одном из входов. Метки вставляются вставляются в поток данных, чтобы моменты изменения сигнала могли быть привязаны к отсчетам модуля при сборе данных.
А что у Вас за задача?

Мне нужна метка "старт" для запуска сбора данных. У меня есть прямоугольный импульс, длительность которого определяет время вывода звукового импульса на звуковую плату. После этого необходимо начать сбор данных. Мне нужно определить фронт этого (прямоугольного) импульса и с этого момента начать сбор данных. Подскажите как это реализовать штатными функциями Labview.

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

Общий алгоритм может выглядеть так:
1. Надо настроить генерации метки "СТАРТ" для самого крейта. Для этого в LabView нужно создать отдельный объект типа ltrapiLabView, вызвав Open(), затем MakeStartMark с нужным параметром (см. описание функции в ltrapi.pdf). Затем можно сразу сделать Close() и удалить этот объект.
2. Запуск сбора (должен быть запущен соответственно до фронта) и прием с LTR24 аналогичен тому как в примере за исключением того, что нужно использовать вариант метода Recv() с наличием параметра tmark (есть две функции Recv() с ним и без него). На вход tmark нужно подать созданный массив, аналогично тому (и такого же размера) как подается на вход buffer.
Массив на выходе tmark представляет собой счетчик меток времени "Старт" (в старшей половине слова) и "Секунда" (в младшей половине) (раздел 4.2.5 ltrapi.pdf). Т.е. для выделения счетчика меток "Старт" нужно сдвинуть каждый отсчет влево на 16.  Размер массива tmark всегда равен количеству принятых слов от модуля и каждый элемент соответствует значениям счетчиков меток в момент приема соответствующего слова от модуля.

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

Когда изменение найдено, то для той итерации цикла приема, где есть изменение нужно сделать следующее:
- откинуть часть принятого массива слов от модуля (buffer) до номера отчета, соответствующего номеру элемента массива счетчиков меток с изменением счетчика меток "СТАРТ".
- на оставшийся массив вызвать FindFrameStart для поиска начала кадра сразу за изменением счетчика меток "СТАРТ" (он может произойти посередине кадра).
- Если полученный индекс >= 0, то отбросить еще кол-во отсчетов равное этому индексу из начала массива и уже оставшийся массив передать в ProcessData() и использовать в обработке. Если индекс < 0, то все данные в данном цикле можно отбросить

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

Спасибо! Буду пробовать. Возникнут вопросы напишу.

Этого не понимаю. Что такое MakeStartMark ? С каким нужным параметром? Я так понял, после функции Open сразу ставить LTR24_Recv с входом tmark??? И как потом удалить этот объект?

Можно ссылку на руководство, у меня ltr24api, там такого найти не могу.

ltrapi.pdf находится в архиве http://www.lcard.ru/download/ltr_sw.zip и описывает общие функции для работы с крейтом и сервером.

Если брать штатный для LTR24 пример http://www.lcard.ru/download/examples/l … abview.zip, то в нем показана работа с LTR24 и там создается объект типа ltr24api потом Open, работа, в конце Close и его удаление. Работа с LTR24 вся остается без изменения за исключением того, что нужно использовать другой вариант Recv и фильтровать входные данные, как я описывал.

Настройка условия генерации меток это настройка самого крейта, для работы нужен уже другой объект, который надо аналогичным образом создать только типа ltrapiApiLabview) для него также сделать Open() (для установки соединения с крейтом, а не модулем),  настройку меток, Close(), удаление объекта (аналогично тому как для LTR24, но это уже другая цепочка блоков). Ну и по хорошему только после этого уже делать все для LTR24.

Это должно быть так?

Почти. Только нужно использовать функцию (InvokeNode) MakeStartMark вместо PropertyNode StartMarks. На вход можно подать одну из констант из типа _LTRNative.en_MarkMode (либо просто целое число посмотрев значение констант в 4.1 в ltrapi.pdf)

Ещё вопрос - вход "hnd" на указанной функции для чего, что на него нужно подать?

Вход CrateSerial - что на него подать?

Если крейт один, то на CrateSerial можете подать массив из 16 байт с нулевыми элементами.

По поводу LTR24_Recv, то лучше использовать метод просто Recv без префикса LTR24_ (методы без префикса LTR24_ аналогичны методам с префиксом, за исключением того, что им не нужен первый параметр hnd, так как сам описатель уже содержится внутри объекта ltr24api).

У меня в одной программе будут работать два крейта, но метки в данные буду вставлять только на одном из крейтов. При таком варианте какой массив надо подавать на CrateSerial?

Это равно массиву размером 128 элементов с нулевыми элементами?

Вот так организовал вставку меток и использовал функцию для приёма данных без входа hnd так правильно? Crate Serial - тип U16.

Вообще CrateSerial это должен быть серийный номер крейта, с которым Вы хотите установить соединение. Тип это элемента насколько я вижу имеет byte[], поэтому я не очень понял как туда подключился U16... Вообще по логике там должна быть строка с серийным номером крейта (аналогично параметру csn в ltr24api.Open). Вариант, принимающий byte[] конечно использовать можно, преобразовав строку вручную, но не слишком выглядит удобно, поэтому если что я добавил вариант Open в котором CrateSerial является строкой, можете воспользоваться им (включил в установщик отсюда https://bitbucket.org/lcard/ltr_cross_s … .30.11.exe - при установке LabView должен быть полностью закрыт)

Как понять, что метки в данных формируются? С выхода tmark массив я подаю на GRAPH, но там сплошная нулевая линия без скачков.

Что метки приходят можно посмотреть в программе LtrServer/LtrManager - в них при выделении в параметрах написано кол-во пришедших меток Страрт и Секунда с момента подключения крейта

Чего-то не понятно. Если индекс больше либо равен нулю - отбрасываем данные, если меньше нуля отбрасываем данные. Так мы все данные отбрасываем. Или я недопонимаю?

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

В первом случае Вы откидываете только кол-во слов, равное индексу, во втором все.
Приведу пример, чтобы был ясен смысл действий. Допустим Вы принимаете с помощью Recv() блоками по 100 слов. При этом кадр у Вас допустим состоит из 4-х слов (например 2 канала в 24-битном режиме или 4 в 20-битном).
Допустим Вы фиксируете изменение метки в 18-м слове (при счете от единицы). Вы откидываете первые 17 слов, как слова до изменения метки, при этом получилось что вы откинули 4 кадра и еще одно из 4-х слов следующего кадра, а Вам надо обрабатывать целыми кадрами. Вы вызываете на оставшийся массив FindFrameStart, который вернет индекс 3 (считая от нуля), соответственно, вы откидываете первые 3 слова, которые относятся к неполному кадру и уже оставшийся массив из 80 слов обрабатываете.
Если же изменение метки произошло, допустим в 98 слове, то отбросив 97 слов в оставшихся 3-х словах начало кадра будет не найдено и, соответственно, можно откинуть все слова, а в следующем Recv() уже будет принято начало первого интересующего Вас кадра

Индекс, который нужно контролировать находится на выходе "FindFrameStart"? Посмотрите вот скрин как я реализовал поиск индекса изменения счётчика меток через пиковый детектор. Затем отбрасываю часть массива из buffer до индекса метки. Подаю на FindFrameStart. С выхода FindFrameStart индекс всегда ноль показывает. Схема в целом работает но выдаёт сообщение " Невыровненные данные". Посмотрите пожалуйста, что не так.