Подскажите, пожалуйста, в чем может быть дело.
В крейте LTR-EU-2 установлено 2 модуля LTR27, заполненных субмодулями H27. LTR-сервер распознает оба модуля. Программа считывания основана на прилагаемом Вами примере ltr27_V8.vi. Конструкция примера удвоена (во втором экземпляре изменен логический номер модуля) и расширена на считывание со всех субмодулей. Регистрация сигналов с модуля, указанного первым, происходит без вопросов, но с указанного вторым – со значительной задержкой. Варьируя значениями делителя частоты дискретизации и частотой выполнения цикла опроса в Лабвью удается добиться минимальной задержки регистрации изменения сигнала около 5 сек. Но все равно это много.
Вероятно причина – в написанной на Лабвью программе. Хотя опрос обоих модулей LTR27 происходит внутри одного цикла, задержка отмечается только для того модуля, который в программе (а не в крейте) записан нижестоящим. Если же для обоих модулей использовать один constructor Node, то, хотя описания мезонинов в модулях дается правильное, сигналы считываются только с модуля, указанного первым.
Как можно уменьшить время задержки считывания сигнала со второго модуля?

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

По labview сходу не скажу, но, может быть, там сделан большой размер буфера чтения, и он долго заполняется?
Кстати, что Вы понимаете под <<задержкой регистрации изменения сигнала>> - реальное время между физическим событием и реакцией программы на компьютере? Это в принципе не очень корректное понятие - ПК не является системой реального времени.
(см. также
http://www.lcard.ru/forumthreads/10844
http://www.lcard.ru/forumthreads/10420 )

А если говорить на уровне LTRAPI (для C/C++), то
вообще LTR передает данные общим потоком, т.е. как бы параллельно со всех модулей, LTRserver их принимает и раскладывает по отдельным буферам, а приложение соединяется с конкретным модулем через TCP сокет и оттуда читает данные. Если читать небольшими порциями (с маленьким размером буфера или с маленьким таймаутом в LTR_Recv), то работа программы будет более, так сказать, синхроноподобна По-моему, что-то похожее сделано в LGraph2. Также можно сделать многопоточное приложение и читать в каждом потоке свой сокет.

Под реальную задачу, видимо, пример надо переработать и несколько усложнить. Под labview, насколько я понимаю, импортируется обертка LTRAPI в C#, т.е. интерфейс в конечном счете тот же.

Под "задержкой регистрации изменения сигнала" подразумеваю время от момента изменения  сигнала (например подачи сигнала от батарейки на вход АЦП) до момента отображения этого изменения на экране компьютера.
Если бы роль была в большом размере буфера чтения, то наверное, задержка была бы и в чтении данных и с первого модуля, однако этого нет.
Поскольку я не С/С##-программист, похоже придется пользоваться в основном одним модулем, поставив наименее важные датчики на второй.

Проблема в том, что сложно сказать, в чем проблема, не зная точно, как устроена Ваша программа.   Каждый модуль LTR в LabView – свой по сути независимый объект, поэтому constructor Node для каждого действительно должен быть свой и процесс установки настроек и цепочка вызова функций – свои. Т.е.  по сути сбор может осуществляться в совершенно независимых ветвях программы, и тогда кто выше, а кто ниже никак не должно влиять. У Вас же получается, что как-то сделана зависимость «нижнего» модуля от «верхнего»?

Что такое «частота выполнения цикла опроса» и как она задается? Чтение в примере с сайта цикл выполняется постоянно.

И неплохо было бы конкретный пример: частота дискретизации такая-то, частота выполнения цикла опроса  такая-то, size и timeout у ReadData такие-то,  задержка получилась такая-то.

Удалось получить примерно одинаково быстрый ответ с обоих модулей таким путем: частота дискретизации у "верхнего" модуля должна быть меньше, чем у "нижнего", например, 0 и 9. Если частота дискретизации у обоих модулей одинакова - возникает задержка у "нижнего" модуля.
Все остальные параметры (кроме логического номера второго модуля)- точно такие же как в вашем примере. А «частота выполнения цикла опроса» это просто таймер, установленный внутри цикла While Loop из вашего примера.

Странно... А можете этот измененный пример прислать мне на почту?

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

Алексей, мне кажется, что у Вас просто получается последовательный (поочередный) опрос большими порциями. Данные, собранные модулем A, ждут своей очереди, пока читается модуль B (полярник написал письмо на материк, но опоздал: почтовый самолет улетел 5 минут назад. Теперь почту заберет только следующим рейсом).
Если я правильно понял проблему, то, как и говорил, принципиальных решения у нее два: уменьшать время, уделяемое при чтении каждому модулю (через таймаут или через размер порции данных), либо читать параллельно в несколько потоков (если для labview это возможно).

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

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

А если убрать таймер опроса и сделать по циклу отдельно для каждого модуля, а не общий – задержка останется?

P.S.: Вообще таймер опроса не нужен. Из блока Recv мы выходим только если примем нужное количество отсчетов (size) или по таймауту (поле timeout в мс), ну или по ошибке. Т.е. если мы постоянно вызываем Recv, то мы принимаем данные со скоростью, с которой их вырабатывает модуль (что определяется частотой дискретизации), что в общем то и нужно при непрерывном сборе. Таким образом, если таймер опроса срабатывает раньше, чем успеваем выполнить Recv, то он ни на что не влияет, а если позже, то будет задержка между Recv, что приведет к тому, что мы будем читать данные медленнее чем их передает модуль, что приведет к запаздыванию данных.

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