работал с H2000, было все просто - с точностью до кванта времени системы знал время прихода данных от разных каналов. С LTR так не получается, особенно при работе разноскоростных плат  например 11-й и 27-й. 43-й платы в системе нет, меток времени от нее, соответственно тоже нет... Сама система, естественно, работает синхронно - но при чтении данных в разных потоках от разных h-плат возникает рассогласование времени прихода данных.
Пока решаю введением собственных меток времени для каждой платы, с вычислением их по частотам опроса ацп в каждом потоке и складыванием в общий буфер по этим меткам. громоздко и неудобно...
Может я пропустил в документации простой способ?

что надо получить: (пример при частоте опроса ltr11 в 4-ре раза быстрей ltr27)
старт системы
1 отсчет от ltr11
2 отсчет от ltr11
3 отсчет от ltr11
4 отсчет от ltr11 отсчет от ltr27
5 отсчет от ltr11
6 отсчет от ltr11
7 отсчет от ltr11
8 отсчет от ltr11 отсчет от ltr27
9 отсчет от ltr11
10 отсчет от ltr11
11 отсчет от ltr11
12 отсчет от ltr11 отсчет от ltr27

Василий.
1. Вы не пишете, какие именно частоты сбора нужно получить, но принципиально то, что если точно задать частоты сбора данных в известном  соотношении (например, 4:1) между модулями LTR27 и LTR11, установленными в одном и том же крейте, то и из потоков от этих модулей можно брать данные в том же самом количественном соотношении  (4:1). Систематическая ошибка времён сэмплов от разных модулей будет неизменна, поскольку синхрогенератор у них один и тот же.

2. Учесть вышеуказанную систематическую ошибку   можно либо по метке от модуля LTR43(LTR42,LTR41),
либо по аналогичной метке от крейт-контроллера LTR (но эта функция будет доступна только в новых 2,8,16-ти местных USB/Ethernet крейтах), либо в  случае нескольких модулей (LTR11 и LTR27) можно использовать по одному каналу от каждого модуля для оцифровки общего синхросигнала, поданного на модули извне.  В последнем случае достаточно начало временной шкалы каждого модуля программно привязать (один раз при запуске системы) к фронту этого синхросигнала и дальше привязка временных шкал останется неизменной (п.1) до следующего запуска системы.

задачка такая:
h11-я плата одним каналом со скоростью несколько (1-20) килогерц снимает сигнал с трансформатора тока, а десяток (возможно намного больше в будущем)термопар на h27-й плате снимают температурное поле, со скоростью 10-50 герц.
Очень важна динамика процесса, поэтому 27-я плата работает на завышенной скорости, и важна привязка сэмплов с 27-й платы к сигналу с 11-й.
желательно привязаться до единиц миллисекунд.
Исходя из пункта 2 Вашего ответа, имея 8-ми местный юсб-крейт невозможно привязать потоки к друг другу средствами системы (еще раз уточню, что 43,42,41-й платы у меня нет)?
Я в принципе решил систему привязки, просто считая микросекунды со старта по количеству отсчетов каждого ацп, но имею неопределенность порядка 100мс по старту модулей.

еще такой момент - в документации упоминается негарантированная многопоточность LTR dll , а во всех потоках вызывается функция чтения данных из одной и той же длл. пока у меня всего 2 потока (экспериментирую всего на 2-х платах), вроде как все работает (с некой времянной нестабильностью потоков относительно друг друга), а что можно ожидать дальше?

а нельзя сделать доработку фирмваре "старого" крейта для получения времянных меток?

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

Василий.
"Исходя из пункта 2 Вашего ответа, имея 8-ми местный юсб-крейт невозможно привязать потоки к друг другу средствами системы (еще раз уточню, что 43,42,41-й платы у меня нет)?"
-- Для случая LTR-U-8-1 + LTR11 + LTR27 нет возможности взаимной синхронизации штатными средствами крейта. Тот факт, что в крейте LTR синхронизация производится посредством модулей LTR43/42/41, достаточно подробно описан в Руководстве пользователя. У Вас в крейте нет свободного посадочного места для LTR43? В новом крейте LTR-EU-8-1 будет встроенный источник синхрометок.

"еще такой момент - в документации упоминается негарантированная многопоточность LTR dll..
-- дайте ссылку конкретно на пп. в документации, чтобы понятно, о чём речь...

"...вроде как все работает (с некой времянной нестабильностью потоков относительно друг друга), а что можно ожидать дальше?"
-- О какой временной нестабильности идёт речь?  Количественные характеристики?

"...а нельзя сделать доработку фирмваре "старого" крейта для получения времянных меток?"
-- Технически возможно доработать firmware и прошивки ПЛИС крейта LTR-U-8-1 и внедрить туда источник синхрометок, но организационно этой работы в планах нет.

