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

Предположим частота опроса каналов модуля 1Гц. В какой момент производится измерение?

Два варианта:
1. Сначала модуль делает паузу 1000 мсек, потом производится оцифровка всех каналов.
или
2. Сначала делается оцифровка всех каналов, потом пауза 1000 мсек.

Здравствуйте.
Из п. 17.2.2.2 "Особенности АЦП" https://www.lcard.ru/download/ltr.pdf следует, что в LTR114 цикл сбора данных TADC начинается с коммутации каналов, затем происходит ожидание установления сигнала после коммутации на входе интегрального АЦП, а затем происходит собственно преобразование в течение TCONV, длительность которого оценивается по приведённой формуле. Далее, там написано:

В течение времени TCONV.

У меня какая-то непонятная проблема, она не появлялась пока частоты опросы были большими. Но вот я захотел потестить запись у  указал два модуля с разными частотами опроса. Проблемка summary:

Запаздывание в показаниях каналов LTR114 при частоте опроса 1 Гц

Меандр генерируется генератором с частотой 0.1 Гц амплитудой от -0.025V до +0.025V

В крейте u3 опрашиваются два модуля 5-й (LTR114 или u3_m5, с частотой 1Гц)  и 12-й (LTR 27  или u3_m12, с частотой 10Гц
У каждого модуля опрашиваются по два канала  (в двух нитях).
Записываются только по одному параметру из каждого модуля  u3_m5_c1 и u3_m12_c1.

Модуль LTR114 (опрос 1Гц) стартует долго (более 6 секунд) видимо из-за начальной автокалибровки.
После старта наблюдается запаздывание в его показаниях на 1.3 секунды от показаний LTR27(10Гц). 

Если оба модуля опрашивать с частотой 10Гц, то запаздывания нет, автокалиброка мгновенная.

Вот так это выглядит:

Приведенное ПО Вы сами пишите?
Я правильно понял, что для LTR114 Вы опрашиваете два канала, а на график выводятся значения только с одного? Тогда, учитывая что LTR114 --- АЦП с коммутацией каналов и опрашивает каналы последовательно, т.е. частота модуля делится между всеми разрешенными каналами, частота 1 Гц - это частота АЦП и тогда частота на канал 0.5 Гц, или это частота на канал, а частота АЦП - 2 Гц?
Две нити (потока) - имеется ввиду по нити на модуль?
Как вообще происходит привязка данных разных модулей к единому времени на графике?

AL> Приведенное ПО Вы сами пишите?

Да. Это OPC сервер с возможностью записывать данные опроса.

AL> Я правильно понял, что для LTR114 Вы опрашиваете два канала, а на
AL> график выводятся значения только с одного?

Да, потому что на графике выводится запись с диска, а записывались только первые каналы каждого модуля (для наглядности).

AL> Тогда, учитывая что LTR114 --- АЦП с коммутацией каналов и опрашивает каналы
AL> последовательно, т.е. частота модуля делится между всеми разрешенными каналами,
AL> частота 1 Гц - это частота АЦП и тогда частота на канал 0.5 Гц, или это частота
AL> на канал, а частота АЦП - 2 Гц?

У LTR114 1 Гц это частота дискретизации модуля. Т.е. число логических каналов 2 и делитель 4000. После LTR114_Recv и LTR114_ProcessData два канала заносятся в массив OPC тегов сервера, а первый канал, помеченный на запись, пишется в файл.

Запись в файл идет отдельной ниткой. У каждого тега свой буфер значений. Как только буфер тега заполняется, то выдается сигнал и по нему происходит сброс буфера в файл и создается новый буфер тега. Таким образом, файл записи состоит теговых буферов.

AL> Две нити (потока) - имеется ввиду по нити на модуль?

Я имел в виду, что каждого модуля своя нитка, которая работает через ltr_module::DataThread(void *arg)

AL> Как вообще происходит привязка данных разных модулей к единому
AL> времени на графике?

Наверно трудно объяснить коротко.
----------
Происходит конвертация блокового файла записи в файл табличной (сампловой) формы. Для этого берётся максимальная частота записи (в нашем случае 10Гц), и она принимается за интервал конвертирования. Создается массив значений для всех параметров (т.е. самл).
Далее читаем value итерируя все теговские блоки и их значения.
Если время записанного значения попадает в вилку интервала конверсии, то значение параметра заносится в массив значений и сампл целиком сбрасывается (т.е. время + все параметры массива).
Если параметр низкочастотный и не попадает в вилку интервала конверсии, то его значение в буфере-сампле остается прежним. Т.е. обновление его будет редким.
Таким образом в выходном сампловом файле 1 герцовый параметр превращается в псевдо 10 герцовый путем дополнения промежуточных самплов.
----------

Но, я хочу сказать, посмотреть процесс опроса можно путем распечатки самого блокового файла записи:
В приводимой ниже распечатке четко видно как заполняются два блока. Первый это LTR114 1Гц, второй LTR27 - 10 Гц. Т.е. измение знака значений val говорит о форме меантра, а по временам можно судить как разночастотные опросы двух модулей соотносятся во времени.

https://drive.google.com/open?id=1Yo8Kb … 3wq3tgjp1n

Правильно ли я понял, что время в файле это по сути время когда выполнилась ProcessData() для модуля?

Ну все же значит по делителю и по тому, что данные каждого канала обновляются раз в секунду, то частота самого модуля - 2 Гц и соответственно частота приема кадров - 1 Гц.

А такое же файл для частоты LTR114 в 10 Гц можете выложить? и допустим для 2.5 Гц?

Хотя в принципе те данные, что в Вашем файле объяснимы.

LTR114 измеряет каналы последовательно, сперва первый, затем второй. Т.е. цикл коммутации + измерения одного канала занимает 0.5 с.
Соответственно на момент прихода кадра, у Вас измерение второго канала соответствует интервалу времени (начало преобразования; конец преобразования):
Tch2 = (t - Tпер - Tconv; t - Tпер), где t - время приема кадра, Tпер - задержка на передачу от модуля до ПК , Tconv - время преобразования АЦП.
Измерения же первого канала было на 0.5 с раньше, т.е.
Tch1 = (t - Tпер - 0,5 - Tconv; t - Tпер - 0,5)

Задержку Tпер можно опустить, она в пределах разброса одинакова для обоих модулей, да и по сравнению с секундой незначительна.

По данным LTR27 Вы обнаруживаете спад сигнала в 09:19:07:962,
Прием кадра с LTR114 у Вас произошел в 09:19:08:328, т.е. для этого кадра у Вас измерение соответствует интервалу: (09:19:07:828 - Tconv; 09:19:07:828), т.е. измерение закончилось уже в 09:19:07:828, в то время как спад у Вас начинается в 09:19:07:962 (в 09:19:07:862 на LTR27 у Вас все еще высокий уровень), т.е. это измерение как раз завершилось незадолго до спада. Соответственно спад обнаруживается только в следующем измерении, которое придет в 09:19:09:328. И это даже без учета Tconv, т.к. нужно еще учитывать, что измерение соответствует не концу интервала, а условно усредненному значение за время преобразования Tconv.

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

Отредактировано Алексей L Card (29.11.2019 15:14:40)

AL> Правильно ли я понял, что время в файле это по сути время когда
AL> выполнилась ProcessData() для модуля?

Только не время файла, а время сброшенного теговского буфера. Как я говорил, файл записи состоит из буферов тегов (по 500 float значений в каждом буфере).

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

Каждое (из 500) значение в буфере записи имеет смещение distance (время относительно предыдущего значения). Т.е. при опросе 10 герц distance будет 0.1 сек. Чтобы узнать время N-го значения в буфере  нужно сложить все distance от предыдущих значений и прибавить время буфера.

AL> Ну все же значит по делителю и по тому, что данные каждого канала
AL> обновляются раз в секунду, то частота самого модуля - 2 Гц и
AL> соответственно частота приема кадров - 1 Гц.

Да, раз в секунду принимается два канала.

AL> А такое же файл для частоты LTR114 в 10 Гц можете выложить? и
AL> допустим для 2.5 Гц?

Здесь LTR27 10Гц + LTR114 10Гц 30 секунд
https://drive.google.com/open?id=1NHHqH … eoIFalC5yl

Для 2.5Гц не получится - максимальный FrequencyDivisor на LTR27 это 255, т.е. минимальная частота опроса LTR27 3.9 Гц. Делаю 4 герца для обоих модулей:

Здесь LTR27 4Гц + LTR114 4Гц 30 секунд
https://drive.google.com/open?id=1SlmXp … 4tPlT2uWBe

Когда у Вас одинаковая частота, то оба модуля определяют перепад со своей задержкой от 0 до Td, в зависимости от того как будет момент преобразования находится относительно самого фронта по времени (ну у LTR114 еще можно условно прибавить Tconv/2, так как усреднение идет за время Tconv). В общем тут вроде тоже все совпадает.
Про 1 Гц в предыдущим сообщении я постарался подробно описать что происходит.

Да я это проверю. Пока же я понял, что у меня неточно маркируется время у накопительного блока тега - я создаю этот блок и получаю время блока после  ProcessData(), т.е. после приема всех параметров кадра. Т.е. это фктически время прихода посденего параметра кадра.

Время блока тега должно определяться перед LTR114_Recv() в момент когда буфер тега еще не создан. Тогда формируя блок после ProcessData() я смогу установить в блоке более точное время и установить правильный distance по каждому параметру принятого блока данных.
Эта неточность здесь по идее тем больше, чем ниже частота опроса.

К тому же тесты надо производить когда в LTR114 1 Гц пишутся оба канала - тогда при распечатке записи лучше видно как происходит процесс опроса.

Можно также у Вас также уточнить, как по времени модуль LTR27 выдает данные с его восьми мезонинов на которых стоят H27T?
В буфере данных каналы  идут в порядке 1,2 Nмезонина и т.д, но как идет опрос по времени? Имеют ли все каналы на мезонинах одно время оцифровки или также как и в LTR114 каждый канал имеет свой временной 1 слот?
Вызов такой:
    int size_Recv = LTR27_Recv(&ltr27, buf, NULL, 16, 1000);

Т.е. в случае опроса 10 Гц чтобы получить время второго канала нужно прибавитьо  0.2 сек ко времени перед вызовом LTR27_Recv?

Для LTR27 измерения со всех каналов выполняются одновременно, в нем нет коммутации каналов.

А как же тогда заполняются метки времени (массив tmark) при вызове LTR27_Recv()? Ведь каждая метка соответстует элементу принятого массива?

В массиве tmark возвращается для каждого принятого слова количество меток каждого типа на момент прихода этого слова в сам крейт от модуля. Этот механизм работает независимо от типа модуля.

В случае с LTR27, модуль выполняет параллельно преобразование по всем 16 каналам в течении одного периода измерения, после этого передает все эти 16 слов одновременно в крейт. Ну, точнее одновременно ставит на передачу в крейт, т.к. интерфейс между модулем и крейтом последовательный, т.е. по сути все 16 слов соответствуют одному времени и приходят в крейт после завершения периода измерения друг за другом без паузы. Соответственно, у всех 16 слов будет одно значение tmark (ну если не рассматривать крайний случай, когда генерация метки произойдет в момент приема крейтом пачки из этих 16 слов и наложится на этот прием). Поэтому для АЦП без коммутации каналов, где все каналы выполняют преобразование одновременно, можно использовать только одну метку, соответствующую первому каналу, остальные в принципе не несут дополнительной информации.

Уточните пожалуйста бестолковому еще раз )

