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

Здравствуйте.
Для начала нужно понять:
1. Влияет ли  режим работы с DSP на переполнение, т.е. если оставить тот же код, но включать режим работы с FPGA, то проблема остается?
2. Влияет ли сам код Вашей программы, т.к. если какие-то действия после завершения Recv до следующего его вызова выполняются дольше, чем собственно время, за которое выполняется преобразование принимаемого за блок кол-ва точек, то данные будут забираться медленнее, чем передаваться модулем, что в конце концов приведет к переполнению буфера. Можно взять консольный пример, и посмотреть на нем, изменив настройки модуля на используемые у Вас, а затем также добавив загрузку прошивки DSP.

По поводу описания передачи данных, то в принципе корректно, только во фразе:

не совсем понятно, что имеется ввиду под "единица данных". Единицей передачи данных независимо от модуля является 32-битное слово (которые принимаются в LTRxxx_Recv()). Отличие в том, что в LTR114 во первых одному отсчету соответствует 2 слова, во вторых, так как это модуль с коммутацией каналов и измерения происходят последовательно, то он передает по одному отсчету (2 слова), как только очередные данные будут готовы, т.е. данные будут передаваться по два слова равномерно с частой АЦП. В LTR27 одному отсчету соответствует одно слово, при этом в этом модуле каналы АЦП работают параллельно и модуль сразу выдает все 16 слов (по одному отчету на канал) раз в заданный период дискретизации АЦП. В LTR51 передача идет аналогично LTR27, но одному отсчету соответствует два слова, со значениями M и N. Но все это передается в общий буфер и при передаче в ПК один кадр даже переданный одновременно от модуля, как для LTR27? может быть разбит например на разные пакеты TCP, в середину кадра попасть данные другого модуля если придут в момент передачи слов кадра и т.п.

a) идея в принципе правильная, правда при передаче по Ethernet это все немного сложнее. Корректнее сказать, что данные поступают в общий буфер в крейте, прошивка процессора крейта на сколько я помню раз в 1 мс проверяет наличия новых данных в FIFO и при их наличии ставит их на передачу по интерфейсу, в Вашем случае через TCP по Ethernet. Далее уже действуют алгоритмы передачи самого TCP, на которые влияет реализация TCP с обоих сторон соединения, в частности Алгоритм Нейгла  (данные передаются либо когда все отправленные были подтверждены другой стороной, либо накопился целый новый пакет для отправки по TCP), подверждения от ПК  так же могут при этом быть отложены и не переданы сразу (delayed ACK) и т.п.

б) Если говорить о задержках в модулях и в крейте до попадания данных в FIFO буфер крейта, то тут они будут либо фиксированы для каждого типа модуля, либо иметь небольшой дребезг, но явно они не измерялись для каждого режима работы каждого модуля. Но они не должны превышать единиц мс и остальные факторы по идее должны иметь большее значение при обработке данных на ПК.

в)  Задержки в сети измерить выглядит не так просто, если под ними подразумевать не только физическое время передачи пакета, но и задержки в планировании отправки пакетов сетевого стека с обоих сторон соединения. Про ltrd так, но опять же ОС общего назначения вполне имеет право вносить задержки при переключении задач на выполнения ltrd, при передаче программе сигнала готовности данных принятых по сети в сокете и т.п., и они в общем случае не нормированы, хотя и в частном случае малозагруженной системы могут быть минимальными
г) помимо буфера ltrd нужно иметь ввиду, что обмен ltrd с клиентом также выполняется через локальные сокеты, у которых тоже есть свой внутренний буфер. Если в нем есть место, то ltrd сразу принятые слова записывает в сокет на передачу клиенту и они в собственно буфере данных модуля в самом ltrd  не задерживаются. Заполняться буфер будет в том случае, если сокет клиента не может принять на передачу данные из-за того, что его буфер заполнен. Таким образом действительно, если клиент своевременно откачивает данные, то этот буфер должен быть пуст или минимально заполнен.
В теории (если это действительно нужно, см. дальше) определить число готовых к приему слов по статистике можно, но если использовать счетчик принятых от модуля слов (wrd_recv). Т.е. можно перед LTRxxx_Start() прочитать это значение, далее с учетом того, что по крайней мере для используемых у Вас модулей, по вызову Start происходит посылка одной команды с одним ответом (для LTR114 предполагается, что начальная калибровка уже выполнена до старта), то прибавить к этому числу 1 и взять это значение за начало отчета. Далее проверяя статистику и вычисляя разницу между новым wrd_recv и взятым за начало отсчета, можно понять, сколько слов данных было принято от модуля. При этом нужно также завести счетчик принятых слов клиентом (т.е. Вашей программой) увеличиваемый при каждом успешном Recv на количество принятых слов. Соответственно разница числа принятых слов от модуля и принятых слов клиентом и будет числом принятых ltrd, но не считанных клиентом слов, т.е. той самой общей заполненностью буферов сокета клиента и буфера модуля в ltrd.

