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

не совсем понятно, что имеется ввиду под "единица данных". Единицей передачи данных независимо от модуля является 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;

X502_GetAdcCoef принимает параметром номер диапазона и возвращает два коэффициента (k и b) для этого диапазона. Номера диапазонов определены как t_x502_adc_range в x502api.h, т.е. начинается с диапазона 10 В, который имеет номер 0.

Добрый день. Переходник видимо имеется ввиду DB37Fv4 (https://www.lcard.ru/products/accesorie … -increaser). Он подходит к любому модулю LTR и на нем сигналы с разъема на передней панели модуля выводятся на клеммы один к одному для возможности удобного подключения проводов.

Подключение сигналов к LTR114 подробно описано в разделе 18.3 руководства LTR (https://www.lcard.ru/download/ltr.pdf), в частности соответствие сигналов и номеров контактов на разъеме модуля/переходнике указаны на рисунке 18-4 и описаны в таблице 18-2, а типичные варианты подключения на рисунке 18-6.

А что именно подразумевается под "Сломалось взаимодействие с нашим ПО"? Какие именно возможности LTR43 вы используете и в чем проявляется некорректная работа?

Так с точки зрения api работа не должна была меняться. Чтобы проверить, действительно ли проблема в версии прошивки LTR43, выложил сюда архив с версией 2.0: http://lcard.ru/download/ltr43_avr_update_2.0.zip (нужно разархивировать, закрыть все программы, работающие с модулем LTR43, и вызвать ltr43_update_all.bat)

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

Не совсем так, правильнее каждое поле от начала структуры выравнено на минимум между своим размером и 4 (т.е. байтовое располагается подряд, WORD всегда выравнен на 2 байта от начала структуры, DWORD/INT/float/double выравнены на 4 байта)
Т.е. например несколько байтовых полей идут всегда подряд.
Если два байтовых поля, а потом двухбайтовое, они тоже будут подряд.
Если одно байтовое, а потом двухбайтовое, то будет пропуск после первого байта, чтобы выравнять второе поле на 2 байта.
Если одно байтовое, а потом 4-х байтовое, то после байтового поля будет 3 байта пропуска, чтобы выравнять второе на 4 байта.
Если одно байтовое, а потом 8-и байтовое, то будет точно также 3 байта пропуска, т.к. из-за pack(4) поля размером больше 4 тоже выравниваются на 4

Также нужно учесть, что размер BOOL 4 байта, а размер BOOLEAN - 1 байт. Размер указателя зависит от используемой разрядности компилятора/виртуальной машины (4 или 8 байт).

Если в языке есть способ узнать размер полученной структуры (по аналогии с sizeof в C), то правильность вы всегда можете проверить, сравнив размер, полученный в вашем языке аналогом sizeof, с размером, который будет в поле Size после вызова LTR24_Init

Здравствуйте. Если говорить про исходную библиотеку  e502api/x502api на C, то она под Linux работает, в том числе и под ARM, нужно только собрать или взять собранный пакет под нужную архитектуру и ОС.
Что касается LabView и .Net обертки (lpcieNet), через которую работают штатные примеры LabView, то их работа под Linux не проверялась. Нельзя исключать, что для запуска понадобятся какие-то правки.
Ну и само LabView, нужно смотреть как у него с поддержкой ARM, раньше вроде была поддержка только amd/intel, вроде есть некий LabVIEW Hobbyist Toolkit для запуска  на Raspberry, но не знаю, есть ли там какие-то особенности...