Добрый день, уважаемые!
Вопрос, как всегда, срочный и не совсем понятный.
Есть крейт на 8 мест. Среди прочих стоит модуль LTR-41.
Опрашивает концевики и разные дискретные датчики.
Опрашивали с помощью стандартной функции LTR41_ReadPort с частотой 20гц.
Все было хорошо, никаких ложных значений.
Решили его использовать в режиме потокового чтения данных. Для повышения разрешающей способности в постобработке данных массивов. И вот тут начались проблемы.
Модуль настроен на частоту чтения в 10000гц. При чтении ошибок не возникает.
При вызове процессдата ошибок тоже нет. Начинаем смотреть массив получаемых данных и видим ошибки. Если датчик до запуска имел значение 1, а затем в процессе чтения мы его изменили на 0. а потом спустя несколлько сек вернули обратно и можем снова повторить, то данные будут такими - начальное значение датчика читается правильно(в нашем примере это 1), а вот следущее состояние датчика(в нашем примере 0) читается не стабильным - цепочки 1 от 50-400 сэмплов, может и больше/меньше. Мы грешили сначала на дребезг контактов или "висящи" конец. Но, если до запуска чтения состояние было 0, то проблемы не стабильных значений уже возникали для состояния 1.
Что может быть? Куда рыть? Какие мысли? Может кто сталквался?
Заранее благодарен за ответы и внимание к вопросу.
Алекс

Здравствуйте.
Чтобы исключить причины, связанные с корректностью подключения, сообщите тип датчика, к которому подключен LTR41.  Желательна ссылка на документацию датчика. Опишите схему подключения датчика.  Это позволит сначала понять, обеспечивают ли поданные входные  напряжения-токи надёжные дискретные состояния входов LTR41.

Датчики разные, но все они управляют реле, а вот контакты реле уже коммутируют входа 41 модуля, с 5в.
Далее, при использовнии функции чтения порта все читается стабильно и только при потоковом чтении происходят непонятки. Еще часто секундные метки =0. Т.е. идет поток меток нормально, потом 0, потом снова нормально и опять 0. Какой-то взаимосвязи между ошибками чтения и ошибками меток не обнаружено

Завтра я попробую написать пример и проверить у себя работу данного режима.

Я попробовал данный режим и честно говоря не нашел проблем с данными. Выложил сюда пример https://bitbucket.org/lcard/ltr_cross_s … m_recv.zip. В bin - собранная версия. Можно изменить в ltr41_slot.txt номер слота, куда вставлен интересующий модуль и запустить ltr41_stream_recv_start.bat. Программа будет выводить значения входов и меток при изменении какого-либо из этих значений (метки или входов). В src лежат исходники примера.  Тогда попробуйте проверить на этой тестовой программе, как ведет себя модуль в Вашем случае...

А может быть какая-то аппаратная проблема? Сам модуль больной? Или крейт? Смотрю собираемые логи и в модулях ltr11 и ltr212 часто TimeMark метки чередуются с 0. Бывает даже долго границу прихода новой метки (новой секунды)  трудно найти.
Чем можно протестировать здоровье крейта и модуля на этот счет?
ЛГраф работает и показывает... Но там про метки что-то не припомню...
Пример попробую...

Запустил пример. после нескольких информационных строк вышла одна строка блок,позиция,биты,старт и секунда.
Я так понимаю должны печататься в потоке много строк при частой смене состояния на входах или раз в секунду при их отсутствии. Но выводится только одна.
Мало того - запускаю несколько раз уже в течении минут 20, а поле секунда показывает одну и тоже значение. Это баг в проге или крейт/модуль болеют?

Сообщите название крейта и его серийный номер.

