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

Добрый день.

Не хватает понимания по теме, поэтому хочется раскрыть некоторые детали взаимодействия LabView и модуля LTR11.
Имеется конфигурация (часть схемы):
крейт LTR-EU-8-2 (подключение к ПК по USB) и один из установленных модулей - LTR11, к которому подключен пирометр.
Опираясь на пример для LabView из раздела "ПО ДЛЯ LTR МОДУЛЕЙ" разрабатываю VI под наши нужды. Основной замысел - использовать оцифрованные с пирометра показания для ПИД-регуляции.
Соответственно, нужно довольно часто передавать показания на ПИД-регулятор. А учитывая то, что сбор данных (из пары Recv+ProcessData) будет крутиться в одном цикле с ПИД-регулятором, то часто нужно не только передавать показания, но и "снимать" их.
Но, насколько я понял из чтения документации, данные снимаются и крутятся в буфере модуля, а LTR_Recv лишь забирает часть данных. И размер этой части устанавливается полем "Время сбора блока (мс)". В совокупности с "Количеством логических каналов" и "Частотой АЦП, Гц" они определяют размер выходного массива данных.
Следовательно, я мог бы уменьшить "Время сбора блока (мс)" и забирать одно значение из этого массива, но всё-таки насколько часто LTR_Recv сможет забирать данные? Насколько мал этот промежуток времени чисто теоретически?
Или же проще оставить в цикле только Recv+ProcessData и замерить внутренними средствами LabView время выполнения одной итерации? (+- сколько-то процентов) Раз уж "Время сбора блока (мс)" - это не реальное время сбора и напрямую не влияет на время выполнения одной итерации.

С уважением,
Павел

Добрый день.

С точки зрения механизма приема Вы в принципе все верно написали, отсчеты от модуля снимаются с заданной частотой и далее передаются в буфер в ПК, а уже Recv забирает данные указанными порциями, соответственно размер чтения вместе с частотой АЦП (равной частоте на канал * кол-во лог. каналов) определяет интервал времени, которому соответствует принятый блок данных.

В принципе возможно уменьшение размера приема вплоть до приема по одному отсчету на канал, но практически есть следующие ограничения:
1. При уменьшении размера блока приема увеличивается частота вызова функций и нагрузка на процессор
2. Имеются задержки в Windows как при получении данных из крейта в буфер, так и при получении данных из буфера программой. Более того, так как Windows не является ОС реального времени, то строго говоря задержки системных вызовов не определены. В общем то эти задержки и являются главным ограничением скорости реакции управления и возможности его реализации на верхнем уровне под ОС общего назначения.

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

Также, так как задержки вызовов в Windows при каждом вызове могут отличаться, для уменьшения их влияния возможно следует для управления учитывать время отсчета исходя из частоты АЦП и  номера принятого кадра, а не исходя из именно времени приема функцией Recv.

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

Алексей, спасибо за развернутый ответ.