Сообщения от Николай С

Николай С · Техническая поддержка

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

Николай С · Техническая поддержка

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

Николай С · Техническая поддержка

Алексей L Card пишет:

Если код верный, то эта ошибка свидетельствует о том что буфер канала связи между программой и 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, например), то ничего не выйдет.

Николай С · Техническая поддержка

Алексей L Card пишет:

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

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

Николай С · Техническая поддержка

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

Российский производитель и разработчик сертифицированного измерительного оборудования с 1987 года

Форум

#1 Re: Техническая поддержка » Модуль LTR34. Ошибка -44. » 05.08.2020 12:07:38

#2 Re: Техническая поддержка » Модуль LTR34. Ошибка -44. » 04.08.2020 19:26:43

#3 Re: Техническая поддержка » Модуль LTR34. Ошибка -44. » 30.07.2020 16:35:33

#4 Re: Техническая поддержка » Модуль LTR34. Ошибка -44. » 29.07.2020 13:54:58

#5 Техническая поддержка » Модуль LTR34. Ошибка -44. » 29.07.2020 12:36:43

Контакты

Быстрые ссылки

Связь с техподдержкой