Алексей, а пробовали брать этот поток и выводить в файл? Допустим как в нашем случае 10кгц и с временными метками (я так понимаю на каждый сэмпл идет метка. но она меяется при новой секунде и можно отлавливать лишь это измненение, а потом отсчитывать такты от этого изменения до нужного места в пределах секунды). У нас метки "бьются" чередуются с 0 причем и более секунды и часто затирая границыв прихода новой секунды (.  Может модуль битый? Но заменить и проверить не чем (  ил крейт так может себя вести? ил всеж программно это?

21.07.15 18:13:06.937] (0) SERVER: Starting up LTR-Server v1.5.4.1 (L-CARD)
[21.07.15 18:13:07.406] (3) CRATE_CTL: USB crate found: "LTR-EU-8/16"
[21.07.15 18:13:07.484] (3) CRATE_INIT: Connecting USB crate...
[21.07.15 18:13:07.500] (3) CRATE_INIT: Crate Info:
[21.07.15 18:13:07.500] (3) CRATE_INIT: + DeviceName = LTR030
[21.07.15 18:13:07.500] (3) CRATE_INIT: + SerialNumber = 2T185807

Вот пока писал на форуме, оставил включнной тестовую программу. Добавились 4 строчки вывода(это примерно минут 10 после старта проги)
и теперь выглядит так
---------------------------------------------------------
c:\Spring\bin>for /F %s in (ltr41_slot.txt) do set ltr41_slot=%s

c:\Spring\bin>set ltr41_slot=8

c:\Spring\bin>ltr41_stream_recv.exe 8
Модуль открыт успешно:
  Название:        LTR41
  Серийный номер:  2D776982
  Версия прошивки: 1.2
  Дата прошивки:   28.04.2008
Потоковый ввод запущен. Для останова нажмите любую клавишу
    Блок, позиция: Биты 16 - 1                     Старт  Секунда
       0,       0: 0 0 0 0 0 0 0 0 1 0 1 0 0 0 0 1     0      694
    5713,    3836: 0 0 0 0 0 0 1 0 1 0 1 0 0 0 0 1     0      694
    5713,    3837: 0 0 0 0 0 0 0 0 1 0 1 0 0 0 0 1     0      694
    6055,     291: 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 1     0      694
    6055,     292: 0 0 0 0 0 0 0 0 1 0 1 0 0 0 0 1     0      694

Как описано тут, то это не может объясняться проблемами крейта  (или модуля LTR41, если метки от него). Крейт высылает только слово метки раз в секунду и вставляет в поток. А массив tmark реально формируется при вызове LTRXXX_Recv() - из потока выкидываются найденные метки и увеличивается tmark для последующих отсчетов. Описанное поведение могу объяснить только какими-то проблемами в программе, если Вы обрабатываете часть массива tmark в который реально не были сохранены отсчеты. Я бы проверил везде ли Вы проверяете значение, которое возвращает LTRXXX_Recv() и обрабатываете только эту часть массива и связанные с этим действия. Корректность работы меток вообще можно проверить в статистике в LtrManager или LtrServer - если они увеличиваются при запуске секундных меток на 1 раз в секунду, то все реботает нормально и по-видимому ошибка при обработке массивов tmark при приеме

Данная программа сама не запускает секундные метки, а только запускает сбор и выводит данные при изменении. Так что если не запущены метки от другого источника, то вывод будет только при изменении входов (т.к. как я понял первичная проблема это некорректное значение входов). Соответственно если ничего не выводит значит на входах одни нули и ничего не меняется. В последнем выводе у Вас изначально были 1 на 1-м, 6-м и 8-м входах, это сохранялось довольно долго, а потом было одно изменение в 10-ой линии (на 1 измерение была 1, потом снова 0), а потом еще через некоторое время время на 6-ой линии стал 0 на одно измерение, а потом снова вернулась 1.

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

И да, если у Вас к 6-му входу и 10-му входу что-то реально подключено, то вопрос откуда были эти одиночные выбросы, вопрос скорее к подключению...

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

И еще уточнить по меткам.
Мы используем лтр42 и его функцию старта меток. Метки внутренние.
Скажите, массив меток в фунгкциях приема содержит метку для каждого принятого слова?вернее одного сэмпла одного канала данных. Т.е. для лтр212 при его двух словах на сэмпл, получаем массив данных длиной 2х и массив меток длиной х, так?
А когда скармливаем массив данных функции процессдата, получаем результирующий массив данных каждый элемент которого должен совпадать с элементом массива меток?
По поводу приема. Мы каждый раз при приеме заполняем временный массив данных и массив меток. Далее массив данных через ПроцессДата и потом оба массива переносим в накопительный. Т.е. мы обрабатываем не часть массива, а весь полученный массив данных от функции  LTRXXX_Recv() .  Такой подход имеет право на жизнь? Где его слабые стороны?
Есть какие-то ограничентя на скорости, объемы, частоту вызовов функций. Могут ли они так влиять на результат?
И еще, если у фукнции LTRXXX_Recv() запрашиваем заведомо большее число слов и с минимальным таймаутом,ю такое может дать такое проявление?

Не совсем. Метки привязываются к словам в LTR-овском изначальном формате (одинаково для совершенно любого модуля) - к тем, которые возвращаются после Recv(). И их количество равно возвращенному Recv() значению. Соответственно, если у модуля 2 слова на семпл, то по сути каждому семплу соответствуют две метки, т.е. при сопоставлении меток и уже конечных семплов вам нужно брать значение из массива tmrak через одно.

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

Так же следует обратить внимание на то, что в ProcessData() допустимо передавать только размеры кратные кадру, что требует особого внимания, если Вы работаете по принципу запросить больше, чем может будет принято за таймаут, т.к. в таком случае Recv() может вернуть произвольное значение, не кратное кадру. Т.е. если например у Вас LTR212 с 4-мя разрешенными каналами, то в ProcessData() необходимо передавать блоки данных, кратных 8. Т.е. перед ProcessData() нужно сырые данные корректно склеивать (если Recv() например вернул 7, то нужно дождаться следующего Recv(), если он вернул например 15, то склеить их, получить 22 отсчета, передать в ProcessData() первые 16, а последние 6 оставить для склейки со следующими результатами Recv()).

Кстати Вы результат ProcessData() всегда проверяете? Он у Вас всегда без ошибок выполняется?

Ясно. Было сомнение в этом и изначально предполагал, что так. Но потом переубедил себя. Хорошо, если я в том же 212 собираю не правильно метки, это
может так влиять на другие модули?

Да про склейку и кратность кадров это следим. возвращаемые значения отслеживаем и информирую, сбрасываю в логи. результаты процессдаты тоже смотрю и сравниваю вход/выход.

если это разные программы, то нет. в одной программе, только если вы уже у себя используете какие-то общие ресурсы для разных модулей, в плане библиотеки для каждого модуля tmark заполняется независимо.

Ясно. Спасибо, успокоили.
Вот еще вопрос, если не надоел с вопросами ;-)
лтр11 несколько каналов, частота опроса на канал около 10кгц. Общий результирующий массив набирается порциями с частотой 10-15гц
Т.е. размеры порции около 5000-7000 слов.
Кадры склеиваются. После очередного получения новой порции, она (с учетом склейки кадра) скармливается процессдате и результат уже помещается в накопительный массив.
Так вот в данный момент в каждом факте обращения к процессдате на выходе имеем ошибку  "Неверный счетчик пакетов в массиве полученных от АЦП данных"
и размер обработанного результата меньше на 2-3% (обычно 150-300 слов теряется)
Т.е. если бы ошибка вылезла в начале и весь принятый буфер выкинули бы - я бы понял, где-то ошибся со склейкой , указателями и т.д. А здесь получается в конце массива попадается ошибка. Что это может быть? Может элементарно крейт подвис и надо просто перегрузить его? Или всеж не туда рою? Точно уже не помню, но за несколько часов до этого подобные ошибки иногда выскакивали и лечились стоп/стартом или уж перезагрузкой лтр-сервера.
Или при таком способе чтения это штатная ситуация и надо смериться и просто учитывать сей момет и забирать обработанные данные?

