Форум: Техническая поддержка

П.4.6,  ltrapi.PDF:
Биты 31-16    Количество меток "СТАРТ", возникших до прихода  соответствующего слова в крейт
Биты 15-0     Количество меток "СЕКУНДА", возникших до прихода  соответствующего слова в крейт
1) Биты 15-0 с числом меток "СЕКУНДА" заполняются циклически (после 0xFFFF следует 0x0000)?
2) Метка "СЕКУНДА" отмечает импульсы синхронизации  (при 25Гц интервал 0.04с)?
3) При пропуске кадра соответствующие значения в битах 15-0 отсутствуюет в принимаемых 32-битных метках?
#
Вопросы про массивы data[] и tmark[] в функциях получения данных:
Каждый крейт у нас (4 крейта LTR-EU-8-1) содержит модули LTR114 и LTR212M-3. Все крейты между собой синхронизированы. Модули LTR212M-3 работают
в 4-канальном режиме повышенной точности.
Судя по описанию, оцифровка измерения в этом режиме будет происходить с частотой около 150Гц.
4) Временные метки tmark[] для модулей разных типов будут следовать с одинаковым интервалом (0.04с при частоте 25Гц) или на LTR212M-3  будет интервал около 1/150 с?
5) Если первый вариант, какое значение попадет в массив data[] на LTR212M-3? (он же выдаст 6 значений на 0.04с)
#
Для формирования нашей временной метки (астрономические время-дата) можем зафиксировать астрономическое время-дату формирования команды  "СТАРТ" и прибавлять по 0.04с на каждую единицу метки "СЕКУНДА" (если они приходят с интервалом 0.04с).
6) Если команду остановки и старта на ведущий крейт будем подавать с некоторой периодичностью (скажем, 1сек или 1мин).
Такой режим возможен и какой объем данных мы потяряем при перезапуске для модулей LTR114 и LTR212M-3?

1) Да, циклически
2) Если подать внешнюю частоту 25 Гц на один из DIGIN разъема синхронизации крейта и настроить метки секунда по фронту/спаду этого сигнала, то тогда да, можно получить метки с интервалом 0.04 с. Для внутренней генерации самим крейтом без внешней частоты поддерживается только генерация с частотой 1 Гц (1 с).
3-5) Не совсем понял, что имеется ввиду под "пропуском кадра".
При вызове Recv значений tmark принимается ровно столько же, сколько принято и самих исходных слов от LTR с отсчетами (т.к. число действительных значений tmark равно числу действительных значений в массиве 32-битных слов LTR и равно возвращенному значению функцией Recv). Каждое значение tmark содержит счетчик количества меток от включения крейта на момент приема крейтом от модуля соответствующего слова.
Т.е. если у Вас частота генерации меток 25 Гц, а частота сбора 150 Гц, то у Вас прием значений tmark будет также с частотой 150 Гц, при этом значения будут повторяться по 6 раз. По номерам отсчетов tmark, где произошло изменение значения tmark, Вы и понимаете между какими отсчетами реально произошла генерация метки. Т.е условно у Вас первые 3 слова tmark имели значение k, следующие шесть - k+1, и т.д., т.е. у Вас момент первой метки соответствует времени между 3 и 4 словом LTR, следующей между 9 и 10 и т.д.
Также нужно учитывать, что для модулей с 24-битным АЦП, как LTR212, один отсчет передается не одним словом LTR, а двумя (поэтому после ProcessData отсчетов на выходе в два раза меньше, чем принято слов в Recv), соответственно и слов tmark будет в 2 раза больше. Кроме того, в модуле LTR212 каналы АЦП измеряют параллельно (в 4-х канальном режиме), т.е. измерения со всех 4-х каналов выполняется одновременно и с частотой 150 Гц будет выполняться по одному измерению на каждый разрешенный канал и приходить количество отсчетов, соответствующее числу разрешенных каналов. Если разрешено 4 канала, то с частотой 150 Гц у Вас будет приходить 4 отсчета или 8 32-битных слов LTR и для частоты генерации меток 25 Гц у Вас будет 8 * 6 = 48 повторяющихся значений tmark.
Но это в идеальном случае, если бы частота LTR212 была бы ровно 150 Гц и частота генерации меток и частота модуля была бы строго синхронно, но т.к. частота у LTR212 не ровно 150 Гц, а чуть выше, да и частота для генерации меток у Вас внешняя, то число повторяющихся tmark у Вас будет не строго фиксированное.

В LTR114 также на один отсчет передается с помощью двух слов LTR. Но в отличие от LTR212 каналы опрашиваются последовательно (т.е. первый отсчет первого и второго канала сдвинуты по времени на период частоты АЦП).

6) Не совсем понял, что имеется ввиду под командой СТАРТ крейту. Если полный перезапуск сбора всех модулей, то это может быть достаточно длительный процесс, зависящий от состава модулей, интерфейса подключения крейтов и т.п. и привязка соответственно будет очень не точной.
Если привязывать время к команде с ПК, то можно использовать метку секунда. Т.е. сбор с модулей идет всегда, а для привязки делается команда ведущему крейту сгенерировать метку секунда, с засеканием времени перед посылкой команды и сразу после посылки и считая время метки как среднее между этими двумя. И дальше уже по части, отвечающей за метки СТАРТ в tmark, привязать отсчет в потоке к абсолютному времени. Погрешность конечно тут все равно будет как разность между временем передачи команды и временем получения ответа, т.к. ОС общего назначения вносит переменные задержки, как и сам интерфейс с крейтом, которые не обязательно одинаковые на прием и передачу, но с точки зрения привязки по команде к ПК лучше вряд ли возможно. И данные в этом варианте вообще не теряются.