Доработка встроенного ПО L-ViMS под заданную задачу вряд ли реализуема, по крайней мере на текущий момент.

Доработка ПО верхнего уровня (LMS), в виде добавления в него программных модулей для расчета перечисленных Вами параметров, выглядит более реальной задачей, при этом настройка времени вычисления каждого параметра может быть задана тогда явно. В случае использования LMS в качестве оборудования возможно использовать крейт LTR-EU-2 с модулем LTR25 (до 8 ICP датчиков) + модулем для подключения датчиков оборотов, в зависимости от используемых датчиков (например LTR24 если диапазон выходного сигнала датчиков в пределах +/-10 В). Текущие возможности ПО см. https://www.lcard.ru/download/lms_users_guide.pdf. Принцип работы ПО: сперва настраивается сценарий эксперимента со всем используемым оборудованием, рассчитываемыми параметрами и способом отображения, затем по сценарию можно запустить ограниченный по времени эксперимент, с сохранением результатов для дальнейшего просмотра. Вопрос насколько это подходит под Вашу задачу?

С точки зрения метрологической аттестации, следует учитывать, что в системе Виброприбора насколько я понял, используются свои датчики и погрешность определяется для финальных рассчитываемых параметров. В случае L-ViMS погрешность нормируется для измерения входных сигналов напряжения, погрешность рассчитываемых параметров, хоть они и вычисляются самим модулем, явно не нормируется и не поверятся. Тут Вам нужно оценить, насколько в Вашем случае использование L-ViMS потребует отдельной метрологической аттестации всего комплекса и насколько тут большая разница с случаем использования варианта с расчетом в ПО верхнего уровня.

"Ethernet/MODBUS TCP или RS485/MODBUS RTU" - этот пункт не совсем понятен. В случае L-ViMS используются Ethernet/MODBUS TCP. В случае использования ПО верхнего уровня, какое значение имеет протокол передачи между модулем и этим ПО?  или Вам нужно передавать результаты расчетов в какое-то свое ПО и в случае использования LMS требуется, чтобы это ПО передавало стороннему софту вычисленные данные по Modbus TCP?

Да, если при пропаже сети произойдет переполнение буфера в крейте, то это тоже может привести к нарушению данных.
По поводу инициализации модулей, можете написать, какая версия прошивки крейта у Вас? Можно посмотреть в LTR Manger в параметрах крейта.

ProcessData обрабатывает данные покадрово, т.е. каждый обрабатываемый блок данных должен состоять из числа слов, кратного N (для 20-битного формата) или 2*N (длф 24-битный формата), где N - число разрешенных каналов. Т.е. если у Вас 4 канала и 20-битный режим, то необходимо не просто обрабатывать слова в очереди "когда в очереди набирается 4 или больше слов", но обрабатывать кратное 4 словам кол-во слов, после чего оставшиеся слова сдвигать в начало очереди и следующий принятый блок добавлять к ним. Данные ошибки как раз могут возникать, если склейка данных по кадрам и обработка строго целыми кадрами выполнена не корректно.

Следует также учитывать, что Windows не система реального времени, да и при передаче данных вносятся задержки передачи, поэтому обработка с таймаутом 5 мс будет приводить к тому, что хотя сбор на уровне модуля выполняется строго с заданной частотой (с учетом погрешности опорного генератора крейта), размеры принятых данных за 5 мс на стороне Windos будут сильно меняться от приема к приему и не соответствовать исходному интервалу сигнала 5 мс на уровне модуля. Если требуется обрабатывать по 5 мс исходя из времени синхронного ввода на уровне модуля, то может быть более корректно вычисление числа точек, которое модуль собирает за 5 мс исходя из установленной частоты и выполнять прием и обработку этого числа отсчетов с большим таймаутом (для учета времени передачи и задержек Windows), чтобы при штатной работе функция возвращалась по приему нужного количества отсчетов, а не таймауту, тогда хоть время на стороне ПК может варьироваться, но обкатываемые данные будет соответствовать интервалу снятых данных за 5 мс, и ручное разбиение на кадры не нужно (т.к. прием уже будет выравненным).

Отлично! Спасибо за информацию. Если будут вопросы, обращайтесь!

В LTR43 есть возможности генерации синхрометок, но это нужно было главным образом в первых вариантах крейта (LTR-U-1/8/16), тогда требовалось по модулю LTR41, LTR42 или LTR43 в каждом из синхроизируемых крейтов. В LTR-EU-2/8/16 и LTR-CEU-1 эти возможности уже включены в крейт, там есть отдельный разъем синхронизации SYNC на задней панали крейта с линиями для трансляции сигнала генерации меток одним крейтом и приема другим, о котором я писал выше. 

