В 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 завершился по таймауту и вернул не все данные и т.п. А нет возможности проверить на штатном консольном примере, как он будет вести себя если запустить его на неправильном ПК (можно запустить несколько в параллель для сбора с нескольких модулей)?

Если речь про burnUSB.bat из архива с версией 2.0.0.0, то в принципе он рабочий, просто требует остановки ltrd и привязан к Windows.
Поэтому сейчас основной вариант описан в ltr_cross_sdk.pdf: либо через LTR Manger (пункт 4.3.3), либо в отдельной консольной утилитой (пункт 4.5.1.3). Последнее в основном для использования в Linux без графического интерфейса.

Подумаю, возможно можно будет включить краткое описание способов в  ltr_soft_getting_started.pdf, чтобы не было вопросов...

Здравствуйте.
В принципе должно быть возможно. Можно использовать как циклический вывод на одно слово (значение выходов DO), так и потоковый, подгрузив одно значение (если новые не будет передаваться, то будет повторяться на выводе последнее). Сделать предзагрузку этого одного слова нужно до X502_StreamsStart(), тогда по X502_StreamsStart() начнется выводиться как это значение на DOUT, так и сбор АЦП (с фиксированной задержкой, описанной в руководстве пользователя.
А вот чтобы установить выход обратно в 0 по останову сбора данных придется видимо использовать асинхронный вывод значения перед X502_StreamsStop() или после него, соответственно будет разница во времени между этими двумя событиями на время выполнения этих команд.

А какие версии прошивки крейта у Вас? Если ниже последней (3.0.0.17), то лучше обновить.

Каких-то специальных требований, кроме необходимости обеспечить непрерывный поток данных в соответствии с настроенной частотой сбора. В остальном требования такие же как и с другими сетевыми устройствами со статическим IP-адресом. Хотя конечно полностью исключать какие-то проблемы с совместимостью с работой какого-либо сетевого оборудования нельзя...

А как именно у Вас организована сеть у клиента? Что отвечает за разделение сетей? Есть там NAT и если да, настроен ли проброс портов и каким образом и т.д. Также вопрос наличия другого трафика, не может ли возникать полная загрузка канала другим трафиком в этой сети?
Также на всякий случай следует проверить отсутствие пересечения IP адресов других устройств с адресами крейтов в сети клиента.

Есть ли возможность записать на ПК клиента обмен данными с помощью программы вроде Wireshark и прислать нам?

Настройка шлюза требуется только в том случае, если у Вас крейт и ПК с ltrd (ну или ПК с ltrd и ПК с программой сбора данных, если они разные) находятся в разных сетях (т.е. в IP адресе старшие части адреса, отвечающие за сеть, у ПК и крейта отличаются). В этом случае т.к. устройство не может напрямую послать пакет в другую сеть, оно шлет его по указанному адресу шлюза для дальнейшей передачи. Для крейта адрес шлюза задается в его сетевых настройках, как и его IP-адрес. В LTR Manager для их изменения нужно нажать правой кнопки мыши на подключенном крейте и выбрать пункт "Сетевые настройки" (до версии прошивки 3.0.0.17 доступен только при подключении по USB). Для ПО на ПК адрес шлюза определяется сетевыми настройками самого ПК.
Но опять же в локальной сети настройка шлюза не требуется, а если Вы работаете в разных сетях, то без нее по идее и работать не должно.
Поэтому сильно сомневаюсь, что проблема как-то с этим связана.
А если запускать просто в параллель несколько консольных примеров, с измененными настройками на Ваши, то проблема будет проявляться?