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

Вы имеете в виду 3906.25 отсчетов в секунду на канал при частоте дискретизации 31250 Гц?
Вопрос непонятен. В потоковом режиме посылаться должно столько данных, сколько выводится (каждый отсчет), т.е. уменьшить поток, очевидно, нельзя. Подкачка контролируется LTR-сервером, см. параграф 6.2 описания ltr34api.pdf

Можно попытаться сократить размер буфера до 0,5-0,25сек , зависит от быстродействия системы. Но не стоит увлекаться, под Windows система может отвлечся и неуспеть передать данные в модуль.
Самый точный метод: работать в режиме потока с подтверждением каждого слова.
Предварительно, до старта, загрузить в модуль 2 буфера. Далее после запуска, принимать от модуля данные, как только вернёться 1-й буфер - отправлять 3-й, после прихода 2-го отправлять 4-й, и.т.д. Тогда модуль будет работать под контролем и небудет перекачки модуля.
Так-же, если сигнал, который вы выводите меняет значение лиш иногда, с одного постоянного значения на другое, можно работать с модулем в режиме "голодания", т.е. не подкачивать в него данные а только иногда сбрасывать новое значение.

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

спасибо за ответ.

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

Иван. Аппаратно в LTR34 реализован, в том числе, специальный  вариант потокового режима, при котором копия  каждого отсчёта, физически отправленного в ЦАП, отправляется также назад в качестве подтверждения выдачи. Кроме того, в этой возвращённой копии присутствуют также признаки статуса буфера full-empty для фиксации факта переполнения/опустошения, если такое событие случалось. Такой режим даёт полный контроль над отправленными данными, но требует дополнительного трафика на приём данных. Но, так или иначе, передающий и приёмный каналы ЦАП, имеют глубокие буфера поэтому, как Вы пишете, "понять когда действительно ушел на плату мой буфер" можно, но с точностью до большой конвейерной задержки между принятыми и отправленными данными.

Если я вас правельно понял вы говорите про функцию LTR_Recv  а конкретно про масив tmark   как рашифровываются даные из это го масива??

Нет, tmark это массив меток времени, в нём содержеться значение счётчиков меток "старт" и "стоп" на момент отправки модулем отчёта.
Для контроля LTR34 нужно использовать режим с подтверждением каждого слова. Однако узнаете вы о выдаче того или иного отчёта с задеркой по времени, так как отчёт сначало попадает в буфур крейта, потом в буфер сервера, и лиш потом принимаеться коммандой recv.
Чтобы снизить эту задерку нужно уменьшать размер передаваемого и принимаемого буфера, но их нельзя делать слишком короткими по времени, нужно учитывать врема реакции windows и время прохождения через буфер сервера и крейта.

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

Данные, т.е. те-же отчёты что вы посылали в LTR34 будут в массиве data приниматься коммандой recv.
т.е. если вы послали какой-то сигнал, то он потом и вернёться вам, в том же виде.

Для получения более точного времени отправки можно запустить параллельно выдаче отчётов генерацию секундных меток (c помощью LTR43, LTR41, LTR42 синхровозможностей крейтов LTR-EU, LTR-U-1), тогда анализируя принятые обратно данные вместе с массивом tmark вы сможете точно понять (с точностью до частоты дискретизации LTR34) в какое время ушёл тот или иной отчёт. Т.е. счётчик секундных меток будет меняться раз в 1с а в массиве tmark будут значения этих меток для каждого из отправленных отчётов.

Да, такая привязка к шкале времени по секундным меткам обратного потока данных от LTR34 вполне возможна. Фактически это означает, что мы постфактум на верхнем уровне узнаем, когда именно по времени был выдан каждый отсчёт ЦАП.

направте тогда пожалуйста на синхро возможности  ltr eu

Синхровозможности крейт-контроллеров LTR-EU аналогичны LTR41/42/43. Функционально эти возможности заложены, в настоящее время они тестируются.

Иван, какой конкретно у вас крейт (модель, ревизия)?

LTR EU-2-5

Иван, тестировать заканчиваем. Завтра или в понедельник, скорее всего, выложим обновление ПО и прошивок для всех LTR-EU, позволяющее использовать синхронизацию самого крейта.

Иван. Обновление выложено.
http://www.lcard.ru/forumthreads/8166  Буду рад, если сообщите о своих результатах.

Будет ли реализована возможность единовременой выдачи напряжения как это зделано в цапе е14-440
я имею в виду функцию DAC_SAMPLE.

Oleg, технически реализовать асинхронный режим выдачи напряжения одновременно на все каналы LTR34 вполне возможно путём изменения прошивки ПЛИС LTR34 и внедрения соответствующих возможностей на уровне API-библиотечных функций. Попробуйте переговорить с нашим офисом, возможно, эту работу включат в план... С другой стороны, если требуется параллельная выдача данных, то можно использовать и штатный синхронный потоковый режим, например, с установленной малой частотой выдачи на ЦАП для экономии трафика.

Олег, обратите внимание на ответы от 13.10.09 - может быть, Вас устроит описанный там режим?

Здравствуйте хотелось бы узнать невключен ли в план добавление функции единовременого вывода.
Насчет режима голодания  насколко малым может быть буфер передачи в потоковом режиме? и насколько быстро модуль сможет вывести значение.

Олег. В план пока это не включено.
На сколько малым может быть буфер передачи в потоковом режиме? - Если подразумевается буфер LTR34, то это зависит от равномерности подкачки. Например, если подкачивает Blackfin крейт-контроллера LTR-EU, то (если написать такое ПО для Blackfin) можно задастся целью заставить Blackfin на столько равномерно подкачивать данные, что в буфере LTR34 держать буквально  3-4 сэмпла данных, но только  если LTR34 использовать в режиме подтверждения выдачи каждого слова данных на выход ЦАП.

Собственно, с любым модулем LTR крейт-контроллер LTR-EU имеет ресурс работать на порядки более оперативно, чем через Host-комптьютер, если заточить ПО Blackfin под эту задачу. 

Практически, то, что есть сейчас: если  подкачивает Windows через USB (Ethernet) с использованием LTR-сервера, то равномерности подкачки ожидать не приходится (зависит от загрузки компьютера, от трафика через LTR), поэтому стратегия подкачки LTR-сервера - "качать пока в буфере LTR34 есть место".

Олег, я так понял, что Вы спрашивали про минимальный объём буфера для сохранения синхронности вывода.
Но "режимом голодания" я называл ранее режим полностью опустошенного буфера ЦАП, когда принимаемый LTR34 сэмпл сразу попадает на выход ЦАП. Если программировать этот режим на Blackfin, то задержка передачи данных от Blackfin на выдачу в LTR34 cоставит единицы микросекунд. Если то же под Windows, то задержка будет асинхронная и плохо детерминированная (грубо - десятки миллисекунд).