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

Функция ltr27_recv возвращает, как указано в документации, количество отсчетов. Я так понимаю, LTR27 всегда снимает все каналы, независимо от их количества и видового состава (т.е., H27-R, хоть и имеет 1 канал, в массиве отсчетов занимает 2 поля). Это правильно? Тогда второй вопрос: в чем возвращается значение от функции ltr27_recv? В штуках принятых каналов (2 цикла по 16 каналов=32)? В штуках проведенных циклов измерений (2 цикла=2)?
Или, если в крейте стоят 3 модуля из 8, в массиве результатов будет только эти 6 каналов "кругами", а остальных каналов не будет вовсе (а не заполнены мусором или нулями еще 10 каналов)?

Владимир, вам должен помочь параграф 4.3.2.5 http://www.lcard.ru/download/ltr27api.pdf :
"Вне зависимости от параметров работы АЦП порядок следования данных всегда фиксирован:

• данные 1-го канала мезонина установленного в 1-ом слоте модуля;

• данные 2-го канала мезонина установленного в 1-ом слоте модуля;

• т.д.

• данные 2-го канала мезонина установленного в 8-ом слоте модуля;

Таким образом, каждый 16-ый элемент массива содержит отсчеты одного и того же канала АЦП"

Возвращаемое значение в DWORD'ах, т.е. в тех же единицах, что параметр size. В "штуках принятых каналов", как Вы говорите.

В данном параграфе несколько туманно изложен вариант, если в каком-то слоте просто нет мезонина. Соответственно, нет и его каналов. Что при этом происходит? Единственная догадка вытекает из "каждый 16-ый элемент массива содержит отсчеты одного и того же канала АЦП". Т.е., видимо, автор документации намекает, что все равно там что-то будет выдаваться и поля в 2 DWORD на 2 канала будут чем-то заполнены. На этот вопрос более четко отвечает п. 5.1.1, это уже приложение, интересное тем, кто библиотекой ltr27api.dll не пользуется, а значит, для остальных и к прочтению не обязательное. Вот там-то вдруг этот вопрос освещается: "Данные АЦП высылаются хост-компьютеру кадрами по 16 32-х разрядных слова, содержащими отсчеты всех 16 каналов вне зависимости от наличия на плате мезонинов."

Ок. Тогда у меня следующий вопрос: я запрашиваю у ltr27_recv 16*8 штук отсчетов: 16 каналов * 8 циклов, а мне функция отдает 3 и в следующий раз 13.
1. Это, действительно, мне готовы отдать 3 канала? А остальные 13 в след. раз?
2. Я могу быть уверен, что те 3 и эти 13 снимались в одно время?
3. Если в начале я указываю на буфер как @Data[0], в следующий раз мне нужно будет указывать на @Data[3]?

<blockquote>
<p>1. Это, действительно, мне готовы отдать 3 канала? А остальные 13 в след. раз?</p>

<p>2.Я могу быть уверен, что те 3 и эти 13 снимались в одно время?</p>
</blockquote>

<p>Система LTR (вне зависимости от типа крейта) - это система с глубокой буферизацией. Это объяснено в&nbsp; http://lcard.ru/download/ltr.pdf , глава 4, в частности, рис 4-3. Это означает, что все последовательно снятые отсчёты ложатся в буфер без потери данных. К этим буферам также добпавляются задержки буферизации USB и LTR-сервера.&nbsp; Потому, функция приёма может вернуть меньшее количество отсчётов, чем запрошено сейчас. А следующий раз - снова вернёт столько, сколько дошло на момент данного запроса - не больше, чем запрошено. Главное, чтобы средняя скорость приёма данных на верхнем уровне&nbsp; не была меньше, чем отдаёт каждый модуль, иначе буфера переполнятся.&nbsp; LTR27 <strong>всегда</strong> отдаёт по 16 отсчётов данных 16-ти каналов, относящихся к&nbsp; одному и тому же времени дискретизации входного сигнала,&nbsp; вне зависимости от того, физически присутствуют ли соответствующий канал в LTR27 (установлен ли субмодуль, 1- или 2-х канальный ли&nbsp; субмодуль). Следующие 16 отстают по времени дискретизации от предыдущих&nbsp;16-ти на период дискретизации. Каждый отсчёт в LTR27 -&nbsp; 4-х байтный, "индексный" -&nbsp; кроме отсчёта данных, содержит номер канала и номер модуля. Последовательность номеров каналов в потоке отсчётов - всегда естественная -&nbsp; это индексы от 0 до 15, соответствующие <strong>физическим</strong>&nbsp; номерам каналов от 1-го до 16-го. (Я - не программист, но не&nbsp; плохо представляю себе аппаратную архитектуру LTR ) &nbsp;</p>

<p>&nbsp;</p>

<p>&nbsp;</p>

<p>4-х байтые слова не использованных каналов не бессмысленны, поскольку их индексная часть используются для контроля целостности данных на приёме. Кроме того, независимость формата даггых&nbsp; от конфигурации субмодулей - это удобно со всех точек зрения. Увеличение трафика из-за избыточности - этот аргумент (в случае LTR27, как самого медленного модуля в системе LTR)&nbsp; не является значимым.&nbsp;</p>

Александр, спасибо!

