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

Добрый день.

Возникли сомнения в понимании работы с 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 - не система реального времени и самого смущают некоторые моменты, но приходится выжимать максимум.

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

Добрый день.

1. Да, эхо ответ модуль посылает после непосредственно вывода уровня, соответствующего этому слову, на ЦАП. Т.е. эти слова были выведены + успели быть переданы из крейта в ПК.
2. Нет, эхо ответы не пропадут. На ПК есть буфер (в службе ltrd), в который принимаются данные от модуля всегда, а Recv просто забирает данные из этого буфера (с возможным ожиданием их прихода). Так что, если этот буфер не переполнится (а по умолчанию он на 1024 КСлов, т.е. на 2 секунды при макс. скорости модуля, но можно и изменить глобально для всей службы через LTR Manager), то ответы не пропадут.
Тут основная опасность задержки не в том, что ответы пропадут, а в том, что если процесс задержится на время, за которое все посланные данные через Send будут выведены на ЦАП, то так как в ЦАП не будет данных на передачу, то он будет повторять прошлое слово и, соответственно, будет разрыв сигнала. Таким образом, нужно, чтобы всегда в буфере было количество отсчетов не меньше максимально допустимой задержки на верхнем уровне. Чем меньше этот размер, тем меньше время реакции на изменение, но и больше чувствительность к возможным задержкам.
3. Да, если Вам надо контролировать заполненность буфера, т.е. сигнал заранее не известен и определяется во время уже запущенного вывода, то это единственный способ. В общем тут сложно придумать другой механизм контроля с верхнего уровня для задачи общего вида.

Спасибо, понял.  Про этот буфер не додумал..
По п.2 эту проблему осознаю. Если где-то не успеваю в программе, то в LGraph2 видны эти самые разрывы между блоками (наблюдаю на 2-м LTR11). Поэтому экспериментирую с параметрами и алгоритмом в целом.

Добрый вечер.
Появился еще один вопрос по поводу LTR34_Recv: захотелось установить timeout=0, но выяснилось, что это не 0 мс, а некое значение по умолчанию - LTR_DEFAULT_SEND_RECV_TIMEOUT. Нашёл функцию LTR_SetTimeout и теперь нужно ей воспользоваться в LabVIEW. По идее также через Constructor Node и Invoke Node (?), но никак не могу найти, где конкретно эта функция находится?

Добрый день.

Да, действительно, эта функция не была добавлена в .net библиотеку и не видна в LabView. Могу в ближайшие пару дней добавить, если она нужна. Так как функция устанавливает значение таймата для конкретного соединения, то видимо ее нужно будет добавить как метод (Invoke Node) для каждого класса модуля (включая ltr34api) , а также ltrcrate и ltrsvccon.
Либо можно использовать таймаут в 1 мс.

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

Я напишу тогда, как выложу новую версию с поддержкой этой функции

Обновил http://lcard.ru/download/ltrdll.exe. Теперь в новой версии ltrModulesNet у каждого класса модуля должен быть метод (InvokeNode) SetDefaultTimeout(), т.е. в Вашем случае нужно вызвать его на ltr34api после Open и до начала приема.

Алексей, спасибо.
Установил, посмотрел - теперь на LTR34_Recv тратится меньше времени.
Правильно я понимаю, что теперь при timeout=0 я должен указать size и размерность Data, равными [ожидаемому_кол-ву_слов]+[некоторый_запас]?
А то я на прошлой неделе почему-то подумал, что могу поставить timeout=1, а Data/size бесконечно большими и тогда Recv просто вернет то кол-во слов, которое успела принять за 1 мс. А возникло такое ощущение, что Recv просто вычитывала всё, что есть, т.е. времени это занимало больше.