Использовал пример для управлением LTR11 в среде LabView, следующая проблема. Создаю exe,  ПК на котором создавался exe все работает, идет сбор данных и т. д., а если перенести на другой ПК предварительно установив туда LabVIEW_Runtime_Engine_2011 и ltr server, приложение запускается, ltr server подключается без проблем, но крейта программа не видит, подсоединяется все через ethernet. Думал проблема в антивирусах и т. д., но lgraph видит крейт , в чем может быть проблема?

Несколько вопросов, чтобы прояснить ситуацию:

1. ltrdll из http://www.lcard.ru/download/ltr_binary.zip на новом ПК Вы устанавили? ltrModulesNet.dll тоже перенесли на новый ПК?

2. Что за ОС на другом ПК?

3. Никакие исключительные ситуации (сообщения об ошибках) при запуске Вашей программы не возникают?

4. Под не видит крейт подразумевается что LTR11_Open возвращает ошибку? Или Вы в своей программе получаете список серийных номеров крейта и он пустой?

1.Когда создается ехе, ltrModulesNet.dll автоматически переносится в папку data
2.в обоих случаях win xp, пробывал на win7 таже история
3.Ошибок не возникает
4. LTR11_Open вызывает ошибку error_open_chanell
Такое ощущение, что при переносе на другой компьтер, программа не видет ltrModulesNet.dll использует старую директорию.

А Если в LTR-Server/'е поставить самый выский уровень отладки (Настройки -> Уровень журнала -> (7) Отладочные 3), то при запуске Вашей программы (когда LTR11_Open возвращает ошибку) в журнале сервера новые записи появляются?

не появляются

Странно. Значит до сервера дело не доходит.

Тогда просьба еще раз проверить:
1. Что установлены успешно ltrdll - в Windows/system32 есть файлы ltr11api.dll, ltrapi.dll?
2. Установлен .Net Framework 2 (установщик есть в частности на L-CDROM в LTR/RETISTR)

Сейчас проверил с 2012 LavView, при установленном вышеперичисленном все заработало на XP без самой среды.

И еще - точно LTR11_Open возвращает error_open_chanel, а не это значение просто было выставлено на индикаторе при создании exe и так и осталось значением по-умолчанию?

LTR11_Open  действительно, был в значение по умолчанию и значение не менялось, отсутствовал фаил 11api.dll, заработало, но как то странно, некоторые модули в процессе отваливаются, пишут что переполнен буффер

А можно поподробнее - кто и где пишет, что переполнен буфер?

Как часто это происходит? С одними и теми же модулями?  Вы работаете с несколькими модулями LTR11 параллельно?
На изначальном ПК со средой подобного не было?

ltrserver
2.08.12 15:11:54.353] (2) CLIENT_READ: RCT.0005 Rx buffer overflow
[22.08.12 15:11:54.385] (2) CLIENT_READ: RCT.0003 Rx buffer overflow
[22.08.12 15:11:54.416] (2) CLIENT_READ: RCT.0001 Rx buffer overflow
[22.08.12 15:11:54.650] (2) CLIENT_READ: RCT.0002 Rx buffer overflow
[22.08.12 15:11:54.666] (2) CLIENT_READ: RCT.0004 Rx buffer overflow
[22.08.12 15:11:59.572] (2) CLIENT_READ: RCT.0003 Rx buffer overflow
[22.08.12 15:12:00.056] (2) CLIENT_READ: RCT.0001 Rx buffer overflow
[22.08.12 15:12:00.291] (2) CLIENT_READ: RCT.0005 Rx buffer overflow
[22.08.12 15:12:00.556] (2) CLIENT_READ: RCT.0002 Rx buffer overflow
[22.08.12 15:12:00.603] (2) CLIENT_READ: RCT.0004 Rx buffer overflow
[22.08.12 15:12:04.322] (2) CLIENT_READ: RCT.0003 Rx buffer overflow
[22.08.12 15:12:05.666] (2) CLIENT_READ: RCT.0001 Rx buffer overflow
[22.08.12 15:12:05.681] (2) CLIENT_READ: RCT.0004 Rx buffer overflow
[22.08.12 15:12:05.884] (2) CLIENT_READ: RCT.0005 Rx buffer overflow
[22.08.12 15:12:05.931] (2) CLIENT_READ: RCT.0002 Rx buffer overflow

Еще на lgraph было замечено, если достаточно долгая запись идет, то иногда в процессе записи отваливаютлись модули, обычно это происходило, если вдруг начал работать антивирус или просто винда задумывалась, а иногда и просто так, модули отваливаются разные, но чаще слот №3, переставляли местами, одна и так же история . Работаем с 5 модулями одновременно, задействовано по 4 канала в каждом. Fd=100кГц на канал.
Попробывали написать на labview програмку, которая заточена только на запись и никаких других функций в себя не включала.После долгих мучений нормально заработала,сейчас на "изначальном ПК" работают все 8 модулей одновременно, проблемы возникают, но очень редко, а если на этом же ПК запускать lgraph максимально получалось использовать 6 модулей.

Fd=100кГц на канал - то есть частота сбора данных для АЦП -  400кГЦ (максимальная скорость LTR11), или 100кГц это и имеется в виду частота АЦП?

