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

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

При работе с новым 16-ти позиционным крейтом, в котором установлены несколько модулей LTR114
иногда возникает ошибка

LTR114_ERR_ADCDATA_CHNUM -10010 Неверный номер канала в массиве данных от модуля

Ошибка возникает сразу по нескольким (2..4) модулям

Пож. подскажите возможную причину этого сбоя, на что нужно обратить внимание?

Спасибо.

Здравствуйте, Леонид.
- Сообщите полное название крейта (см. его этикетку сзади крейта) и его серийный номер. 
- По какому интерфейсу работаете: Ethernet или USB?
- Какая суммарная скорость передачи данных от модулей крейта?  - К модулям в крейте?
- С каким ПО работаете?

- Сообщите полное название крейта (см. его этикетку сзади крейта) и его серийный номер. 

LTR-EU-8/16 серийным номер: 2T229738

- По какому интерфейсу работаете: Ethernet или USB?

Ethernet

- Какая суммарная скорость передачи данных от модулей крейта?  - К модулям в крейте?

В крейте смонтированы 9 модулей LTR27 и 6 модулей LTR114. В работе задействованы 6 модулей LTR27 и 6 модулей LTR114

Максимальная частота опроса 50Гц. Максимально возможный трафик 50Гц*12модулей*16каналов*24байт=230кБайт
в ту или другую сторону. Т.е. трафик небольшой, загрузка процессора ПК небольшая.

- С каким ПО работаете?
Работаем в ОС QNX4. Для работы в QNX4 взяли исходные тексты библиотеки работы с LTR-крейтом в QNX6 (адаптация в QNX6 проверена
специалистом  LCard). Далее испходные тексты скомиплированы в QNX4 компилятором Watcom10.6.

Проблема наблюдается при первом включении ПК и крейта из состояния "Выключено"
после долгого простоя.

При последующем выключении-включении или после перезагрузки программ ltrd и программ обслуживания модулей
проблема вроде как не повторяется.

На E-Mail техподдержки вышлю фото экрана ПК с представленной выше информацией.

Спасибо.

Добрый день.

А проблема возникает именно при обработке первого принятого блока данных? Или сколько-то приемов проходит успешно и возникает уже потом?
При этом Вы проверяете, что Recv() всегда возвращает столько, сколько запрашивали? Т.е. не может быть такого, что Recv() возвращает сперва меньше данных, из-за чего уже дальше данные начинают обрабатываться не выравненные на кадр, вызывая постоянные ошибки обработки?
Прием с модулей LTR27 запускается одновременно (до или после) с LTR114? При этом как я понимаю ошибок при обработке данных от LTR27 не наблюдается никогда?

Правильно ли я понимаю, что во время работы (если не было простоя) данная проблема никогда не наблюдается? Насколько часто воспроизводится после простоя? Если был выключен только крейт, а ПК работал, то проблема воспроизводится? Крейт у

Какая версия прошивки процессора у крейта?

Есть ли возможность сохранить в файл массив необработанных данных (из Recv()), который привел к возникновению ошибки и предыдущий (если был и это не первый)?

На Вашем оборудовании только QNX или потенциально возможно загрузить для тестирования и Windows?

Мне кажется, что первые опросы модулей LTR-114 идут без сбоев. Сбой может возникнуть через 10-20 секунд после начала работы с крейтом, а может и не возникнуть вовсе.

После LTR114_Recv() проверка числа принятых данных (возврат из функции) и числа запрошенных данных выполняется, и при не соответствии выводится текстовым сообщением в консоль. Но если и выведется - то сразу потеряется за другими текстовыми сообщениями с расшифровкой ошибки, так что не могу пока точно ответить.

Правильно ли я понял, что смысл Вашего предположения таков, что если мы потеряли какую-то часть данных их модуля, то для последующих данных все время будет происходить сдвиг и ошибка в номере канала в массиве данных от модуля?

Стоит ли тогда, при обнаружении не соответствия числа запрошенных и принятых данных
- остановить измерения LTR114_Stop()
- закрыть работу с модулем LTR114_Close()
- выйти из цикла опроса в начало программы и заново инициализировать этот модуль начиная
с LTR114_Init()
и далее LTR114_Open() и т.д.?

