В крейте утановлены:
- Одна плата LC-111 для измерения 16-ти напряжений в переделах 10 вольт
- Четыре LC-104 для измерения 32 сопротивлений в пределах 100 ом на АЦП LC-301

Датчики удалены от крейта на 50-100 метров, есть помехи.

Использую сихронный ввод последовательно для LC-111 и LC-301 - функции для каждой серии:
FORCE_INTER_DELAY_CC(...)
SOFT_CONFIG_CC(...)
SOFT_START_CC(...)
GET_NWORDS_CC(...)
GET_SOFT_DATA_CC(...)
SOFT_STOP_CC(...)

Измерения проводятся циклически следующими сериями в каждом цикле (см. пример ниже):
1. короткая серия 104 для коммутации источников тока на каналы измерения сопротивлений (сами измерения проводятся далее (см. п.3)) - запрос на однократное измерение четырех однономерных 104-каналов на разных 104-платах
2. серия измерения напряжений на каналах 111 -
запрос на измерение 16-ти каналов с межканальной
задержкой 40 мкс. в течении 16 мс. (около 25-ти измерений для кажного канала за это время)
3. серия измерение сопротивлений на каналах 104 -
запрос на измерение 4-х каналов (однономерные каналы на 4-х разных платах LC-104) c межканальной задержкой 200 мкс. в течении 240 мс. (около 300 значений для каждого канала, которые потом усредняются/фильтруются для подавления помех).

Проблемы:
1. Через несколько циклов (около 150 серий шагов 1-3) крейт перестает работать - дает ошибку тайм-аут в функции GetData.
2. Данные полученые при измерении каждой серии 104-каналов (4 канала по 300 значений) очень похожи друг на друга. Такое впечатление, что измеряется не четыре канала на разных платах LC-104, а один.

Вопросы:
1. Почему возникает тайм-аут?
2. Может крейт не успевать переключать каналы с четырех разных плат LC-104 на АЦП LC-301 за 200 мкс.?

Пример измерений:

short ch104[2*4] = { slot104_1, ch0, slot104_2, ch0, slot104_3, ch0, slot104_4, ch0 };
...
for(...) {
  // 1
  FORCE_INTER_DELAY_CC(2000)
  SOFT_CONFIG_CC(slot301,4,ch104,4*200+1)
  SOFT_START_CC()
  GET_NWORDS_CC(...) // жду 4 измерения
  SOFT_STOP_CC() // результаты не нужны - нужна коммутация источника тока на каналы ch0

  // 2
  FORCE_INTER_DELAY_CC(400)
  SOFT_CONFIG_CC(-1,16,ch111,16*40+1)
  SOFT_START_CC()
  GET_NWORDS_CC(...) // жду 16*25 измерений
  GET_SOFT_DATA_CC(...) // получаю их
  SOFT_STOP_CC() //

  // 3
  FORCE_INTER_DELAY_CC(2000)
  SOFT_CONFIG_CC(slot301,4,ch104,4*200+1)
  SOFT_START_CC()
  GET_NWORDS_CC(...) // жду 300*4 измерения c каналов ch0 на разных 104-платах
  GET_SOFT_DATA_CC(...) // получаю их
  SOFT_STOP_CC() //

  // обработка результатов
  // изменение номера канала LC-104 ch0 (ch0++; ch &= 7;)
  // новый шаг цикла
...
} // конец цикла

Вадим.

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

Какого рода помеха?

2. В принципе и этого времени может не хватать для нормальной работы коммутатора АЦП на длинных линиях- здесь нужно экспериментально подобрать рабочее значение межканальной задержки и Rate. Сам по себе крейт успевает переключать и большую частоту. Но, может быть, вы забываете менять содержимое массива ch104, когда ch0++; ch&=7; ?

Непонятно, зачем нужен п.1 - коммутация источников тока?
И второе, как измеряется значение резистора, если вы неправильно задаете логический канал: см. описание SAMPLE_LC301 и CREATE_CHANNEL_LC104.

Извиняюсь, в последнем замечнии я сам ошибся. Канал вы задаете правильно, если это 4-х проводная схема подключения.

по поводу коммутации источников тока:

хотелось как можно чаще (20 мкс.) в течении 5-ти
периодов промышленной частоты (примерно 100 мс.)
опрашивать температурные датчики с тем, чтобы
потом их усреднить/отфильтровать,
ликвидировав влияние помехи.
Для того чтобы избежать переходных процессов сразу
после коммутации источника тока - коммутация
делается заблаговременно и в течении опроса
источники тока на каждой плате не коммутируются.
Т.е. на каждый 104-ый модуль приходит измеряемое напряжения+помеха-переходные процессы. Коммутация
каналов происходит только на шине крейта при доступе к модулю 301.
У меня сложилось впечатление, что коммутация 301-модуля к каждому каналу на разных 104-модулях не может быть чаще чем 300-200 мкс. Так ли это?

С чем может быть связан timeout getdata?
Он присходит на функции SOFT_CONFIG_CC,
используемой на третьем шаге.

И еще вопрос по поводу timeout getdata.
Как ликвидировать эту ошибку. Программная
перегрузка крейта не помогает - дает ошибку 2
(невозможно загрузить крейт-модуль lc-010 для связи с РС) из-за вновь возникающих timeout.

Проверьте все-таки следующее:

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

Какого рода помеха?

Да, и еще: для LC-111 Rate попробуйте увеличить, например:
SOFT_CONFIG_CC(-1, 16, ch111, 16*100);
А что, ->

"Он присходит на функции SOFT_CONFIG_CC, "

-> это всегда так?

Помеха частотой 100 Гц, среднее отклонение показателей около 2%, максимальное отклонение
около 15-20%.
При межканальной задержке 200 мкс. коммутация
каналов на шине крейта приводит к неправильным
показаниям.
При межканальной задержке 300 мкс. показания
правильные.

Как бороться с timeout. Из-за чего он может
появляться? Как его преодалевать?

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

межканальную задержку для 111 увеличу. Результаты
сообщу завтра после прогона.

Результаты прогона сегодня:
межканальная задержка для 104 = 250 мкс. (Rate=n104*250+1) - показания датчиков правильные
межканальная задержка для 111 = 80 мкс. (rate=n111*80+1) - показания датчиков не правильные (все показывают одно и то же число)

таймаут getdata на том же месте. Как его программно преодалевать? Я уже писал что перегрузка bios не помогает.

Так Вы пробовали без кабелей? TimeOut может быть связан с тем, что помеха мешает нормальной работе контроллера и пр. устройств.
Для LC-111 имелось в виду: FORCE_INTER_DELAY_CC(40), а SOFT_CONFIG_CC(..., 16*100) для 16-ти каналов.

Данные новых прогонов:

1. если межканальная задержка для 104 - 250 мкс,
период опроса 4*250, а период опроса 111 -
16*100, программа работает нормально, показания
правильные

2. если значения задержек уменьшается, то
показания правильные, но программа завершается
по timeout. С отключенными проводами тоже самое.

Вопросы:
1. Какие все-таки есть критерии выбора задержек?
С чем связан совет для 111-каналов использовать
период опроса 16*100? Можно меньше?

2. Как преодалевать timeout?

3. Где взять исходники для lcard32_vc4.dll?
Если можно пришлите их по почте.

1. Для 111 межканальная задержка Delay не должна быть меньше 4 мкс.
Rate при этом должен быть > N_каналов*Delay. По сути,
контроллер помимо сбора данных должен откачивать их в PC.
Это определяет Rate. Под Windows все медленнее, - этим объясняется значение, которое
Вам было указано. Под DOS можно и меньше, чем 100 мкс.
2. Задержки здесь не при чем - важно соотношение Delay/Rate - см. п.1
Timeout возможно из-за этого. По хорошему, его быть не должно (у вас же есть вариант, когда все работает).
3. Пишите на lcard@lcard.ru

А где работа FIFO?
Я считал, что оно накачивается со скоростью оцифровки (delay, rate), а скорость откачки
зависит от возможностей компьютера и самое
плохое, что может происходить - переполнение
FIFO.
Почему происходят timeout getdata - по сути
дела зависания крейта (не отклик за запрос)?

В SOFT_CC используется протокол с посылками запросов в контроллер. Они медленно работают в сторону от PC->DSP, в силу аппаратных особенностей.
FIFO используется контроллером для распараллеливания сбора данных и выдачи их в PC. Такая малая скорость - из-за сочетания 111 и Windows.
Есть другой класс функций - см. GET_FAST_SOFT_DATA.