д) Подходы могут быть разные... С моей стороны самым простым и удобным является выделение под каждый модуль потока, и в нем реализовывать принцип, который и приводится в консольных примерах на модуль. Т.е. исходя из интервала обработки и настроенных частоты сбора и прочих настроек можно получить, сколько слов мы должны обработать за один цикл программы, а далее вызывается в этом потоке Recv на этот размер с заведомо большим таймаутом (время цикла плюс несколько секунд). В этом случае при корректной работе Recv ожидает заданное число слов и как только они дойдут до клиента, Recv вернет управление (по сути то, что Вы пытаетесь сделать). Таймаута функция при штатной работе не дожидается (т.к. завершение работы функции выполняется по тому событию, которое было первым - пришло нужное число данных или истек таймаут), и служит только как указание через сколько выйти из функции в случае каких-либо ошибочных ситуациях, и завышенное значение негативно на нормальную работу не влияет. Далее уже идет ProcessData, возможно какая-то своя обработка и далее при необходимости передача полученного блока данных за цикл в другой поток для обработки/сохранения в зависимости от задачи. После переход к новому циклу ожидания. В этом случае время цикла обработки определяется временем прихода нужного числа данных, нет требования измерять время или заполненность буфера вручную и если время обработки меньше времени цикла, то гарантирует своевременную откачку данных. Так как на каждый модуль свой поток, то то, что он спит, ожидая новую порцию данных внутри Recv, не является проблемой, все равно ему нечего выполнять, пока нет новых данных. Если есть желание принимать данные всех модулей в одном потоке, тогда общий поток не должен зависать в Recv, тогда имеет смысл получать число непрочитанных слов через статистики описанным выше методом, а при потоке на модуль не уверен в целесообразности этого...
e) ну тут опять же зависит от Вашей программы, если как описано выше Recv используется для ожидания новых данных, то таймаут может быть взят с большим запасом на несколько секунд больше интервала сбора и это ничему не вредит, в варианте со статистикой он может быть и небольшим (в пределах секунды или десятков/сотен мс), тут только задержки самой ОС могут влиять, хотя опять же увеличение его не влияет негативно на штатную работу.

Здравствуйте.

Вы вроде сами приводите порядок вызова функций, поэтому не совсем понятно, как у Вас может вызываться Stop лишний раз или без Start. Корректная работа с модулем подразумевает, что Stop вызывается на успешно выполненный Start один раз, другое использование нештатное и для определенных типов модулей действительно Stop во время не запущенного сбора приводит к такой ошибке.

Если данные не вычитывать и они заполнят весь буфер, то далее из-за отсутствия места станут отбрасываться, если вызвать Stop в этот момент, то так как команды и данные передаются в LTR общим потоком для модуля, то ответ на Stop может быть отброшен из-за отсутствия места в буфера, что может привести к подобной ошибке. Но переполнение это не штатная ситуация, которая при нормальной работе не должна возникать.

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

При корректной последовательности вызовов и штатной работе подобных проблем при вызове Stop возникать не должно. Выполнять вызов последовательности функций правильно целиком в Ваших руках, а переполнение буфера это в общем нештатная ситуация, которая по хорошему требует перезапуск сбора или вообще целиком модуля (Close/Open).

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

Здравствуйте.

Да, для L-502/E-502/E16 используется другая библиотека. Ее подробное описание приведено тут: https://www.lcard.ru/download/x502&e16api.pdf
По поводу установки библиотеки, то пакеты устанавливаются аналогично lcomp, только требуемый пакет libx502api1-devel и его зависимости. Драйвер для E-502 не требуется, так как работа по USB под Linux идет через стандартную библиотеку  libusb-1.0, а Ethrenet в принципе драйверов не требует. Установка под Linux описана в пункте 2.1.7 руководства программиста.

Примеры есть на сайте на странице https://www.lcard.ru/support/developer в разделе E-502/L-502, там есть два консольных примера под msvc/gcc:
Ввод - https://www.lcard.ru/download/examples/ … m_read.zip
Циклический вывод - https://www.lcard.ru/download/examples/ … le_out.zip
Также в исходных кодах библиотеки можно дополнительные примеры использования посмотреть: https://gitlab.com/l-card/acq/devices/x … type=heads

По поводу Вашей задачи я не до конца понял про мертвое время и запуск каждую секунду на 2 секунды. Но думаю что Вам нужно смотреть в сторону запуска постоянного потокового ввода одновременно данных АЦП и цифровых линий и по данным цифровых линий определять момент фронта PPS и привязывать к нему данные АЦП и уже делить на файлы и изменять данные в соответствии с задачей. Режимом именно запуска сбора по сигналу синхронизации у Вас вряд ли получится, т.к. во-первых синхронизация запуска АЦП и ЦАП идет по одному условию, а у Вас ЦАП если я правильно понял должен генерировать сигнал непрерывно и на том же модуле, а во-вторых иначе у Вас будут теряться данные во время перезапуска сбора, а у Вас время записи на 2 секунды по сути на два блока непрерывного сбора, и не понятно как гарантировать, чтобы перезапуск успел до прихода следующего PPS.

Функция SetLDeviceEvent реализована только в Windows-версии библиотеки lcomp.
Для Linux если только вручную отслеживать по позиции в буфере, когда будет принято нужное число отсчетов, после чего перезапускать сбор.

В смысле если посмотреть бинарные данные из записываемого файла, например через

xxd test.dat | less

то будут одни только нули?

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

И можете также вывести результат RequestBufferStream - заменить

 
pI->RequestBufferStream(&size);
cout << " alloc size " <<  size << endl;

на

 
err = pI->RequestBufferStream(&size);
cout << " alloc size " <<  size << " err " << err << endl;