На новом ПК lgraph2 работает так же как на предыдущем или с еще меньшим количеством модулей? И с меньшим числом модулей Ваша программа работает нормально на новом ПК?

У Вас одна программа LabView работает сразу с 8-ю модулями, правильно? Если да, то как сделан цикл сбора данных? Если сделан общий цикл на все модули, то лучше на каждый модуль для сбора делать отдельный независимый цикл.

1. Частота АЦП, 4 канала по 100кГц
2.На разныз ПК разная ситуация, но общая тенденция прослеживается, чем хуже процессор тем меньше каналов можно использывать
3.По мере надобности можно отключать модули. Сделано в одном цикле, пробывал в разных циклах, но возникла некоторая проблема, конечный размер записаных фалов не совпадает у 1-2х модулей, старт начинается по внешнему сигналу. Остановлся на структуре: задаются настройки модулей->определяются модули, пауза 250мс и затем уже начинается сбор данных в одном цикле. А почему не рекомендуется использовать общий цикл?

Максим, при такой нагрузке просто физически не должно хватать скорости интерфейса:
8 модулей x 400 кГц x 4 байта/отсчет = 12.2 МБайт/с ~= 100 Мбит/с (физический Ethernet без учета накладных расходов). В описании LTR-EU заявлена скорость 10 МБайт/с по этому интерфейсу (и 16 по USB).

Во-вторых, есть смысл посмотреть, что происходит на компьютере: сколько процентов CPU кушает ltrserver и сколько Ваше приложение (по task manager). При большом потоке данных производительность компьютера тоже играет роль.

Думается, что экстремальные потоки данных можно попробовать обрабатывать, подключая несколько крейтов по отдельным интерфейсам (не в один 100-Мбитный сегмент ethernet) к очень быстрой и многоядерной машине. Или соединить две машины гигабитным интерфейсом - на одной ltrserver, на другой приложение (??).

Кушает приблизительно: приложение 20-25% и ltr сервер 10-15% при записи с 6 модулей, завтра проверю, действительно ли работают 8 модулей.
    Когда несколько крейтов это начнутся вопросы с синхронизацией и т.д. + довольно габаритно, в стационарном режиме не проблема, а где-нибудь на объкте... не подходит.
    Так почему не рекомендуется использовать общий цикл?

Вроде бы если передается в кодах АЦП,то 2 байта/отсчет ?? в чем смысл передедавать коды АЦП в process data в формате dbl, там же нет функции перевода в вольты?

В LTR формат - 4 байта на отсчёт для модуля LTR11.
Это внутренний формат LTR, содержащий, кроме данных, ещё индексную часть. См.Руководство пользователя, п.4.5

Почему не рекомендуется общий цикл, я сейчас сказать не могу, тут нужен специалист по labview, а его сейчас нет. Вообще labview - штука сложная и тяжелая (я смотрю, нагрузка от приложения в 2 раза больше, чем от ltrserver, а сервер - нельзя сказать, что очень легкое приложение...)

Кстати, сколько процессорных ядер на машине?

Сам ltrserver весьма многопоточный, и каждый модуль имеет свои буферы и свои потоки чтения/записи. Клиентское приложение соединяется через TCP сокеты по сути с разными потоками в ltrserver. Сокетный ввод/вывод должен буферизироваться ОС, и по идее должно быть возможно как параллельное, так и последовательное чтение данных. Видимо, в одном случае накладные расходы оказываются меньше (во время ожидания одного потока второй может обмениваться данными??)

А написание программы на C/C++ не рассматривается совсем? Нагрузка очень уж большая. Я бы на Вашем месте попробовал сделать тест и сравнить производительность.

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

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

При одном цикле нагрузка на процессор сокращается проверял и легче добится синхронизации, чем городить сложные структуры. При разных циклах добиться синхронизации сложнее и нагрузка на процессор возрастает.
Если сравнивать lgraph  и приложение на labview, то по производительности labview выше,т.к. нагрузка приблизительно одинаковая на процессор( и модули не отваливаются=)), но у меня каждый канал пишется в отдельный фаил, а в lgraph модуль в отдельный фаил.Если делать в labview - модуль в отдельный фаил, думаю нагрузка сократится.Что бы не было старта в разные моменты времени и была использована Timed Structures, в среднем инициализация модулей занимает порядка 100-150ms была введена задержа перед началом старта. Функция close выполнятся для разных модулей по разному, из-за чего и получаются различные размеры файлов, нужно было вводить локальные переменные и т.д.,много лишнего.
C/C++ не пробывал, графическое програмирование нагляднее для инженера=)
ноутбук средненький проц intel core 2 duo 2.26GHz 3Gb памяти

Тут есть еще пути для экспериментов: например, выключить запись на диск и посмотреть, что это дает в плане производительности.

Синхронизацию старта можно делать аппаратную, кстати. По стартовой метке.

При выключенной записи 7-10% загружает labview, просто vi  без exe файла, много сжирает многопоточная запись. По стартовой метке можно реализовать в labview?

Можно поэкспериментировать с Timing VIs, что бы по мах разгрузить процессор,но принципе, текущая загрузка процессора не столь критична, параллельно никакие приложения не включаются

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