"...или просто читать через юсб поток данных с фифо крейта, самому разбирая его по платам, имея при этом гарантированную ошибку по одновременности?"
-- Для Вашего случая основная проблема заключается в разновременности моментов старта LTR-модулей. По идее, если команды старта сбора данных для всех 8-ми LTR-модулей отсылать в крейт LTR одним пакетом (одним программным запросом), то относительная нестабильность времён старта LTR-модулей должна уменьшиться. Возможно, при низкоуровневом программировании без LTR-сервера это удасться сделать (здесь, может, программисты наши подскажут).

"еще такой момент - в документации упоминается негарантированная многопоточность LTR dll..
-- дайте ссылку конкретно на пп. в документации, чтобы понятно, о чём речь...

ltrapi.pdf (стр7 пункт 3 3-й абзац)
"Функции библиотеки, строго говоря, не обеспечивают “потокобезопасную” работу. Поэтому, во избежание недоразумений, в многопоточных приложениях пользователь должен сам организовывать, если необходимо, корректную синхронизацию вызовов интерфейсных функций в различных потоках (используя, например, критические участки, мутексы и т.д.)."

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

"...вроде как все работает (с некой времянной нестабильностью потоков относительно друг друга), а что можно ожидать дальше?"
-- О какой временной нестабильности идёт речь? Количественные характеристики?

читаю данные с двух плат - h11 и h27 одна на 2000Гц, другая на 10Гц - размер буфера минимальный LTR_Recv, для каждого потока считаю микросекунды со старта (по отсчетам ацп) и получаю "гонки" по времени прихода данных в 50-100мс между потоками.

Василий_А
Насчет потокобезопасности - имеется ввиду - что для одного и того же модуля (по слоту и по крейту, а не по типу) вызывать LTR_Recv из 2-х потоков одновременно нельзя.

Насчет низкоуровнего программирования без LTR сервера - все возможно, только сложно, так как придется разбираться еще и с низкоуровневыми интерфейсами модулей.

есть просьба (может и несовсем корректно сформированная):

реализовать в ltrapi функцию "одновременно запустить все модули"

наверное не только мне будет полезно. насколько я понял из документации, это на уровне ПО лтр-сервера совсем не сложно, в отличии от ПО клиента.

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

в общем я начал делать - потом посмотрел, например в LTR11 модуле при старте
используется как отсыл комманды, так и прием комманды, так что старт
одной коммандой на отсыл не получится.

Для этого надо переделывать все модули.

Василий. Функция "одновременно запустить все модули" для LTR-сервера оказывается слишком накладной по требуемым ресурсам (кроме того, это кардинально не решило бы проблему). Решено её не реализовывать. Если хотите решить вопрос, используйте штатный принцип синхронизации LTR-крейта -- это изначально идеологически продуманный принцип.

ну значит не судьба...

еще возможно бестолковый вопрос:
а можно сделать так:
работая с лтр-сервером, штатным образом проводится инициализация системы и запуск плат.
А чтение потока данных с плат производить со всех сразу (просто получать поток данных с фифо крейта), самостоятельно разбирая данные. если на входе получать просто 32-х битные данные (модуль+канал+данные с ацп), примерно как в h2000 системе. чем хорош такой метод - простота адаптации ПО от h2000 на новую LTR-систему одновременно с простой синхронизацией данных.

вызываем подобную LTR_Recv функцию, и получаем (без таймаута) буфер и число принятых от крейта 32бит слов (если 0, то значит ничего не пришло, иначе разбираем поток). привязка по времени получится по самому быстрому каналу.

Пример формата данных (из ltr27api.pdf)
если бы получать в таком формате данные от всех модулей с фифо крейта (да еще с буферизацией в LTR-сервере)... 

DDDDDDDD DDDDDDDD 0000MMMM 11P0SSSS
Бит расположен слева на право в порядке уменьшения номера бита.
S – номер субканала
P – бит четности
M – номер модуля в крейте
D – данные субканала

Вообще, Вы совершенно правильно понимаете, что поток групповых данных из крейта LTR (от LTR-модулей) не имеет относительных временных сдвижек между данными от разных модулей (с точностью до 1-2 мкс, если учесть индивидуальную для каждого модуля систематическую составляющую задержки выдачи данных в интерфейс), и если Вы самостоятельно программно будете поток разбирать, то это решит проблему относительной синхронизации потоков от разных модулей. Так можно поступать при работе без LTR-сервера (но это сложный путь).
А вот, можно ли из LTR-сервера вынуть для пользователя такой групповой поток данных (да ещё буферизированный самим сервером)-- это вопрос. Подождём, что ответит Maxim.

Василий_А
Да, есть такая возможность, читайте о функции
LTR_GetCrateRawData
в ltrapi.pdf.

Василий. Тогда, Вам остаётся разгребать поток данных от LTR-модулей в их чистых форматах и относительную синхронизацию Вы получите.

