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

Добрый день.
При работе с модулем LTR34 через LabVIEW периодически возникает ошибка с кодом -44 и весь крейт зависает. При сбросе крейта и установке тех же параметров ошибки не возникает. Не могли бы вы подсказать, в чём её причина и как этого избежать?

Добрый день.
Чтобы что-то ответить, нужно знать больше информации. По какому интерфейсу работаете с крейтом (USB/Ethernet), как настраиваете модуль, что передаете. Желательно пример программы, которая приводит к возникновению ошибки.
Также не совсем понятно, что именно подразумевается под "весь крейт зависает". Видится ли он при этом в LTR Manager?

Подключение через USB интерфейс. Программа на основе примеров в ltr34api_labview. Появляется ошибка в Invoke Node для ltr34api ProcessData или в Send. Установки следующие - многоканальный режим (4 канала), выход 1:1, уст. амплитуда 1.4 В, тип сигнала - синус, частота АЦП 3000 Гц, режим stream. После появления этой ошибки (код -44) на другие команды модуль и крейт не реагирует. В LTR Manager его видно, поэтому и получается выполнить его сброс. Сделал бы это программно, но не нашёл в какой библиотеке это можно сделать. Проблема ещё в том, что после сброса всё работает нормально, т.е. отправляю те же данные и модуль их адекватно воспринимает, но через какое то время ошибка может повториться. Возможно проблема во внутренней прошивке самих модулей.

Если код верный, то эта ошибка свидетельствует о том что буфер канала связи между программой и ltrd для данного модуля полностью заполнен и из-за чего возможности послать нужную команду.
Правда в Send или тем более ProcessData возможности возвращения этой ошибки я не нашел, т.к. Send количество слов возвращает явно и в этом случае просто оно будет меньше запрошенного size, но не приведет к ошибке, а ProcessData вообще никаких данных не посылает.  Данная ошибка возможна в вызовах Stop/Start/Config.
В любом случае, если код ошибки правильный, то к заполнению канала может приводить вызов Send без контроля частоты вызова при малой частоте генерации ЦАП. Если 3000 Гц это она и есть (хотя вроде она минимальная 3906.5 ?), то это как раз Ваш случай. С данной частотой если буфер обмена заполнен отсчетами, то команда останова будет поставлена в очередь за ними, и при такой частоте она до модуля может дойти за очень долгое время.
При низких частотах генерации лучше явно контролировать заполненность буфера по эхо сигналу, как показано в примере ltr34_stream_fifo_ctl из https://www.lcard.ru/download/examples/ … abview.zip.
По поводу сброса через LTRManger, то эта функция доступна через управляющее соединение с службой, есть пример для LabView: https://www.lcard.ru/download/examples/ … _reset.zip.

Спасибо за ответ, вероятно ошибка действительно была в Config. Как оказалось в модулях LTR34-8 такая ошибка не появляется, только в LTR34-4, либо дело в прошивке самих модулей, пока мало данных чтоб говорить однозначно, но в 8 модификации она не наблюдалась.
Как я понял на частоту ЦАП повлиять вообще не получится, она устанавливается в зависимости от количества каналов, я говорил про частоту самого сигнала, который идёт с выходов модуля. По поводу эхо сигнала - он был активирован как это сделано в примере, но это не помогло, возможно ошибка была именно в момент изменения режима с circle на stream, попытаюсь это проверить. Есть ли возможность писать команду не в конец буфера, а в начало, чтоб приоритетно останавливать обмен данными?
По поводу примера для сброса - в нём происходит сброс модуля, а это не помогает - зависает весь крейт, со всеми модулями в нём, т.е. даже если я после этой ошибки попытаюсь подключиться к другому модулю в крейте (LTR27, например), то ничего не выйдет.

Добрый день.
После многочисленных тестов выяснил, что зависания крейта (именно всего крейта, а не только модуля) происходят именно с модулем LTR-34-4 при работе в режиме STREAM по всем четырём каналам. Помогает при этом только сброс крейта, как на картинке. К сожалению, ни перезагрузка службы, ни сброс модуля ни к чему не приводят. Не могли бы вы подсказать, как сделать сброс как на картинке через LabVIEW? Текущая версия ltrModulesNet - 1.4.14.0

Здравствуйте.
Сообщите серийные номера обоих модулей LTR34.

Вообще, логически модули LTR34-4 и LTR34-8 идентичны, они имеют одинаковую прошивку CPLD, которая не менялась с марта 2010 г....
Если в одном и том же крейте, при одном и том же ПО, при одних и тех же программных настройках, проблема возникает с одним из модулей,  то либо этот модуль выпущен до марта 2010 г. (это будет понятно по серийному номеру), либо проблеммный модуль, возможно, неисправен. Неисправность модуля желательно подтвердить с нашим ПО. Вы можете оба модуля протестировать  в одном и том же крейте с помощью тестового ПО LTRTEST2 и сообщить результат?

Отредактировано Инженер (04.08.2020 22:14:02)

Тут два крейта LTR-EU-2-5, в составе каждого модуль LTR27 в первом слоте и LTR-34-4 во втором слоте.
Серийный номер первого крейта - №1R813476 2009 г. выпуска. Серийный номер модуля LTR-34-4 в нём - 3R752151.
Серийный номер второго крейта №2D047709 2010 г. выпуска. Серийный номер модуля LTR-34-4 в нём - 3R752160.
При попытке запуска теста LTRTEST2 возникла следующая проблема - если нажать кнопку "Найти крейты" то он сразу же крейт находит, но при этом поле с номером горит красным цветом и поля "Слот" и "Модуль" не заполнены. Если запустить тест то написано что он запущен, но ничего не происходит при этом - ни в течении минуты, ни дольше.

Николай, все эти изделия выпущены более 10 лет тому назад. Это означает, что средний предполагаемый срок службы этих изделий уже истёк - требуется либо ремонт, либо замена.  По поводу ремонта и его целесообразности:  https://www.lcard.ru/support/faq/units_repair
Организационные стороны вопроса, пожалуйста, уточняйте с нашим отделом продаж. Если будете передавать в ремонт, обязательно сошлитесь на эту тему форума.