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

Здравствуйте!
Имеется система измерений (ИС) медленно меняющихся параметров на базе PCI-АЦП, в которую предполагается установить 4 крейта LTR-16EU, 4*16=64 модуля LTR27, количество каналов до 4*16*16=1024. Частота работы всех LTR27 в пределах 4-10 Гц.

ПО ИС верхнего уровня под Windows работает в цикле с периодом Т=100 мс (возможно увеличить до 200-250 мс).
Цикл запускается от обычного таймера Windows с синхронизацией по часам ПК.
Цикл работы ПО включает:
-отсчет времени по часам ПК;
-опрос всех LTR27;
-опрос прочих ИК-ов;
-расчет;
-регистрацию;
-выдачу на экран средних за 10 опросов.

Предполагаемый порядок работы с LTR27:
Производится конфигурация LTR27 по руководству, далее

LTR27_Start
Цикл
{
    ...
    LTR27_Recv
    ...
}
LTR27_Stop

Вопросы:
1. Как организовать сбор данных с 64 модулей LTR27, уложившись в период Т? Ошибка отсчета времени и разбег времени между каналами должны быть в пределах Т.
2. Если использовать вместо LTR27 модули LTR11, может ли это облегчить задачу п.1 и насколько это может удешивить систему?

Здравствуйте.

С точки зрения

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

Другой вопрос, что подразумевается под

. Если вопрос привязки отсчетов к абсолютному времени, то аппаратной привязки к времени отсчетов нет в крейте нет, только если использовать программную с некоторыми допущениями. За время начала можно использовать время перед командой для генерации метки СТАРТ всем модулям, то ошибка во времени будет равна времени выполнения команды, что строго говоря для ОС общего назначения как Windows не регламентировано (хотя скорее всего будет находится в нужных пределах в случае если ОС не "притормазит" из-за чего-то).

По поводу цикла опроса, то  с моей точки зрения более простым и надежным способом с точки зрения цикла опроса будет вместо последовательного опроса модулей создать отдельно поток под каждый модуль, который будет принимать данные от своего модуля, отслеживая момент синхрометки СТАРТ для начала сохранения данных и передавать эти отсчеты в основной поток регистрации (или сохранять в очередь, чтобы основной поток их забрал уже в своем основном цикле). Кроме того, при наличии очереди между потоками можно избежать пропуск данных, если из-за загрузки ОС по какой-то причине таймер основного потока пропустит цикл (если это допустимо), т.к. опять же Windows не ос реального времени и насколько и не может гарантировать, что обработчик таймера будет каждые 100мс при любых условиях (загрузке и т.п.).

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

По погрешности времени
Отсчет времени происходит в начале цикла работы ПО ИС по часам ПК - "Т0".
Погрешность времени при этом - разница между T0 и моментом времени, когда производилось измерение в модуле.
Основная задача СИ - делать замеры, т.е. на установившемся режиме в течении 10 с собирать с ИК данные и записывать среднее значение. В этом случае погрешность в 1 с вполне допустима.
Регистрация с частотой 10 Гц нужна для "разбора полетов" в случае нештатной ситуации или посчитать выбег вала или количество съеденного топлива. Здесь требуется чтобы погрешность времени соответствовала в среднем периоду опроса.
По результатам испытаний, таймер Виндовс взбрыкивает очень редко 1 раз за 10000 циклов, что для нас вполне допустимо.
Нам не хочется связываться с метками времени и синхронизацией крейтов, а также с дополнительными потоками в основной программе.
Если я правильно понял, в одном потоке организовать такой сбор невозможно из-за функции LTR27_Recv, которая ждет ответа от ltrd или от модуля слишком долго?

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

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

Другой вопрос, что эти подходы сильно зависят от задержек самой ОС Windows.

К сожалению, крейтов LTR у нас нет и проверить не могу.
Хотелось бы понять логику работы механизма сбора данных.
По команде ADCStart модуль начинает пересылку данных в ltrd, который будет складывать их в свой буфер.

Допустим,
ltr27.FrequencyDivisor=199;
NSAMPLES=16;
size=LTR27_Recv(&ltr27, buf, NULL, NSAMPLES, Timeout);

Что будет если не собирать данные вовремя. Будут ли затираться старые данные новыми, или новые будут отбрасываться?
Что будет если указать Timeout=0?

Да, после старта модуль начинает пересылать данные в ltrd с частотой, соответствующей настроенной частоте АЦП. Эти данные помещаются в очередь в ltrd. LTR27_Recv() считывает заданное количество слов из начала очереди (если за заданный таймаут так нужного кол-ва слов и не появилось, то возвращает только те слова, что есть в очереди с указанием размера). 
Если данные вовремя не вычитывать то они просто накапливаются в очереди ltrd (если не вычитывать долго, то этот буфер может переполнится, что считается ошибочной ситцацией и когда чтение дойдет до момента разрыва данных, то Recv вернет ошибку, но для ваших частот в 10 Гц за 10 с в любом случае этот буфер не переполнится).

Timeout = 0 означает использование таймаута по умолчанию для соединения, который можно установить через LTR_SetTimeout(), если один раз после открытия соединения с модулем вы сделаете LTR_SetTimeout с 0, то тогда Timeout=0 будет означать, что функция просто проверит наличие данных в ltrd и вернет от 0 до NSAMPLES слов (в зависимости от того, сколько их в буфере ltrd)

Здравствуйте Алексей!

Будет ли работать этот фрагмент, чтобы опрос 64-х модулей уложить в 100 мс?

NChan=16;
NKadr=1000;
Timeout=0;
while(true)// Основной цикл программы
{
    for(int i=0; i<64; i++)
    {
      size=LTR27_Recv(&ltr27, buff, NULL, NChan*NKadr, Timeout);
      // 
      // По какому адресу будет лежать последний принятый кадр от модуля
      // в массиве buff?
    }
}


Во первых для каждого модуля LTR27 должна быть своя структура TLTR27 (т.е. в Recv первый параметр вроде &ltr27[ i ]).
Также для нулевого таймаута как писал выше нужно перед циклом один раз сделать для каждого модуля LTR_SetTimeout (&ltr27[ i ].Channel, 0).

С точки зрения адреса, то в простейшем случае  последние нужные отсчеты будут в массиве buff с номерами size - NChan (первый канал первого субмодуля) до size - 1 (второй канал последнего) (далее этот массив из NChan элементов нужно передать в ProcessData()). Но это если LTR27_Recv() всегда будет возвращать размер кратный NChan, что не обязательно (если прием придется в момент когда принята только часть кадра). Поэтому в общем случае нужно еще учитывать, что нужно брать отсчеты начиная с индекса, кратного NChan от начала приема.

Чтобы это могло уложится в 100мс нужно, чтобы:
1. Выполнение самого цикла не задержалось из-за задержек Windows
2. В момент Recv() нужного кол-ва данных может не прийти. Кроме того, если пришло больше данных, а Вы берете по одному отсчету, то часть данных придется отбросить.

Если нужно сохранять данные идущие со строгим периодом, то мне кажется будет проще настроить модуль на частоту 100 Гц и принимать с ненулевым таймаутом по одному кадру (NChan отсчетов), тогда не будет проблем с выравниванием кадром (вы всегда принимаете по одному кадру) и т.п.

Будет ли это успевать опять же определяется задержками Windows и в интерфейсе при приеме данных...