Форум:

Вы не вошли.

 Поиск | Регистрация | Вход 

#1 Re: Техническая поддержка » LTR-114, ошибка -10010 Неверный номер канала » 06.06.2019 08:52:06

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

#2 Re: Техническая поддержка » LTR-114, ошибка -10010 Неверный номер канала » 05.06.2019 09:17:05

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

Спасибо

#3 Re: Техническая поддержка » LTR-114, ошибка -10010 Неверный номер канала » 30.05.2019 16:02:56

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

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

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

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

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

#4 Re: Техническая поддержка » LTR-114, ошибка -10010 Неверный номер канала » 30.05.2019 08:21:53

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

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

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

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

Спасибо.

#5 Re: Техническая поддержка » LTR-114, ошибка -10010 Неверный номер канала » 29.05.2019 14:11:07

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

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

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

Спасибо.

#6 Re: Техническая поддержка » LTR-114, ошибка -10010 Неверный номер канала » 28.05.2019 15:45:50

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

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

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

#7 Re: Техническая поддержка » LTR-114, ошибка -10010 Неверный номер канала » 28.05.2019 15:27:06

А проблема возникает именно при обработке первого принятого блока данных? Или сколько-то приемов проходит успешно и возникает уже потом?

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



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

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

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

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

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




Прием с модулей LTR27 запускается одновременно (до или после) с LTR114? При этом как я понимаю ошибок при обработке данных от LTR27 не наблюдается никогда?

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

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

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

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

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

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


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

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


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

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

Спасибо.

#8 Re: Выбор оборудования » Как оценить погрешность LTR27? » 28.05.2019 14:43:45

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

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

Пределы допускаемой основной приведённой погрешности для модуля измеритель-
ного LTR27 с преобразователями H -27U.... ,  % ±0,05

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

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

Спасибо.

#9 Re: Выбор оборудования » Как оценить погрешность LTR27? » 28.05.2019 08:27:17

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

Вынуждены вернуться к теме обсуждения 6-летней давности  smile

Пож. поясените: почему Ваши расчеты из данной ветки форума

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}

#10 Re: Техническая поддержка » LTR-114, ошибка -10010 Неверный номер канала » 28.05.2019 08:02:21

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

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

Спасибо.

#11 Техническая поддержка » LTR-114, ошибка -10010 Неверный номер канала » 27.05.2019 16:11:25

Леонид
Ответов: 16

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

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

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

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

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

Спасибо.

#12 Техническая поддержка » Поверка крейтовой системы LTR: вместе с крейтом или модули отдельно? » 06.12.2018 07:53:30

Леонид
Ответов: 1

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

В документе Установки измерительные LTR "Методика поверки" вроде бы нет требования отправлять на поверку модули LTR совместно с крейтом.

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

Пож. поясните: какие имеются преимущества/недостатки, если отправлять к вам на поверку крейт совместно с модулями, которые нужно поверить.
На сколько принципиально получить отметку о поверке в Паспорте на крейт?

Спасибо.

#13 Техническая поддержка » Определение обрыва термопары » 20.05.2017 06:45:05

Леонид
Ответов: 3

Используем LTR-27 с субмодулями H-27Т для измерения напряжения с датчиков - термопар.

Есть ли возможность определить сбой измерения в случае обрыва термопары?

Спасибо.

#14 Re: Техническая поддержка » LTR114 в режиме измерения сопротивления » 05.05.2017 14:14:17

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

#15 Re: Техническая поддержка » LTR114 в режиме измерения сопротивления » 04.05.2017 05:40:34

Вы правы: дочитали руководство до п.16.4

В нашем случае наиболее частый случай неисправности - не подключение термо-сопротивления или поломка датчика.

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

#16 Техническая поддержка » LTR114 в режиме измерения сопротивления » 27.04.2017 05:45:17

Леонид
Ответов: 6

Используем LTR-114 для измерения сопротивления термометров сопротивления (типа П-109).

Когда к 8-ми каналам модуля LTR-114 подключено 8 датчиков - результаты измерения нормальные.

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

Т.о. нам не удается определять:
- подключен ли датчик термо-сопротивления;
- исправен ли подключенный датчик.

Пож. сообщите: у нас ожидаемый режим работы LTR-114 или что-то не так?