Можно ли при этом сказать что мы повысили надежность опроса ? )

ДА, прием с модулей LTR27 запускается одновременно до запуска опроса LTR114 и при этом ошибок от LTR27 не наблюдается.

Пока наблюдение такое, что проблемы после длительного простоя. Несколько перезагрузок программ опроса или выключение-включение
всего оборудования - и начинается стабильная работа программ+крейта.

Признаться, у нас в проекте два ПК (Пром-компьютера) и 2 крейта. Каждый ПК опрашивает свой крейт. Иногда проблемы
происходят и со вторым крейтом ( там LTR-51 и LTR22 ). По LTR-51 (при ошибке) и выводится несоответствие принятых и запрошенных данных.
Все ПК и крейты подключены через многопортовый коммутатор MOXA, а не прямым кабелем разъем в разъем, т.к. кроме обмена с крейтами по TCP/IP мы поддерживаем дублированную QNX-сеть через те же интерфейсы.

Пока ответить не могу, уже и забыл - где эту инфу нужно смотреть

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

Можно остановить опрос на QNX-ПК, подключить к коммутатору ноутбук с Windows. Или подключить ноутбук к крейту минуя коммутатор. Как посоветуете провести тесты под Windows?

Спасибо.

Извините, забыл уточнить:

во время сбоев наблюдаю периодическое включение индикатора "U" красным цветом. Это странно, т.к.
крейт настроен на обмен по Ethernet и USB кабель в к нему физически не подключен.

Почему же тогда индикатор "U" на некоторое время загорается красным, потом желтым и опять несколько секунд красным?

Да, я это имел ввиду. Для начала стоит этот факт зафиксировать, затем можно попробовать сделать повторный Recv() чтобы допринять данные с большим таймаутом, после доприема можно сделать ProcessData на суммарный кадр. Если выполнится успешно и дальше пойдет сбор, то это будет означать, что это не сбой в данных, а по сути какая-то существенная задержка во времени их доставки, сами данные при этом корректны. Если же после этого ProcessData() возвращает ошибку (или изначально не было проблемы в недостаточном Recv()), значит все же сбой данных и можно попробовать сделать цикл перезапуска в виде Stop(), Start(), посмотреть восстановится ли при этом прием. Вариант Stop()-Close()-Open()-SetADC()-Start() более глубокого перезапуска с полным сбросом и перенастройкой модуля, если предыдущий вариант не поможет.
В общем результат таких попыток перезапуска может дать какую-то информацию, что произошло на уровне потока данных.

По версии прошивки крейта - под Windows/Linux ее можно посмотреть в программе LTR Manager (или в ltrapi LTR_GetCrateDescr() если функция была уже в той версии для qnx). Не помните, Вам не высылали прошивки крейта для обновления?

Про индикатор важное дополнение, действительно это не нормальное поведение. При этом за исключением моментов сбоя индикатор работает нормально?

Леонид,  я бы в экспериментах на всякий случай исключил бы коммутатор как лишнее неизвестное. Уже были случаи, что с коммутатором критично возрастала вероятность переповторов пакетов из-за отбрасывания пакетов коммутатором.

Готов сообщить версии прошиок LTR-крейтов LTR-EU-8/16 c серийными номерами 2Т229738 и 2T229739

Версия прошивки 2.0.0.0
...
Версия прошивки... 1.00.08( build 15.02.10 )

Пож. поясните: по какой причине (если нужно конечно) следует обновить прошивку крейтов и как это сделать?

Спасибо.

Леонид, для Вашей версии оборудования крейта прошивка 1.00.08 является правильной.
Заданный выше вопрос является важным диагностическим признаком: Не наблюдается ли мерцание индикаторов, или другое неправильное поведение индикаторов, при нормальной работе крейта? Состояния индикаторов описаны в http://www.lcard.ru/download/ltr.pdf , п.3.2.3 , стр. 46.
Желто-оранжевый цвет получается смешанным свечение двухцветных красно-зелёных светодиодов.

Здравствуйте, Александр!

Спасибо за Ваш комментарий.

Вроде бы при ненормальном  промигивании красным цветом лампочки U на cоседнем стенде велись сварочные работы.