Смотря сколько длится у Вас эксперимент и какого уровня точность синхронизации требуется. С помощью одной метки Вы можете синхронизировать момент старта, что если эксперимент относительно не длительный, может быть достаточно. Но в случае длительного эксперимента будет постепенный уход меду двумя крейтами с течением времени из-за того, что каждый крейт работает от своего генератора, расхождение которых может составлять ±50 ppm  (до ~4.3 сек в сутки). Соответственно при длительном эксперименте нужны еще и периодические метки и подстройка времени отсчетов во время сбора.

Сам принцип подключения и программной настройки описан в руководстве ltrapi на главу в котором давал ссылку выше, есть еще глава 2.8.4 в руководства по программе LMS (https://www.lcard.ru/download/lms_users_guide.pdf), с учетом интерфейса этой программы, но и общий принцип изложен. Если будет непонятно, пишите.

Настройку на уровне крейта (из ltrapi) можно делать также из программы LTR Manager.

Из примеров LabView есть пример начала сбора по метке СТАРТ для модуля LTR24 (https://www.lcard.ru/download/examples/ … _start.zip), для других модулей принцип такой же. Есть пример настройки выходов разъема SYNC (https://www.lcard.ru/download/examples/ … ut-cfg.zip), правда для другого случая, но общий принцип переноса API из ltrapi на LabView можно понять.

Здравствуйте. До этого не было запросов о возможности подключения инфракрасного приемопередатчика к крейту LTR, поэтому этот вопрос не рассматривался и не проверялся. Принципиально должно быть возможно подключить такой приемопередатчиком, если он может работать от 3.3В, к разъему SYNC крейта, запитав от  3.3 В с этого разъема и подключив TX и RX к DIGIN/DIGOUT разъема SYNC выведя на них TX/RX с UART аналогично случаю RS. Судя по описанию IrDA сигналы обмена с приемопередатчиком однонаправленные и в принципе прохождение сигналов через ПЛИС не должно препятствовать. Но чтобы использовать данную возможность, также придется модифицировать прошивку крейта, чтобы добавить в нее подобный функционал.

Здравствуйте.
Для начала просьба уточнить, правильно ли я понял, что:
1. Используется именно циклический режим вывода (функции X502_OutCycleLoadStart/X502_OutCycleSetup)
2. Смена сигнала у Вас идет без остановки сбора/генерации (т.е. StreamsStart выполняется только один раз, а смена идет на лету через какое-то время через те же X502_OutCycleLoadStart/X502_OutCycleSetup)
3. На последней картинке сама частота сменилась корректно и Вас не устраивает именно фаза (соответствие первой точки сигнала и начала собранного блока АЦП). При этом этот сдвиг фазы фиксированный, т.е. сигнал до следующей смены сигнала сигнал не дергается, просто начало некорректно.

Также уточните, какой интерфейс используется (USB или Ethernet) и модификацию модуля.

"АЦП при этом считывает за раз 819200 байт, что соответствует 102400 отсчётам для 2 каналов" - тут наверное все же опечатка, размер отсчета АЦП 1 слово = 4 байта, т.е. с учетом что DIN не включен, то 102400 отчета это 409600 байт.

Да, для разработки своего приложения (по крайней мере на C) требуется установка заголовочных файлов (с описаниями типов, функций и т.п.), для этого нужно установить пакет libltrapi1-dev (общий для всех библиотек, он не делится по модулям), к которому как зависимости будут также установленные уже отдельные пакеты libltrXXXapi1 под каждый модуль, в которых сами соответствующие библиотеки. А для работы уже собранного приложения -dev не обязателен, достаточны только используемые libltrXXXapi1.

Также для работы программы требуется установка пакета ltrd, т.к. ltrapi работают через эту службу с крейтами.

Пакет ltrmanger - GUI программа для просмотра подключенных крейтов, с возможностью настройки крейтов на Ethernet, подключения по Ethernet, обновления прошивки крейта и т.п.. Не обязательна для работы/сборки своей программы, но полезная отдельная программа.

Подробнее в https://www.lcard.ru/download/ltr_soft_ … tarted.pdf и https://www.lcard.ru/download/ltr_cross_sdk.pdf.

Добрый день!

Существует одно важное отличие между обменом с модулями из крейта и из ltrapi.

Сам обмен идет с помощью 32-битных слов, общий формат которых описан в разделе 4.6 документа https://www.lcard.ru/download/ltr.pdf. При этом через процессор идет один поток со словами всех модулей крейта, и задать, какому модулю предназначено слово на передачу, или узнать, от какого модуля пришло слово, можно узнать по битам MMMM (биты с 8 по 11), 0 - первый слот, 15 - последний в 16-местном крейте.

В ltrXXXapi работа идет с одним модулем в конкретном слоте и поле MMMM не заполняется и не анализируется в самой библиотеке, это делается в службе ltrd, которая объединяет передаваемые потоки от клиентов api в один крейту заполняя поля MMMM и разбивает приходящий поток слов по полю MMMM на потоки каждому клиенту.

В остальном же эти слова передаются в крейт без изменений, т.е. как их формирует библиотека и отправляет через LTR_Send/принимает через LTR_Recv, так их и нужно передавать в крейте, только добавив заполнение поля MMMM на передачу и анализ на прием.

В крейте для передачи слов модулям используется baybustx_put() или baybustx_put_array(), которая кладет слово/несколько слов в буфер на передачу в модули и уже дальше они отправляются в фоне. Проверить наличие места в буфере на передачу можно через baybustx_is_buf_full()/baybustx_free_size_byte(). Единственное, если Вы это делаете в параллель с штатной передачей из ПК, то нужно сделать какую-то защиту от выполнения этих функций в параллель из разных потоков.

Прием же выполняется функцией baybusrx_get_data(). Т.к. поток общий, то она получает слова принятые от всех модулей, а дальше по полю MMMM уже можно понять, от какого модуля каждое слово. Если хотите это делать в параллель с штатным приемом и передачей в ПК слов, то тогда нужно там, где эта функция вызывается (отдельно для каждого интерфейса usb/ethernet) после ее вызова перед тем как они будут поставлены на передачу в ПК сделать вызов своей обработки с фильтрацией по слоту модуля.

По сути вся работа с модулем и состоит из посылки нужных слов модулю и ожидания нужных слов в ответ. В первую очередь нужно проверить работу штатной последовательности посылки команд STOP-STOP-RESET-STOP общей для всех модулей, которая описана в том же разделе 4.6 (для некоторых модулей при запущенном сборе одного STOP может быть не достаточно, при этом второй STOP ничему не мешает, поэтому рекомендуется все же слать два STOP перед RESET). Эта посылка реализована в ltr_module_open в lib/ltrmodule/ltrmodule.c в исходных кодах ltrapi, и получить в ответ на это слово с идентификатором модуля.Если это получится, то дальше уже по аналогии обмен словами из всех функций ltr11api.

Опорная частота 24.576 МГц делится на 5 и получается тактовая частота АЦП = 4.9152 МГц. Частота отсчетов на выходе АЦП для настроек режима высокой точности  получается  делением: 4.9152 / (3 * 16  * 682) = 150.146627566 Гц.
Для модулей LTR212M-1 и LTR212M-2 исходная частота получается из частоты опорного генератора крейта и одинакова в рамках одного крейта, для остальных модификаций - от генератора на самом модуле. Реальная частота может отличаться от номинальной, но в пределах ±50 ppm в рабочих условиях. Соответственно такой же будет максимальный разброс частот между модулями разных крейтов или модулями c модификациями не M1/M2 в одном крейте.

Как и для других модулей ввода данные можно привязать друг к другу с помощью синхрометок с точностью до периода преобразования. Для этого нужно настроить генерацию меток, для синхронизации модулей в разных крейтах также потребуется соединение сигналов разъема синхронизации. С точки зрения ПО это описано в разделе 4.6 руководства программиста, а с точки зрения аппаратуры в разделе 4.7 руководства руководства пользователя, там же на Рис. 3-6. и в таблице 3-3 описан разъем синхронизации.

Добрый день.
Попробуйте взять последнюю версию исходных кодов прошивки (https://www.lcard.ru/download/user/ltr/ … master.zip, версия 3.0.0.17, номер соответствующей версии прошивки можно посмотреть номер в init.c). В ней там как раз были правки по поводу перезагрузки в  process_sd_test() из-за того, что не всегда успевал выполняться сброс сторожевого таймера. Попробуйте будет ли у Вас работать. При этом process_sd_test() тоже использует функции из efsl (функции if_xxxx). Возможно и в Вашем случая сходная проблема, что если функция долго выполняется без возврата управления, то можно не успеть сбросить сторожевой таймер и процессор перезагрузится.
По поводу флага g_sdtest_result, то запуск теста sd в штатной прошивке выполняется только по внешнему запросу (ltr030_CC_StartSDTest в ven_requests.c), который устанавливает g_sdtest_result в 0xFFFF, если Вы хотите при старте ее выполнять, то нужно либо при старте устанавливать эту переменную, либо поменять логику функции.

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

А по поводу большого процента потерь пакетов (там где 5.5% на скриншоте), если такой тест произвести не с крейтом, а с пк, который вовне (i3), проверить путь до ПК который в той же сети, что с крейтами (i5), то также будет большой процент потерь (чтобы понять, такие потери только при обмене с крейтом или в канале до той точки где крейт)?

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