Обращаясь к разработчикам: неужели это посчитали удобным: резать отсчеты одного цикла на несколько кусков? При "глубокой буферизации" уже нет риска переполнить буфер, так зачем отдавать "наверх" 3 отсчета из 16, если вся система (и программа наверху) заточена под получения 16 отсчетов на каждом цикле? И почему бы не предусмотреть функцию, которая отдает количество накопленных в буфере отсчетов, чтобы можно было не вызывать ltr27_recv до накопления 16 штук, а при накоплении 16 и более вызвать ltr27_recv с указанием принять 16 отсчетов. Вещь-то элементарная, а как снижает количество головной боли у разработчика верхней программы!

<p>Здравствуйте.</p>

<p>Для приема данных из сервера, независимо от модуля, используется общий механизм работы через сокеты, которые ничего не знают о кратности слов в кадре и т.п. Объединение слов в кадры - уже более выскоуровневый сервис. API LTR достаточно "низкоуровневое", то есть дает доступ к тем данным в том виде, что передаются от модуля (чем некоторые пользователи и пользуются), но требует некоторой дополнительной работы для пользователя.&nbsp;</p>

<p>По поводу узнавания количества слов в буфере, то эта вещь совсем не элементарная, хотя бы потому, что в буфер из сервера передаются не только отсчеты модуля, но и служебная информация (например, информация о метках "старт" и "секунда"), которые анализируются в LTR_Recv() и извлекаются из потока данных. Таким образом, до приема и разбора данных нельзя узнать, сколько слов в буфере именно с данными от модуля.</p>

<p>Честно говоря я не вижу большой сложности в объединении принятых слов по кадрам (в простейшем случае при заведомо большем таймауте можно просто считать прием меньшего количества слов ошибкой).&nbsp;<br />
Теоретически возможно создание функций приема возвращающих кратное количество слов, но они по сути будут выполнять ту же работу, принимая во временный буфер внутри API и выдавая уже кратные блоки, но тут всегда встает вопрос бинарной совместимости библиотек...&nbsp;</p>

> Честно говоря я не вижу большой сложности в объединении принятых слов по кадрам (в простейшем случае при заведомо большем таймауте можно просто считать прием меньшего количества слов ошибкой).
При большой частоте съема играть с таймером в винде может оказаться несколько чревато, поэтому я пытаюсь опрашивать ltr27_recv чаще, чем должны идти кадры. В результате чего и получаю кусочки кадров.

> Теоретически возможно создание функций приема возвращающих кратное количество слов, но они по сути будут выполнять ту же работу, принимая во временный буфер внутри API и выдавая уже кратные блоки, но тут всегда встает вопрос бинарной совместимости библиотек...
"Теоретически, можно сделать удобно для пользователя, но пусть уж он помучается"...

<p>Таймер в винде использовать для подобных целей вообще сомнительное решение, а тем более при большой "частоте съема"...</p>

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

Владимир, обращаю Ваше внимание на слова Алексея: "при заведомо большем таймауте можно просто считать прием меньшего количества слов ошибкой".
Все дело в таймаутах. Функция ltr_recv не станет просто так, по каким-то внутренним причинам возвращать меньше данных, чем запрошено, она завершается по одному из двух условий, смотря какое наступит раньше: прием запрошенного количества данных или исчерпание отведенного времени. В последнем случае возвращается столько данных, сколько успело прийти.
Обыкновенно программы пишутся исходя из того, что таймаут - это ошибка. Опрашивать в коротком цикле с маленьким таймаутом я бы не советовал, хотя иногда логика программы верхнего уровня этого требует.
Если Ваша программа должна параллельно что-то делать, может быть целесообразно выделить работу с крейтом в отдельный поток (thread), а таймауты сделать достаточно большими.
Вообще надо заметить, что ни ПК с обычной ОС, ни LTR в части накопления и выдачи собранных данных - не системы реального времени, поэтому полагаться на какие-либо временнЫе характеристики потока данных, выдаваемых ltrapi, не стоит. Например, может быть пауза, а потом прийти целая пачка отсчетов (если, к примеру, ОС была занята обработкой другого приложения). Аналогично момент физического присутствия на входе АЦП измеренного напряжения и момент обработки соответствующего отсчета прикладной программой мало связаны между собой. Времени наблюдаемого физического процесса соответствует последовательность отсчетов сигнала, а часы ПК лучше по возможности вывести из рассмотрения.

Ох, Александр! Хорошо написно, верно написано, и многое из предложенного мною уже реализовано, и про потоки, и про невозможность опоры на времена выдачи снятых данных от ltr, да все одно, все вышесказанное разбивается об изложенное выше весьма верное утверждение о том, что сама винда может какими-то своими делами заниматься, а на мой тред переключиться в случайный и заранее неизвестный момент времени. А это значит, что вместе с одним или несколькими уже готовыми для меня блоками данных (по 16 каналов) мне придет и начало следующего блока. И все равно нужно задумываться о буферизации таких кусков, что с таймаутами и таймерами не крути.

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

Владимир, если таймауты большие (секунды), то есть достаточно велики, чтобы их наступление можно было считать за ошибку, равно как и возврат отрицательного кода завершения, то при нормальной работе ltr27_recv(&ltr, buf, tstamp_or_null, num_words, big_enough_timeout) будет возвращать num_words.