При нормальной работе ошибок ProcessData() быть не должно. Так что надо искать проблему. Сейчас LTR11_ProcessData при нахождении ошибки не откидывает все данные после ошибки, а выкидывает ошибочный кадр и дальше после нахождения нового продолжает обработку. Точную информацию где произошла ошибка она не дает и вообще говоря при ошибке ProcessData() уже однозначно сопоставить семплы с метками становится проблематично. Да, и получается что у Вас 2-3% кадров в потоке ошибки...

В общем скорее всего это проблема склейки все же....

На всякий случай еще можно проверить, что макс. скорость крейта не превышается (5 млн. слов в сек по USB и около 2-х млн по Ethernet).
А Вы к слову по USB или Ethernet работаете?

Да я особо и не утверждаю, что у меня идеально и проблемы железа. ;-)  И хочу найти причину. Но, допускаем не правильную склейку: Получив новую порцию данных (около 5000-7000 слов) мы в самом начале неправильно приклеили огрызок от предыдущего неполного кадра предыдущей порции. И что  тогда имеем? Если функция не умеет находить начало кадра, то должна вся порция данных быть потеряна, т.е. все 100%
Если умеет, и найдя начало кадра продолжит конвертировать дальше, то должен потеряться тогда лишь один плохо склеенный кадр. А тут 2-3%. Если учесть, что теперь функция просто выкидывает сбойные кадры, то это значит не кусок порции(допустим в конце) отброшен, а просто набегает за весь объем обработки порции. Тогда склейка вообще никак не влияет. Т.к. я склеиваю начальный кусочек в несколько слов(начала кадра с прошлого раза) и полученный массив в 5000-7000 слов.
Я правильно рассуждаю?
Статистику смотрел, там переполнения буферов не видно (значит скорость канала USB не исчерпали)
Работаем по USB

Ну во первый функция умеет находить начало кадра, поэтому да, если бы проблема была в одном разрыве, то выкинут был бы только один кадр.

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

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

Значит склейка не может быть причиной этих проблем!
Т.к. она происходит 1 раз на одну порцию 5000-7000 сэмплов и ProcessData() вызывается тут же. Вся порция скачивается одним куском, поэтому размер её не фиксированный. Массив от функции ресив передается процессдате.

Да, именно так- много нулевых меток и во всех потоках (лтр11,лтр212, лтр41)
Если предположить про левые куски и данные, то это должно резко проявляться на выходных значениях (как бы такое сомнение возникало и контроль был) - данные были предсказуемы и не выбивались из ряда. Т.е. если давали на вход синус, то потом этот синус был виден и в построенных графиках