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

Здравствуйте!

Столкнулись со странностями в работе модуля LTR35-8.

Симптомы. В процессе генерации вдруг на всех выходах устанавливаются напряжения, близкие к нулевым (но не точно нулевые, как это было бы при явном задании нулевых напряжений). Последующая (по логике работы программы) остановка генерации завершается ошибкой с кодом -19.

Если такое произошло, то временно помогает кратковременное выключение и включение питания модуля (крейта). Затем, через 2-3 часа непрерывной работы, проблема повторяется. И так до конца рабочего дня.

Длительный перерыв в несколько часов (до следующего рабочего дня и более) приводит к длительному исчезновению проблемы. Но затем такая проблема может повториться. Достоверно наблюдалось 3 таких серии проблем ("плохих" рабочих дня) с интервалом в несколько недель. И ещё несколько раз были подозрения, когда работа с модулем происходила не целый рабочий день, а только короткое время. Единичных эпизодов не наблюдалось (то есть или всё хорошо, или серия отказов).

В промежутках между сериями отказов, а также в настоящее время модуль работает без замечаний. Понять, в чём была разница в "плохие" и "хорошие" дни, не удалось.

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

А в журнале службы из LTR Manager на этот момент есть какие-то сообщения?

Ошибка -19 как правило возникает, в случае, если исчез признак наличия модуля, либо вообще весь крейт, в результате чего служба закрывает соединения с работающим с исчезнувшим модулем клиентом. Если это так, то соответствующие сообщения должны быть в журнале.

Если модуль пропадает на короткое время, то после его появления выполняется его сброс службой, и возможно это состояние с выходами близкими к нулевым этому и соответствует (при явном выводе нулей, с которым Вы сравниваете, у Вас калибровка используется? Если да, то калибровка компенсирует само смещение нуля ЦАП).

Не совсем понял про выключение питания крейта. А если его не отключать и просто переподключиться к модулю из программы, то что происходит? Модуль вообще виден в LTR Manger?

.

В LTR Manager я не смотрел - т. к. до ваших пояснений было непонятно, что и где искать, а эксперимент требовалось восстановить как можно скорее.
Переподключение к модулю без выключения и включения обратно питания крейта иногда помогало, иногда нет.
Калибровка используется.

Также расспросы сотрудников показали, что как минимум один раз наблюдалась серия отказов, когда модуль работал без подкачки данных (с использованием только циклического буфера и арифметических генераторов). И эти отказы прекратились, когда модуль после загрузки настроек и запуска генерации просто отключили от Ethernet.

Скорее всего вы правы и действительно модуль работает правильно, но почему-то происходит его сброс службой ltrd. Тогда возникает вопрос - возможно ли такое поведение ltrd отключить? Например, выводить информацию о потере и восстановлении связи с модулем и спрашивать о необходимости перезагрузки у пользователя.

Нет, если исчезает признак наличия модуля, то это как раз значит, что модуль НЕ работает нормально, при нормальной работе такого быть не должно. Нужно вначале определить по журналу? происходит ли кратковременное исчезновение модуля или же исчезновение крейта (а у Вас кстати стоит автоматическое переподключение по ошибке у IP-адреса в LTR Manager (флаг R)?). Если же одна из этих гипотез подтвердится, то уже искать ее причину, и возможно не в программной области (тем более что это проявляется и в режиме автогенератора)

Иногда не помогает переподключение к модулю, это что конкретно значит? Установка соединения, загрузка настроек и сигнала проходит успешно, но потом через какое-то время снова сигнал пропадает? Остальные функции всегда выполняются без ошибок, кроме описанного случая?

А какой именно используется крейт? Работаете Вы под Linux или под Windows с крейтом?

Конечно, необходим лог LTR-сервера от начала сеанса работы до возникновения проблемы. Может быть важным для диагностики состояние индикации крейта после возникновения проблемы. Также будут важны сведения о других экземплярах оборудования, если имеются.
Для диагностики LTR35 целесообразно использовать тестовое ПО. ПО LTR35TestGen - для диагностики функционала LTR35 и ПО  ltrtest2 - для тестирования интерфейса LTR. Были бы немаловажны также результаты тестирования по USB. Если с тестовым ПО проблема проявится, то тогда мы сможем увидеть её у себя при тех же условиях и локализовать.

На всякий случай сообщаю, что вскоре после предыдущего сообщения проблемы наблюдались ещё 2-3 раза, после чего исчезли и с тех пор ни разу не проявлялись. К сожалению, записать логи LTR-сервера до исчезновения проблемы мы не успели. Никаких специальных действий для устранения проблем не предпринималось, ПО и электрические схемы не менялись. Так что причины появления и исчезновения этих проблем остались неизвестными.

Кроме лога LTR-сервера, необходимого для анализа проблемы, следует обратить внимание:
- на состояние светодиодных индикаторов крейта при возникновении проблемы;
- на надёжность соединений в цепи подачи питания крейта;
- на возможное влияние анивирусного ПО;
- на возможную коллизию по IP-адресам компьютера или крейта в локальной сети, в которую подключен крейт;
- на возможное влияние тяжеловесных программных событий в операционной системе (обновления ПО, своппинг жесткого диска и т.д.);
- на температуру окружающего воздуха, когда возникает (и когда не возникает) проблема, если искать причину в плавающей термозависимой неисправности оборудования;
- на поведение второго комплекта оборудования в тех же условиях, если такой комплект имеется;
- на внешние электрофизические события в системе, которые могли резко ухудшить окружающую электромагнитную обстановку во время, когда проблема проявилась.