Пусть LTR114 опрашивает 2 канала с частотой 1 Гц

Я измеряю время перед вызовом LTR114_Recv():

timestamp = get_time()

Затем вызываю функцию опроса

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

В буфер от LTR114 последовательно пришло два значения.

Время первого значения = timestamp
или
Время первого значения = timestamp + Время кадра / число каналов?  (т.е +0.5 сек)

Если так получать timestamp до Recv, то второй вариант. Время значения i-го канала = timestamp + i/N * Tframe, где i - от 1 до N (не от 0 в этой формуле!), N - кол-во каналов, Tframe - время измерения всего кадра (1 с).
Хотя это будет правильно, только если вы в потоке больше вообще ничего не делаете кроме Recv/ProcessData, я бы взял timestamp после Recv и тогда время отсчета i-го канала будет = timestamp - (N - i)/N * Tframe. В этом случае не влияет задержка от одного Recv до второго, если она меньше Tframe.

Отредактировано Алексей L Card (05.12.2019 13:49:49)

Всё, разложил и разобрался, сделал правильное формирование времени блока тега (после LTR114_Recv()) Мне также помог случай, когда падение у меандра совпало с моментом измерения первого канала на LTR114 1Гц. Стало особенно ясно как последовательно измеряются каналы на LTR114 при низкой частоте опроса. Максимальное расхождение с опросом LTR27 10Гц не может превышать 1 секунду, что и было достигнуто.
https://wmpics.pics/di-6HCU.jpg

Касаемо другого модуля LTR11 - я так понимаю, что прием значений в LTR11 также последовательный и определение времени каждого значения в принятом буфере (после LTR_Recv()) будет также как это делается в LTR114 (в этом треде). Т.е. определяем время после LTR_Recv(), и зная число значений в буфере вычисляем время для каждого значения, путем вычитания времени на каждый канал. Я правильно понимаю, что большой разницы нет?

Да, все правильно. Для модулей с коммутацией каналов, которыми являются LTR114 и LTR11, алгоритм определения времени отсчетов одинаков.