пример использования параллельно с модулем ltr11
void main(void)
{ int i,nslot;
  INT res,data_size;
  TLTR module;
  TLTR11 hltr11;
  DWORD data[NumRawData];
  double VoltsData[NumRawData];

  LTR_Init(&module);
  module.cc=CC_CONTROL;
  LTR_Open(&module);
  LTR11_Init(&hltr11);
  nslot=10;  //номер слота модуля 11
  res=LTR11_Open(&hltr11, SADDR_DEFAULT, SPORT_DEFAULT, "", nslot);
  if(res==LTR_OK) {
    printf("LTR11 Open OK/n");
    res=LTR11_GetConfig(&hltr11);
    if(res==LTR_OK) {
      printf("LTR11 getconfig OK/n");
      hltr11.InpMode=LTR11_INPMODE_INT;
      hltr11.LChQnt=16;
      for(i=0;i<16;i++) hltr11.LChTbl[i]=(BYTE)i;
      hltr11.ADCMode=LTR11_ADCMODE_ACQ;
      hltr11.ADCRate.divider=36;
      hltr11.ADCRate.prescaler=8;
      res=LTR11_SetADC(&hltr11);
      if(res==LTR_OK) {
        printf("LTR11 setadc OK/n");
        LTR11_Start(&hltr11);
      }
    }
  }
  while(!kbhit()) { // принимаем и отображаем
    LTR_GetCrateRawData(&module, data,NULL,NumRawData,1000);
    data_size=NumRawData;
    res=LTR11_ProcessData(&hltr11, data, VoltsData, &data_size, TRUE, TRUE);
    if(res==0) printf(" res=%00004d %10.4f %10.4f %10.4f/n",res,VoltsData[0],VoltsData[1],VoltsData[2]);
  }
  LTR11_Stop(&hltr11);
  LTR11_Close(&hltr11);
  LTR_Close(&module);
  printf(" fin programm");
return;
}

Спасибо за внимание к проблеме!

в ltrapi.pdf из <<ltr_sw.zip 7,333,144 07.05.08 Крейтовая система LTR. Руководство программиста.>> к сожелению, LTR_GetCrateRawData не упоминается (а в библиотеке ltrapi действительно присутствует, жаль раньше не разглядел). может есть обновленный вариант документации?

насколько видно из примера, LTR_GetCrateRawData сходна с LTR_Recv, и хотелось бы получить разъяснения по таким моментам:
как связаны timeout и результат функции?

на мой взгляд, самый логичный вариант - это при задании timeout=0 в качестве результата получать количество валидных слов в буфере (максимум - размер буфера, минимум - ноль, то есть ничего пока не пришло).

P.S. жаль, что USB-система не может работать точным системным таймером, как hi8 в H2000

"жаль, что USB-система не может работать точным системным таймером, как hi8 в H2000 "

USB- и тем более Ethernet-система принципиально должна  иметь более глубокую буферизацию по сравнению с PCI, поэтому и идеология синхронизации в LTR совсем другая...

Василий_А
tiemout - время в течении которого ждутся данные, разумеется для этого нужно себе представлять поток данных и в соответствии с этим настраивать размер буфера и таймаут.
Запрашивать размер - некорректно - так как в общем случае необходимо как можно быстрее считать данные из буфера сервера, во избежание его переполнения, то есть функция LTR_GetCrateRawData должна крутиться по хорошему в отдельном потоке, постоянно считывая данные с сервера.
новое описание :
ftp://lcard.ru/pub/ltr/ltrapi.zip

Спасибо за документацию!

очень важный момент (в описании  LTR_GetCrateRawData ):
<<size – количество отсчетов которое следует принять от крейта, не более.>>

в описании LTR_Recv "не более" не фигурирует...

Василий_А
да, недоработка вышла.
Подправил документацию, качать там же
ftp://lcard.ru/pub/ltr/ltrapi.zip
и новую версию сервера :
ftp://lcard.ru/pub/ltr/ltrserver_1_4_5_20.exe

РАБОТАЮ БЕЗ SERVER НИКАКИХ ПРОБЛЕМ НЕТ .ПОЛУЧАЮ ВЕСЬ ПОТОК В ПОРЯДКЕ ОПРОСА КОНТРОЛЕРОМ КРЕЙТА ЭТО НЕ НЕСЛОЖНО ,ЕСЛИ КРЕЙТОВ НЕСКОЛЬКО СИНХРОНИЗИРУЮ СИСТЕМОЙ ЕДИНОГО ВРЕМЕНИ С ТОЧНОСТЬЮ ДО МИЛЛИСЕКУНДЫ, ЧЕРЕЗ 43 МОДУЛЬ

ПРАВДА КОНТРОЛЕР К СОЖЕЛЕНИЮ  ПЕРИОДИЧЕСКИ ДАЕТ ЗАДЕРЖКИ ДО 15 МСЕК. ЧЕМ ОН ЗАНЯТ НЕ ПОЙМУ .

Sergey2. Если желаете разобраться, напишите подробнее, о какой именно задержке идёт речь и как Вы её контролируете. Укажите также состав оборудования полностью и на какие скорости сбора данных настроены LTR-модули.

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