Форум

Наблюдения с загоранием красной лампочки 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?

Спасибо

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

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

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

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

Спасибо.

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

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

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

Я простодушно считал, что чем выше эффективная разрядность (идеального АЦП), тем ниже погрешность измерения.

В Описании Типа (лист №13)  написано, что 

и не написано, что данная погрешность соответствует частоте измерения 5Гц. В прошлом проекте (2013-2014год) отсутствие этого сведения стало для нас проблемой и потребовало разбирательства.

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

Спасибо.

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

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 техподдержки вышлю фото экрана ПК с представленной выше информацией.

Спасибо.

Спасибо, результаты измерений в Специальном режиме подтвердили Ваши выкладки.

Вас понял так, что на один канал LTR114 всегда приходится 2 элемента в tmark с одинаковым значением счетчика.

Т.к. я за один вызов LTR114_Recv() получаю отсчеты по всем активным каналам, то буду считывать все метки tmark[2][число каналов] и для каждого канала принимать свое значение счетчика "Старт".

Осталась такая проблема:один раз за ( примерно ) каждые 30 cекунд с LTR114 происходит очень большая разница между реальным временем по tmark и временем поступления данных в ПК (примерно 300-500мс).

Вроде все требования по отмене периодической автокалибровки выполнил:

conf.Interval = 0 ,
conf.SyncMode = LTR114_SYNCMODE_INTERNAL, перед
LTR114_SetADC(&conf);

далее однократно вызываю
LTR114_Calibrate(&conf);

потом LTR114_Start(&conf);

после приема порции данных вызываю
LTR114_ProcessData(&conf, recv_data, proc_data, &size,
LTR114_CORRECTION_MODE_INIT, LTR114_PROCF_VALUE);

В чем еще может быть причина редкой периодической "длинной" задержки LTR114?

Может ли быть причиной отсутствие вызова LTR114_GetConfig(); перед LTR114_SetADC(); ?

Спасибо.

Тестируется такое решение:
В ПК с ОС реального времени (QNX6) установлен интерфейс с дискретными выводами ТТL-уровня.

В принципе, дискретный сигнал можно формировать с помощью последовательного или параллельного интерфейса любого ПК.

Один дискретный вывод подключен к сигналу DIGIN1 каждого крейта.
После старта ltrd и программ обслуживания модулей крейта запускается нить выдачи дискретных импульсов ( с высоким приоритетом).

Сперва однократно в "глухом" цикле производится ожидание смены секунды. В момент смены секунды настраивается и запускается таймер ОС реального времени.
Время до первого срабатывания таймера настраивается с компенсацией "проскакивания" при смене секунды ( случайное значение от 0 до 200 мкс). Последующие срабатывания таймера настраиваются на период 500мкс. При каждом срабатывании таймера производится выдача дискретного сигнала в "1" и сразу в "0". Время выдачи высокого уровня "1" составляет 4 мкс.

При приеме данных каждый модуль принимает значение метки "Старт" и по числу импульсов определяет время реального измерения как число микросекунд текущих ЧЧ:ММ:СС.

Тесты показывают, что задержки от реального измерения до доставки данных в ПК могут составить 500...3500мкс.
Т.о. точность определения реального времени измерения может составить до 500мкс.

Можно настроить ticksize часов реального времени ОС на величину 100мкс и выдавать импульсы через 100мкс.  При этом точность определения реального времени измерения - до 100мкс. Но растут накладные расходы на функционирование ОС  примерно на 15% от доступных ресурсов ПК.

Выбор зависит от требований прикладной задачи...

Спасибо за полезные советы.

Спасибо за критические комментарии, использовать LTR34 для выдачи меток "Старт" - не лучшее предложение.

{рекламный контекст удалён}

Следую Вашей рекомендации, перечитываю п. 4.7 РЭ и Ваш пост #26.

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

Буферировать данные не представляется возможным: обработка данных проходит в реальном времени их возникновения.

Ваше предложение по уточнению времени очередной порции данных  реализуемо:

- если очередная порция пришла через время <=20мс от предыдущей порции - присвоить ей время поступления данных в ПК;

- если очередная порция пришла через время > 20 мс от предыдущей порции - присвоить ей время поступления данных в ПК минус время возникшей задержки от 20-ти мс.

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

Для этого можно предусмотреть API-функцию занесения в крейт точного времени из host-ПК.

М.б. в будущем разработать модуль получения точного времени через GPS.

Тогда крейтовая система LTR была бы поставщиком измеренных данных с привязкой к реальному времени их сбора . В т.ч. при получении данных по длинным сетям через Internet.