Если ожидаемый, как можно решить проблему оценки состояния датчика?

Спасибо.

#18 Re: Техническая поддержка » ltrd: Ритмичность приема измеренных данных » 28.12.2016 17:00:29

Вас понял так, что на один канал 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(); ?

Спасибо.

#19 Re: Техническая поддержка » ltrd: Ритмичность приема измеренных данных » 28.12.2016 09:25:38

В посте #42 приведены данные тестирования модулей LTR27. Для них в массив tmark[] при приеме счетчиков метки "Старт" помещаются одинаковые значения для каждого канала ( видимо потому, что каналы работают параллельно ).

Для модуля LTR114 в массив tmark[] поступают разные значения счетчика метки "Старт" потому что каналы работают последовательно?

А при 4-х проводной схеме подключения (8 каналов ) элементы массива tmark[0] и [1] - для первого канала, [2] и [3] для второго канала и т.д. ? (приходят попарно одинаковые значения ).

И еще вопрос: для LTR27 задержка , рассчитанная по меткам "Старт", от момента измерения до поступления данных в ПК cоставляет до 1/5 периода измерения ( при периоде 10мс задержка до 2 мс ).

Почему для LTR114 таким же образом рассчитанная задержка составляет около одного периода измерения? (  при периоде 10мс задержка до 10-12 мс )! Как это можно объяснить? Спасибо.

#20 Re: Техническая поддержка » ltrd: Ритмичность приема измеренных данных » 27.12.2016 10:26:55

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

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

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

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

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

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

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

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

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

#21 Re: Выбор оборудования » Частота ввода с LTR41 » 17.12.2016 05:30:07

Увидел информацию в "Автоматизация в промышленности" том 4 стр 39 2016г. В ней говорится об экспериментально установленной задержке 50-70мс между выдачей команды от ПК в крейт на модуль LTR42 и реальным исполнением этой команды модулем LTR42.

Как можно объяснить высокую скорость поступления данных из LTR41 в ПК и большую задержку передачи команды на вывод от ПК в LTR42?

#22 Re: Техническая поддержка » ltrd: Ритмичность приема измеренных данных » 15.12.2016 16:17:56

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

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

#23 Re: Техническая поддержка » ltrd: Ритмичность приема измеренных данных » 14.12.2016 15:25:15

У Вас интересное предложение, будем осмысливать.

Или же, если найти точный внешний генератор прямоугольного сигнала 10кГц и подать его на разъем метки "Старт" крейта, то дорабатывать ПО крейта и API модулей не понадобится?..

Жаль что LTR-43 не программируется на бесконечную генерацию меандра заданной частоты. А 1 канал LTR-34 вроде бы можно под данную нужду использовать?!

#24 Re: Техническая поддержка » ltrd: Ритмичность приема измеренных данных » 11.12.2016 08:07:42

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

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

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

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

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

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

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

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

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

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

#25 Re: Техническая поддержка » ltrd: Ритмичность приема измеренных данных » 07.12.2016 18:30:08

Извините, не могу понять Ваше предложение.

Положим, имею один крейт и в нем один многоканальный модуль.

По LTR***_Recv() получаю очередную порцию измерений  по каждому каналу модуля. Системной ф-цией ftime() сразу после LTR***_Recv() могу "привязать" результаты  к текущему времени ПК с точностью до миллисекунды и отдать результаты другим программам проекта, работающим в реальном времени. Другие программы будут использовать текущий результат по своему усмотрению ( расчеты, вывод на экран, анализ аварий, постоянная запись, мнемосхемы с программами управления и т.д.).

Но стало понятно, что период поступления измерений плавает в диапазоне -+2мс. Т.е. привязка результата к текущему времени ПК (вместо получения результата вместе с внутренним временем крейта ) будет с этой ошибкой -+2мс.

Как мне могут помочь подмешанные в поток данных "секундные" метки чтобы устранить ошибку -+2мс каждого отсчета?

Контакты

Адрес: 117105, Москва, Варшавское шоссе, д. 5, корп. 4, стр. 2

Многоканальный телефон:
+7 (495) 785-95-25
Факс: +7 (495) 785-95-14

Отдел продаж: sale@lcard.ru
Техническая поддержка: support@lcard.ru

Время работы: с 9-00 до 19-00 мск

L-CARD в проектах