Меню
![Главная](https://www.lcard.ru/sites/default/files/Logo.jpg)
+7 (495) 785-95-25
sale@lcard.ru
sale@lcard.ru
Версия прошивки крейта 1.00.08. Выше подтверждена как правильная.
Наблюдения с загоранием красной лампочки 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?
Спасибо
Сейчас у нас проводятся возможные мероприятия по улучшению электрического питания и заземления системы измерения.
Так же у нас питание электрическое ПК и LTR-крейтов производится через UPS APC SRT 2200.
В качестве сетевого коммутатора используется MOXA IKS-6728A. По опыту эксплуатации этого коммутатора в трех других проектах: потери пакетов от LTR-крейтов мы не наблюдаем.
Будем наблюдать далее и при возникновении проблем проверять: происходит ли по-близости сварка и каким цветом горят индикаторы LTR.
Cпасибо за поддержку.
Здравствуйте, Александр!
Спасибо за Ваш комментарий.
Вроде бы при ненормальном промигивании красным цветом лампочки U на cоседнем стенде велись сварочные работы.
На какие моменты электрического притания LTR-крейтов и работающих с ними коммутатора сетевого и ПК Вы рекомендуете обратить особое внимание?
Спасибо.
Готов сообщить версии прошиок LTR-крейтов LTR-EU-8/16 c серийными номерами 2Т229738 и 2T229739
Версия прошивки 2.0.0.0
...
Версия прошивки... 1.00.08( build 15.02.10 )
Пож. поясните: по какой причине (если нужно конечно) следует обновить прошивку крейтов и как это сделать?
Спасибо.
Извините, забыл уточнить:
во время сбоев наблюдаю периодическое включение индикатора "U" красным цветом. Это странно, т.к.
крейт настроен на обмен по Ethernet и USB кабель в к нему физически не подключен.
Почему же тогда индикатор "U" на некоторое время загорается красным, потом желтым и опять несколько секунд красным?
А проблема возникает именно при обработке первого принятого блока данных? Или сколько-то приемов проходит успешно и возникает уже потом?
Мне кажется, что первые опросы модулей LTR-114 идут без сбоев. Сбой может возникнуть через 10-20 секунд после начала работы с крейтом, а может и не возникнуть вовсе.
При этом Вы проверяете, что Recv() всегда возвращает столько, сколько запрашивали? Т.е. не может быть такого, что Recv() возвращает сперва меньше данных, из-за чего уже дальше данные начинают обрабатываться не выравненные на кадр, вызывая постоянные ошибки обработки?
После LTR114_Recv() проверка числа принятых данных (возврат из функции) и числа запрошенных данных выполняется, и при не соответствии выводится текстовым сообщением в консоль. Но если и выведется - то сразу потеряется за другими текстовыми сообщениями с расшифровкой ошибки, так что не могу пока точно ответить.
Правильно ли я понял, что смысл Вашего предположения таков, что если мы потеряли какую-то часть данных их модуля, то для последующих данных все время будет происходить сдвиг и ошибка в номере канала в массиве данных от модуля?
Стоит ли тогда, при обнаружении не соответствия числа запрошенных и принятых данных
- остановить измерения LTR114_Stop()
- закрыть работу с модулем LTR114_Close()
- выйти из цикла опроса в начало программы и заново инициализировать этот модуль начиная
с LTR114_Init()
и далее LTR114_Open() и т.д.?
Можно ли при этом сказать что мы повысили надежность опроса ? )
Прием с модулей LTR27 запускается одновременно (до или после) с LTR114? При этом как я понимаю ошибок при обработке данных от LTR27 не наблюдается никогда?
ДА, прием с модулей LTR27 запускается одновременно до запуска опроса LTR114 и при этом ошибок от LTR27 не наблюдается.
Правильно ли я понимаю, что во время работы (если не было простоя) данная проблема никогда не наблюдается? Насколько часто воспроизводится после простоя? Если был выключен только крейт, а ПК работал, то проблема воспроизводится? Крейт у
Пока наблюдение такое, что проблемы после длительного простоя. Несколько перезагрузок программ опроса или выключение-включение
всего оборудования - и начинается стабильная работа программ+крейта.
Признаться, у нас в проекте два ПК (Пром-компьютера) и 2 крейта. Каждый ПК опрашивает свой крейт. Иногда проблемы
происходят и со вторым крейтом ( там LTR-51 и LTR22 ). По LTR-51 (при ошибке) и выводится несоответствие принятых и запрошенных данных.
Все ПК и крейты подключены через многопортовый коммутатор MOXA, а не прямым кабелем разъем в разъем, т.к. кроме обмена с крейтами по TCP/IP мы поддерживаем дублированную QNX-сеть через те же интерфейсы.
Какая версия прошивки процессора у крейта?
Пока ответить не могу, уже и забыл - где эту инфу нужно смотреть
Есть ли возможность сохранить в файл массив необработанных данных (из Recv()), который привел к возникновению ошибки и предыдущий (если был и это не первый)?
Все программы - в наших руках в исходных текстах. Так что возможность в принципе есть. Не понятно, почему через некоторое время
работа стабилизируется...
На Вашем оборудовании только QNX или потенциально возможно загрузить для тестирования и Windows?
Можно остановить опрос на QNX-ПК, подключить к коммутатору ноутбук с Windows. Или подключить ноутбук к крейту минуя коммутатор. Как посоветуете провести тесты под Windows?
Спасибо.
Я простодушно считал, что чем выше эффективная разрядность (идеального АЦП), тем ниже погрешность измерения.
В Описании Типа (лист №13) написано, что
Пределы допускаемой основной приведённой погрешности для модуля измеритель-
ного LTR27 с преобразователями H -27U.... , % ±0,05
и не написано, что данная погрешность соответствует частоте измерения 5Гц. В прошлом проекте (2013-2014год) отсутствие этого сведения стало для нас проблемой и потребовало разбирательства.
В текущем проекте мы должны увеличить частоту измерения до 50Гц, поэтому и требуется Ваша точная оценка погрешности такого измерения с повышенной частотой.
Спасибо.
Здравствуйте, Александр!
Вынуждены вернуться к теме обсуждения 6-летней давности
Пож. поясените: почему Ваши расчеты из данной ветки форума
5 Гц - 12 бит
20 Гц - 11 бит
80 Гц - 10 бит
320 Гц - 9 бит
не совпадают с документом 422714-027-42885515 по ссылке http://www.lcard.ru/download/h-27x_manual.pdf,
где написано
...
1.2.5.Эффективная разрядность преобразования составляет 15 бит , 12 бит или 10 бит при времени измерения
150 мс , 20 мс или 5 мс соответственно .
...
В конечном итоге, какова погрешность измерения для субмодулей H-27+LTR27 при частоте опроса 50Гц?
Спасибо.
{цитируемые Леонидом расчётные значения обновлены, см. выше - 30.05.19}
- Сообщите полное название крейта (см. его этикетку сзади крейта) и его серийный номер.
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 техподдержки вышлю фото экрана ПК с представленной выше информацией.
Спасибо.
Здравствуйте!
При работе с новым 16-ти позиционным крейтом, в котором установлены несколько модулей LTR114
иногда возникает ошибка
LTR114_ERR_ADCDATA_CHNUM -10010 Неверный номер канала в массиве данных от модуля
Ошибка возникает сразу по нескольким (2..4) модулям
Пож. подскажите возможную причину этого сбоя, на что нужно обратить внимание?
Спасибо.
У нас в эксплуатации несколько LTR-крейтов 16-ти позиционных, наполненных разным составом LTR-модулей. которые нуждаются в периодической поверке.
В документе Установки измерительные LTR "Методика поверки" вроде бы нет требования отправлять на поверку модули LTR совместно с крейтом.
Считается, что удобнее извлекать модули из крейта и отпралять к вам на поверку только только модули (проще упаковать в небольшую коробку и перевезти). При этом отметка о поверке делается в Паспорте на каждый модуль.
Пож. поясните: какие имеются преимущества/недостатки, если отправлять к вам на поверку крейт совместно с модулями, которые нужно поверить.
На сколько принципиально получить отметку о поверке в Паспорте на крейт?
Спасибо.
Используем LTR-27 с субмодулями H-27Т для измерения напряжения с датчиков - термопар.
Есть ли возможность определить сбой измерения в случае обрыва термопары?
Спасибо.
Спасибо, результаты измерений в Специальном режиме подтвердили Ваши выкладки.
Вы правы: дочитали руководство до п.16.4
В нашем случае наиболее частый случай неисправности - не подключение термо-сопротивления или поломка датчика.
Возможно ли определять в Специальном режиме случай, если Rsrc стремится к бесконечно большому сопротивлению, а линии исправны?
Используем LTR-114 для измерения сопротивления термометров сопротивления (типа П-109).
Когда к 8-ми каналам модуля LTR-114 подключено 8 датчиков - результаты измерения нормальные.
Когда от любого одного (нескольких) каналов датчики отключаются, по каналам с подключенными датчиками результаты измерения по-прежнему нормальные, а по каналам с отключенными датчиками (концы кабелей висят в воздухе ), результаты измерения очень похожи по величине на результаты измерения по каналам с подключенными датчиками.
Т.о. нам не удается определять:
- подключен ли датчик термо-сопротивления;
- исправен ли подключенный датчик.
Пож. сообщите: у нас ожидаемый режим работы LTR-114 или что-то не так?
Если ожидаемый, как можно решить проблему оценки состояния датчика?
Спасибо.
Непредвиденной автокалибровки не происходит.
Извините.
Вас понял так, что на один канал 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(); ?
Спасибо.
В посте #42 приведены данные тестирования модулей LTR27. Для них в массив tmark[] при приеме счетчиков метки "Старт" помещаются одинаковые значения для каждого канала ( видимо потому, что каналы работают параллельно ).
Для модуля LTR114 в массив tmark[] поступают разные значения счетчика метки "Старт" потому что каналы работают последовательно?
А при 4-х проводной схеме подключения (8 каналов ) элементы массива tmark[0] и [1] - для первого канала, [2] и [3] для второго канала и т.д. ? (приходят попарно одинаковые значения ).
И еще вопрос: для LTR27 задержка , рассчитанная по меткам "Старт", от момента измерения до поступления данных в ПК cоставляет до 1/5 периода измерения ( при периоде 10мс задержка до 2 мс ).
Почему для LTR114 таким же образом рассчитанная задержка составляет около одного периода измерения? ( при периоде 10мс задержка до 10-12 мс )! Как это можно объяснить? Спасибо.
Тестируется такое решение:
В ПК с ОС реального времени (QNX6) установлен интерфейс с дискретными выводами ТТL-уровня.
В принципе, дискретный сигнал можно формировать с помощью последовательного или параллельного интерфейса любого ПК.
Один дискретный вывод подключен к сигналу DIGIN1 каждого крейта.
После старта ltrd и программ обслуживания модулей крейта запускается нить выдачи дискретных импульсов ( с высоким приоритетом).
Сперва однократно в "глухом" цикле производится ожидание смены секунды. В момент смены секунды настраивается и запускается таймер ОС реального времени.
Время до первого срабатывания таймера настраивается с компенсацией "проскакивания" при смене секунды ( случайное значение от 0 до 200 мкс). Последующие срабатывания таймера настраиваются на период 500мкс. При каждом срабатывании таймера производится выдача дискретного сигнала в "1" и сразу в "0". Время выдачи высокого уровня "1" составляет 4 мкс.
При приеме данных каждый модуль принимает значение метки "Старт" и по числу импульсов определяет время реального измерения как число микросекунд текущих ЧЧ:ММ:СС.
Тесты показывают, что задержки от реального измерения до доставки данных в ПК могут составить 500...3500мкс.
Т.о. точность определения реального времени измерения может составить до 500мкс.
Можно настроить ticksize часов реального времени ОС на величину 100мкс и выдавать импульсы через 100мкс. При этом точность определения реального времени измерения - до 100мкс. Но растут накладные расходы на функционирование ОС примерно на 15% от доступных ресурсов ПК.
Выбор зависит от требований прикладной задачи...
Спасибо за полезные советы.
Увидел информацию в "Автоматизация в промышленности" том 4 стр 39 2016г. В ней говорится об экспериментально установленной задержке 50-70мс между выдачей команды от ПК в крейт на модуль LTR42 и реальным исполнением этой команды модулем LTR42.
Как можно объяснить высокую скорость поступления данных из LTR41 в ПК и большую задержку передачи команды на вывод от ПК в LTR42?
Спасибо за критические комментарии, использовать LTR34 для выдачи меток "Старт" - не лучшее предложение.
{рекламный контекст удалён}
У Вас интересное предложение, будем осмысливать.
Или же, если найти точный внешний генератор прямоугольного сигнала 10кГц и подать его на разъем метки "Старт" крейта, то дорабатывать ПО крейта и API модулей не понадобится?..
Жаль что LTR-43 не программируется на бесконечную генерацию меандра заданной частоты. А 1 канал LTR-34 вроде бы можно под данную нужду использовать?!
Следую Вашей рекомендации, перечитываю п. 4.7 РЭ и Ваш пост #26.
В наших приложениях есть не очень быстрые измерения с частотой сбора 50Гц от всех модулей в крейте.
Буферировать данные не представляется возможным: обработка данных проходит в реальном времени их возникновения.
Ваше предложение по уточнению времени очередной порции данных реализуемо:
- если очередная порция пришла через время <=20мс от предыдущей порции - присвоить ей время поступления данных в ПК;
- если очередная порция пришла через время > 20 мс от предыдущей порции - присвоить ей время поступления данных в ПК минус время возникшей задержки от 20-ти мс.
Но наверное было бы лучше, если бы крейт сам присваивал временные метки ( с точностью до миллисекунды) порциям данных от каждого модуля в момент поступления их от модуля и до занесения из в большой FIFO буфер крейта.
Для этого можно предусмотреть API-функцию занесения в крейт точного времени из host-ПК.
М.б. в будущем разработать модуль получения точного времени через GPS.
Тогда крейтовая система LTR была бы поставщиком измеренных данных с привязкой к реальному времени их сбора . В т.ч. при получении данных по длинным сетям через Internet.
Извините, не могу понять Ваше предложение.
Положим, имею один крейт и в нем один многоканальный модуль.
По LTR***_Recv() получаю очередную порцию измерений по каждому каналу модуля. Системной ф-цией ftime() сразу после LTR***_Recv() могу "привязать" результаты к текущему времени ПК с точностью до миллисекунды и отдать результаты другим программам проекта, работающим в реальном времени. Другие программы будут использовать текущий результат по своему усмотрению ( расчеты, вывод на экран, анализ аварий, постоянная запись, мнемосхемы с программами управления и т.д.).
Но стало понятно, что период поступления измерений плавает в диапазоне -+2мс. Т.е. привязка результата к текущему времени ПК (вместо получения результата вместе с внутренним временем крейта ) будет с этой ошибкой -+2мс.
Как мне могут помочь подмешанные в поток данных "секундные" метки чтобы устранить ошибку -+2мс каждого отсчета?
Адрес: 117105, Москва, Варшавское шоссе, д. 5, корп. 4, стр. 2
Многоканальный телефон:
+7 (495) 785-95-25
Отдел продаж: sale@lcard.ru
Техническая поддержка: support@lcard.ru
Время работы: с 9-00 до 19-00 мск