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

LTR114 + LTR27 (эксперимент 2)

Привет LTR support!

Несинхронный прием с разных модулей.

Экспериментируя с модулями LTR114 + LTR27 на этот раз я наконец
сделал график который адекватно показывает сброшенные сериями данные, в том виде в котором они сбрасываются (без сампловой конверсии).

Генератор дает синусоиду частотой 25Гц которую я опрашиваю с частотй 250 Гц (сигнал одинаков для всех модулей).
Я использую LTR114 (16 лог. каналов) из которых записываются 1-й и 16-й и LTR27 c двумя мезонинами измеряющих милливольты (из 16 каналов пишется только 1-й).

Опрос модулей происходит единообразно в нитках модулей. У каждого канала сбрасывается время и значение.
Время каждого значения я получаю после фукции приема данных.
В случае LTR27 время одинаково для всех принятых каналов.
В случае LTR114 я измеряю время после приема 16 каналов и потом получаю время кажого канала путем вычитания времени опроса каждого канала умноженное на номер канала.
Т.е. (distance это время кадра)

  __int64 one_channel_time_in_frame_i64 = 0;
    one_channel_time_in_frame_i64 = distance / ltr114.LChQnt;  //время заполнения одного канала в кадре приема

 int size_Recv = LTR114_Recv(&ltr114, raw_data, NULL, ltr114.FrameLength, 1500);

   for(int i = 0, ir = size_Recv - 1; i < size_Recv; i++, ir--)
   {
    __int64 timestamp_recbuf_i64 = frame_end_time_i64 - one_channel_time_in_frame_i64 * ir;
    ...
   }

И вот что получается:
https://wmpics.pics/di-M1W0.jpg

Т.е. не смотря на то, что частоты опроса равны, наблюдается рассинхронизация каналов из разных модулей. Время рассинхронизации равно времени дискретизации (т.е. 4 мсек). Почему это может происходить?

Данные в текстовом виде
https://drive.google.com/open?id=1Vvwn1 … RG7RubBHZr

Добрый вечер.

А сдвиг этот фиксированный от запуска к запуску, если проводить несколько экспериментов?
Значение frame_end_time_i64 Вы каким образом получаете?

Никаких различий по поводу смещения кривой LTR27 нет.

frame_end_time_i64  получается после функции приема данных:

   __int64 frame_end_time_i64 = 0;                    //время конца измерения кадра
   CoFileTimeNow( (FILETIME*)&frame_end_time_i64 );   //здесь получим время конца кадра в котором size_Recv параметров
   FileTimeToLocalFileTime((FILETIME*)&frame_end_time_i64, (FILETIME*)&frame_end_time_i64); //получаем локальное время

Остальные настройки LTR114:

В функции ltr_mod114::MakeChannels()
{
...
 res = LTR114_Init(&ltr114);
 ltr114.FreqDivider = FreqDivider_ini; //делитель частоты дискр.
 ltr114.LChQnt = Kol_log_kanals_ini;   //количество логических каналов

....
}


В функции ltr_mod114::Start()
{
...
 ltr114.SyncMode = LTR114_SYNCMODE_INTERNAL; //внутренняя синхронизация
 ltr114.Interval = 0; //без межкадрового интервала (при LTR114_CORRECTION_MODE_INIT в LTR114_ProcessData())
 ltr114.SpecialFeatures = 0;

 //передаем настройки модулю
 res = LTR114_SetADC(&ltr114);

//distance это переменная класса ltr_mod114 - время от кадра до кадра в FILETIME единицах

 distance = (DWORD)(10000000. / LTR114_FREQ_CHANNEL(ltr114));  //В FILETIME (0.1 mksec)

//в данном случае получается distance == 40000 (4 мсек)
...
}

Нашел в чем было дело. Я для теста сделал замер времени для LTR27 не после LTR27_Recv(), а до вызова (и забыл вернуть назад). Время работы функции LTR27_Recv и было неточностью. Упс.

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

Вообще же как оказалось я рано обрадовался. Не зря вы спрашивали всегда ли наблюдаеется рассинхронизация. Т.е. в одной записи дейстительно кривые практически совпадают, а в другой записи может получится рассинхронизация аж до 2 мсек.
Сделал еще график для просмотра с учетом микросекунд. Вот к примеру сегодня я тестировал запись 250 Гц синусоиды 25 Гц LTR114 1 лог канал + LTR27 (пишется 1 канал) Как видим результаты разные.
https://i.ibb.co/qdkLrtf/25-250-LTR114-1ch-LTR27-1.jpg

Как возможное объяснение я могу предложить это

Конструкция замера времени после считывания

   CoFileTimeNow( (FILETIME*)&timestamp_recbuf ); 
   FileTimeToLocalFileTime((FILETIME*)&timestamp_recbuf, (FILETIME*)&timestamp_recbuf);

Не может дать точное время на таких частотах (мы говорим про 250Гц опрос). Как я выяснил эта конструкция не выдает микросекунд при замере (только миллисекунды), хотя и оперирует с 64битным числом. А это значит, что по крайней мере в windows XP расхождение времени двух параметров из разных потоков при замере времени таким способом может достать максимум двух миллисекунд, а в благоприятном случае время может совпадать.