На какие моменты электрического притания LTR-крейтов и работающих с ними коммутатора сетевого и ПК Вы рекомендуете обратить особое внимание?

Спасибо.

Леонид. С этого места подробнее, пожалуйста... И эти же сварочные работы сопровождали сбой данных от LTR114? Без сварочных работ сбоев нет и состояние индикаторов правильное?

- Если оборудование не заземлено, то встроенные сетевые фильтры оборудования не могут выполнять полноценно своих функций фильтрации кондуктивных помех от сети ~220 В.
- Я допускаю, что существует дешёвое сетевое оборудование с плохими сетевыми фильтрами (или без фильтров вообще), а также с плохим качеством гальванической развязки Ethernet (или без гальваноразвязки вообще!), а также с экономной архитектурой, при которой существует повышенная вероятность отбрасывания пакетов коммутатором, а также существуют ограничения с реализацией полнодуплексного режима. С другой стороны, известно, что в режиме выделенной сети с ПК ("точка-точка") режим передачи практически всегда устанавливается полнодуплексным.

Сейчас у нас проводятся возможные мероприятия по улучшению электрического питания и заземления системы измерения.

Так же у нас питание электрическое ПК и LTR-крейтов производится через UPS APC SRT 2200.

В качестве сетевого коммутатора используется MOXA IKS-6728A. По опыту эксплуатации этого коммутатора в трех других проектах:  потери пакетов от LTR-крейтов мы не наблюдаем.

Будем наблюдать далее и при возникновении проблем проверять: происходит ли по-близости сварка и каким цветом горят индикаторы LTR.

Cпасибо за поддержку.

Наблюдения с загоранием красной лампочки U при работе с LTR-крейтом по Ethernet.

Наблюдения выполняется в лабораторных условиях, сварки поблизости нет. ОС QNX4.

1.1 Включается электрическое питание крейта, лампочки E и U зеленые
1.2 Запускатеся ltrd --config-file=ltr3.xml
1.3 по netstat -an наблюдается два сетевых соединения между ltrd и крейтом, состояние ESTABLISHED
1.4 выключается электрическое питание крейта (лампочки E и U погасли
1.5 по netstat -an наблюдается два сетевых соединения между ltrd и крейтом, состояние FIN_WAIT1
1.6 программа ltrd снимается с исполнения
1.7 по netstat -an остаются два сетевых соединения между ltrd и крейтом, состояние FIN_WAIT1
1.6 Включается электрическое питание крейта, лампочки E и U cперва заленые.
1.7 наблюдается периодическое загорание лампочки U красным цветом на 2-3 секунды.
1.8 наблюдается большой трафик по сетевой плате (никакие программы через сеть не обмениваются данными),
видимо трафик между подсистемой Tcpip QNX4 и крейтом.
1.9 по netstat -an остаются два сетевых соединения между снятым с исполнения ltrd и крейтом, состояние остается FIN_WAIT1 долгое время

дальнейший старт ltrd, программ обслуживания модулей приводит к ошибкам при обмене, загораниям лампочки U красным.
если перезапустить подсистему Tcpip , то сетевые соединения в состоянии FIN_WAIT1 исчезнут и работа с крейтом восстановится
в нормальном режиме.

Интересно, что в ОС QNX6 аналогичные действия не приводят к красной лампочке U и проблем после выключения и включения крейта не наблюдается.

Заранее согласен, что выключение и включение крейта - это нестандартное действие. Думаю , если удасться "убивать" FIN_WAIN1(2) соединения, то проблема будет решена.

И все-таки: почему в QNX4 крейт "плохо"  реагирует на соединения с FIN_WAIT1?

Спасибо

А в QNX4 есть какой-то аналог Wireshark для перехвата сетевого трафика? Вообще выглядит странным. То что сокеты в этом состоянии - это нормально. Состояние соответствует не получению пакета закрытия от удаленной стороны (так как крейт вырубился принудительно, то он и не смог корректно закрыть сокеты).
Единственное, что если предположить, что QNX пытается что-то дослать по этим не до конца закрытым сокетам и это как-то влияет на крейт...
И все же версию прошивки желательно посмотреть (можно и под Windows в LTR Manager)

Версия прошивки крейта 1.00.08. Выше подтверждена как правильная.