+7 (495) 785-95-25
+7 (495) 785-95-14
sale@lcard.ru
English version
Меню
+7 (495) 785-95-25
sale@lcard.ru
sale@lcard.ru
Страницы 1
#1 Re: Техническая поддержка » LTR34-8. Дефект формируемого сигнала » 14.10.2020 10:46:39
С LTR34 работаю в отдельном цикле и на каждой итерации отправляю по блоку данных. Цикл крутится как бы с одной и той же скоростью, но с погрешностью в несколько мс (что-то где-то задержалось, Recv приходится вычитывать больше отсчетов и отрабатывает она дольше и т.д.). Именно поэтому приходится корректировать длину блоков.
На 1-й итерации закидываю большой блок данных. На всех последующих итерациях я вызываю LTR34_Recv c timeout=0, чтобы узнать, сколько за время с прошлой итерации было воспроизведено отсчетов. Зная, сколько при этом я отправил отсчетов с п-ю LTR34_Send, у меня складывается представление о заполненности буфера модуля. Всё это лишь примерно, поэтому тут я закладываю некий запас по времени (отправляю больше отсчетов).
Соответственно, если я кладу мало данных и/или не успеваю вовремя положить, то да, возникает вот такой разрыв:
https://www.lcard.ru/forums/img/members … _break.png
А то, что я показал в пред. скриншоте выглядит немного иначе и это меня смутило.
Задача усложняется тем, что от меня требуется изменять сигнал (скважность) гораздо чаще, чем в примере, где блок = 250 мс. И возникает устойчивое ощущение, что с условным "буфером" в десятки мс проблематично добиться стабильной работы. А если, как Вы говорите, блок, отправленный за раз LTR34_Send-ом так же может разбиться, то тогда вообще всё сложно получается..
#2 Re: Техническая поддержка » LTR34-8. Дефект формируемого сигнала » 13.10.2020 17:20:05
Да. Упоминая разрывы, я именно это имел в виду. В тех блоках, что я загружаю/отправляю, последние значения - всегда нули. Соответственно, если бы это был тот случай, то выглядело бы оно иначе (растянулась бы нижняя часть). Поэтому я и разделил их, как две разные проблемы.
#3 Техническая поддержка » LTR34-8. Дефект формируемого сигнала » 13.10.2020 15:46:02
- prodin
- Ответов: 6
Добрый день.
Столкнулся с какой-то неисправностью или аномалией в генерации сигнала с п-ю LTR34-8.
Конфигурация по сути та же:
крейт LTR-EU-8-2, подключение к ПК по USB, несколько модулей (полный список виден на скриншоте с LTRTEST2, но используются не все).
https://www.lcard.ru/forums/img/members … -2_1_0.png
LTR34-8 управляю из LabVIEW (потоковый режим, как в ltr34_stream_fifo_ctl). Использую только 1 из 8 каналов. Частота ЦАП = 100 кГц. Генерирую сигнал прямоугольный формы. Период следования = 1 мс. Соот-но, импульс получается на 100 отсчетов. Блоки с отсчетами отправляю переменной длины в зависимости от условной заполненности. Макс. длина блока при такой частоте до 80 импульсов (мс), но обычно меньше.
И вот этот аналоговый сигнал проверяю параллельно на одном из LTR11 в LGraph2. Массив данных для ЦАП, подготовленный в LabVIEW, выглядит корректно - половина значений 3.0, а другая 0.0, и они чередуются пачками по 50. А в LGraph2 видно, как часть с 3В "растягивается" по времени на одном из импульсов. Длительность других импульсов в блоке остается корректной, как и их число. Поэтому из-за этого "зависания" общая длительность блока увеличивается на несколько мс (на 1-13 мс).
https://www.lcard.ru/forums/img/members … t_0001.png
Возникала мысль, что не очень правильно проверять модулем в том же крейте, что и ЦАП. Но потом проверил с п-ю внешнего модуля E20-10, который подключил к другому ПК, и он показывает такую же картину.
Также поначалу хотел написать, что еще несколько месяцев назад такого не было, но потом нашёл пару таких дефектов среди множества записей в LGraph2 (т.е. проявлялось значительно реже).
Есть какие-то соображения, что это может быть? Разрывы, по крайней мере, понятны (если не успевать вовремя докладывать данные), а тут совсем непонятно.
С уважением,
Павел
#4 Re: Техническая поддержка » LabVIEW - вопрос по LTR34_Recv » 02.03.2020 09:54:25
Алексей, спасибо.
Установил, посмотрел - теперь на LTR34_Recv тратится меньше времени.
Правильно я понимаю, что теперь при timeout=0 я должен указать size и размерность Data, равными [ожидаемому_кол-ву_слов]+[некоторый_запас]?
А то я на прошлой неделе почему-то подумал, что могу поставить timeout=1, а Data/size бесконечно большими и тогда Recv просто вернет то кол-во слов, которое успела принять за 1 мс. А возникло такое ощущение, что Recv просто вычитывала всё, что есть, т.е. времени это занимало больше.
#5 Re: Техническая поддержка » LabVIEW - вопрос по LTR34_Recv » 26.02.2020 11:08:39
Пока пользуюсь 1 мс и пытаюсь понять, достаточно ли этого.
Хотя изначально, делая по алгоритму, хотелось просто опрашивать и возвращать то число, которое уже есть, т.е. без таймаута.
#6 Re: Техническая поддержка » LabVIEW - вопрос по LTR34_Recv » 25.02.2020 16:52:50
Добрый вечер.
Появился еще один вопрос по поводу LTR34_Recv: захотелось установить timeout=0, но выяснилось, что это не 0 мс, а некое значение по умолчанию - LTR_DEFAULT_SEND_RECV_TIMEOUT. Нашёл функцию LTR_SetTimeout и теперь нужно ей воспользоваться в LabVIEW. По идее также через Constructor Node и Invoke Node (?), но никак не могу найти, где конкретно эта функция находится?
#7 Re: Техническая поддержка » LabVIEW - вопрос по LTR34_Recv » 17.02.2020 15:25:28
Алексей L Card пишет:
Добрый день.
1. Да, эхо ответ модуль посылает после непосредственно вывода уровня, соответствующего этому слову, на ЦАП. Т.е. эти слова были выведены + успели быть переданы из крейта в ПК.
2. Нет, эхо ответы не пропадут. На ПК есть буфер (в службе ltrd), в который принимаются данные от модуля всегда, а Recv просто забирает данные из этого буфера (с возможным ожиданием их прихода). Так что, если этот буфер не переполнится (а по умолчанию он на 1024 КСлов, т.е. на 2 секунды при макс. скорости модуля, но можно и изменить глобально для всей службы через LTR Manager), то ответы не пропадут.
Тут основная опасность задержки не в том, что ответы пропадут, а в том, что если процесс задержится на время, за которое все посланные данные через Send будут выведены на ЦАП, то так как в ЦАП не будет данных на передачу, то он будет повторять прошлое слово и, соответственно, будет разрыв сигнала. Таким образом, нужно, чтобы всегда в буфере было количество отсчетов не меньше максимально допустимой задержки на верхнем уровне. Чем меньше этот размер, тем меньше время реакции на изменение, но и больше чувствительность к возможным задержкам.
3. Да, если Вам надо контролировать заполненность буфера, т.е. сигнал заранее не известен и определяется во время уже запущенного вывода, то это единственный способ. В общем тут сложно придумать другой механизм контроля с верхнего уровня для задачи общего вида.
Спасибо, понял. Про этот буфер не додумал..
По п.2 эту проблему осознаю. Если где-то не успеваю в программе, то в LGraph2 видны эти самые разрывы между блоками (наблюдаю на 2-м LTR11). Поэтому экспериментирую с параметрами и алгоритмом в целом.
#8 Техническая поддержка » LabVIEW - вопрос по LTR34_Recv » 17.02.2020 12:11:59
- prodin
- Ответов: 8
Добрый день.
Возникли сомнения в понимании работы с LTR34 в LabVIEW.
Конфигурация следующая:
крейт LTR-EU-8-2, подключение к ПК по USB,
несколько модулей - LTR11, LTR43, LTR34-8.
В своем приложении работаю с LTR34 аналогично примеру на сайте в потоковом режиме, т.е. AcknowledgeType=ECHO и периодически подкладываю данные, опираясь на то, сколько уже получено модулем (LTR34_Recv).
1) Тут 1-й вопрос, эхо, которые считает Recv - это ведь то количество данных, которое было получено модулем и уже воспроизведено? (в смысле уже ушло с модуля в виде аналогового сигнала в случае с ЦАП)
2) Если так, то чисто теоретически, если эти две операции, отправить данные (ProcessData + Send) и "слушать" ответ (Recv), крутятся в отдельном цикле, но в нем также имеются другие операции.. или же между итерациями произошла какая-то задержка, то получается, что в это время модуль отчитывался о полученных данных в крейт, а я в это время не "слушал" с помощью Recv и начал позже, то те эхо как бы пропали?
Может показаться ерундой при непродолжительной работе, но если скажем, блок 10-20 мс и работать ~20 минут, то расхождение наверняка будет существенным.
3) Отсюда вытекает след. вопрос - это ведь единственный способ контролировать заполненность буфера модуля? (с п-ю Recv) Или есть еще какой-то способ гарантированно узнать, сколько модулем уже получено слов/отсчетов? (вроде бы можно считать эти единицы синонимами в контексте подсчета данных и времени)
p.s. Понимаю, что Windows - не система реального времени и самого смущают некоторые моменты, но приходится выжимать максимум.
С уважением,
Павел
#9 Re: Техническая поддержка » Работа с LTR11 в LabView » 06.05.2019 13:25:16
Алексей, спасибо за развернутый ответ.
#10 Техническая поддержка » Работа с LTR11 в LabView » 06.05.2019 10:21:32
- prodin
- Ответов: 2
Добрый день.
Не хватает понимания по теме, поэтому хочется раскрыть некоторые детали взаимодействия LabView и модуля LTR11.
Имеется конфигурация (часть схемы):
крейт LTR-EU-8-2 (подключение к ПК по USB) и один из установленных модулей - LTR11, к которому подключен пирометр.
Опираясь на пример для LabView из раздела "ПО ДЛЯ LTR МОДУЛЕЙ" разрабатываю VI под наши нужды. Основной замысел - использовать оцифрованные с пирометра показания для ПИД-регуляции.
Соответственно, нужно довольно часто передавать показания на ПИД-регулятор. А учитывая то, что сбор данных (из пары Recv+ProcessData) будет крутиться в одном цикле с ПИД-регулятором, то часто нужно не только передавать показания, но и "снимать" их.
Но, насколько я понял из чтения документации, данные снимаются и крутятся в буфере модуля, а LTR_Recv лишь забирает часть данных. И размер этой части устанавливается полем "Время сбора блока (мс)". В совокупности с "Количеством логических каналов" и "Частотой АЦП, Гц" они определяют размер выходного массива данных.
Следовательно, я мог бы уменьшить "Время сбора блока (мс)" и забирать одно значение из этого массива, но всё-таки насколько часто LTR_Recv сможет забирать данные? Насколько мал этот промежуток времени чисто теоретически?
Или же проще оставить в цикле только Recv+ProcessData и замерить внутренними средствами LabView время выполнения одной итерации? (+- сколько-то процентов) Раз уж "Время сбора блока (мс)" - это не реальное время сбора и напрямую не влияет на время выполнения одной итерации.
С уважением,
Павел
#11 Re: Техническая поддержка » LTR11 - Error 1011 » 20.02.2019 10:22:44
@Алексей L Card, спасибо за оперативную помощь! Теперь работает исправно.
#12 Re: Техническая поддержка » LTR11 - Error 1011 » 19.02.2019 15:28:40
Сразу не разобрался с скринами..
#13 Техническая поддержка » LTR11 - Error 1011 » 19.02.2019 15:26:38
- prodin
- Ответов: 4
Добрый день.
Имеется крейт LTR-EU-8-2 (подключен к ПК по USB) и среди установленных в нём модулей - LTR11. К нему в свою очередь подключен пирометр (12 каналов, если я правильно понимаю). Время от времени проводится работа в LGraph2, с этим всё в порядке.
Далее требуется поработать с LTR11 в LabView. Для этого доустановил набор библиотек (ltrdll.exe) и перезагрузился. Скачал для начала пример для LabView из раздела "ПО ДЛЯ LTR МОДУЛЕЙ". Открываю vi из директории 10.0, т.к. LabView 18-й версии и вижу 2 warning, вроде бы не критичные (см. вложения).
После этого изменяю номер слота на нужный, запускаю vi и наблюдаю:
справочная инфа (названия, серийный номер, прошивка) есть;
сигналы с каналов отображаются, изменяются со временем;
НО через несколько секунд сваливается с ошибкой 1011, LTR11_ProcessData: Неверный номер канала в массиве полученных от АЦП данных.
Поигрался с параметрами (режим, частота, количество логических каналов) и заметил, что эта ошибка не появляется только при Количестве логических каналов = 1.
Буду благодарен, если направите в документацию или подскажите, как мне отладить тестовый пример (может, как-то проанализировать получаемые данные).
С уважением,
Павел
Страницы 1
Контакты
Адрес: 117105, Москва, Варшавское шоссе, д. 5, корп. 4, стр. 2
Многоканальный телефон:
+7 (495) 785-95-25
Факс: +7 (495) 785-95-14
Отдел продаж: sale@lcard.ru
Техническая поддержка: support@lcard.ru
Время работы: с 9-00 до 19-00 мск