Тут может быть достаточно много источников ошибки
- как Вы написали, точность измерения времени в Windows. Хотя это можно попробовать исправить более точными функциями (https://docs.microsoft.com/en-us/window … ime-stamps), например если без привязки к абсолютному времени, то QPC (QueryPerformanceCounter) доступен на WindowsXP (хотя с некоторыми оговорками по железу).
- различные задержки от момента измерения до получения с помощью Recv(). Это может быть как задержки передачи, так и задержки самой ОС (хотя самое последнее по идее должно вводить разброс соотношения для каждого кадра, а у Вас по рисунку вроде сдвиг в одном эксперименте фиксированный).

Хотя в общем конечно получать привязку точностью в мс средствами Windows, которая не является ОС реального времени, может быть достаточно проблематично...

Можно еще спросить насчет недочитывания из буфера. Может ли недочитывание произойти у LTR27? Тогда при синхронном формировании времен значения LTR27 будут отставать от другого модуля. Вероятно такое я видел здесь
https://i.ibb.co/k4ZMLSZ/1x1-10-100-LTR114-LTR27.jpg

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

Если Вы выполняете прием модуля в своем отдельном потоке и между Recv нет длительных операций, то если из-за задержки потока Вы не вычитаете кадр, то при следующем чтении Вы его прочитаете быстрее, т.к. он уже в буфере. Т.е. тогда бы была бы смещена одна точка по интервалу, затем шли бы точки с меньшим интервалом до выравнивания.  Если действительно замер времени делается для каждой точки и при построении графика координата по x каждой точки учитывается своя явно измеренная (больно уж подозрительно точная эквидистантность точек у Вас одного графика по оси x для измерения времени в Windows...)

Проблема временной маркировки на большой частоте опроса хорошо решается путем увеличения интервала считывая времени из системы.

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

Т.е. если я правильно понял, Вы делаете замер времени один раз на много кадров, а время приема остальных кадров из серии рассчитывается исходя из частоты опроса кадров. При этом, если я правильно понимаю, сдвиг по времени между сигналами разных модулей как раз и появляется в момент измерения этого времени и сохраняется до следующего измерения. Если это так и использование более точного таймера на это не влияет, то скорее всего это связано с задержками  самой Windows, т.к. Windows может передать управление программе, вызвавшей Recv несколько позже, чем действительно прием завершится, и эта задержка в ОС общего назначения не нормируется и может быть случайной.

Бывает что LTR27_Recv возращает 0. Как это обрабатывать, что происходит с данными? Может быть как раз при этом и происходит недочитывание?

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

Продолжение о совместной записи модулей LTR114 и LTR27 (проблема рассинхронизации и как её убрать)

Кратко напомню о чем речь:
В одном крейте стоят LTR27 и LTR114. Задача вроде тривиальная - сделать так, чтобы мой OPC сервер записывал бы полученные данные (частота 10 Гц) в файл. Оцифровывалась синусоида с частотой 1 Гц - сигнал подавался на все модули.

Как я выяснил главная проблема - в получении одинаковой временной маркировки получаемых данных как на LTR27, так и на LTR114. Мы допустим сделали нитки разных модулей и вызываем функцию LTRxx_Recv. Но эти функции работают по разному у разных модулей.

LTR27:
Что происходит во время LTR27_Recv при кадре в 100 миллисекунд? Я могу считать время только после вызова LTR27_Recv. Но внутри этой функции сначала идет оцифровка, потом пауза и только после я могу считать системное время для маркировки полученных данных. Но у LTR27 после паузы время отличается от времени оцифровки на порядка 45 миллисекунд (плюс минус - зависит от состояния windows).

LTR114:
У модуля LTR114 (с последовательной оцифровкой каналов) похожее происходит когда у него 1 логический канал, но если их много, то пауза между реальным событием и измерением времени будет много меньше чем на LTR27. Время измеренное после LTR114_Recv будет гораздо ближе к времени оцифровки последнего канала. Значит, мы можем получить времена остальных параметров в буфере вычитая из в времени последнего параметра длительность оцифровки одного канала умноженное на индекс канала относительно последнего канала.

При записие двух модулей результат - синусоиды одного сигнала записанные разными модулями (LTR114/LTR27) не совпадают на графике, LTR27 отстает в среднем на 45 миллисекунд, но временами и больше.

https://i.ibb.co/C1SpDN6/image.jpg

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

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

Второй вариант реальный - у LTR27 нужно сократить паузы после оцифровки. Т.е. максимально приблизить замер времени после LTRxx_Recv к моменту оцифровки. Этого можно достигнуть увеличив частоту дискретизации минимум на порядок.

Иначе говоря, для записи с LTR27 с частотой 10 Гц я задаю опрос модулей LTR27 в 200 Герц. В настойках моего OPC сервера я указываю, что во время записи записывать только каждое 20-е измерение.

Если так же записывать и LTR114, то результат будут еще идеальнее. Испробовано для длинных сериях.

Результат - отсутствие расхождения кривых разных модулей - идеальная запись!

https://i.ibb.co/hH2mLKm/image.jpg