Добрый день. У меня одноместный крейт LTR-U-1 с модулем LTR212. Серийный номер крейта 2R369043, модуля LTR212- 4R369514.
Возникла следующая проблема: при работе в режиме показа измерений после 40...60 минут сбор измерений внезапно прерывается с сообщением: "Неверные данные (нарушена целостность последовательности семплов)". (Четырех канальный режим средней точности, число точек на канал - четверть частоты, т.е. 1920). После этого, при попытке остановить сбор данных штатным порядком с помощью функций Stop() и далее Close() приложение зависает полностью. Иногда выдается сообщение: "Не могу остановить сбор данных". Если ошибки сбора данных не возникало, то процесс сбора данных завершается нормально. Чтобы вернуть крейт из зависшего в рабочее состояние, нужно аварийно закрыть программу и на время выдернуть шнур USB. Пытаясь найти причину, обнаружил, что функция Recv() вдруг начинает возвращать нули. Изменения в настройках (количество точек на канал, размеры массивов данных)  ни к чему не привели. Затем попробовал «фирменную» программу UTS pro (с теми же настройками), и описанные проблемы в точности повторились. Так же, после появления сообщения об ошибке, при попытке закрыть окно, например, мультиметра приложение зависает.
При работе в режиме высокой точности (4-х канальный, число точек на канал – четверть частоты выдаваемых данных, т.е. 38) указанных проблем не возникает в обоих программах.
Кроме того, еще проблемы. Так, при попытке соединиться с устройством LTR021 с помощью функции LTR021_Open() прямо из приведенного на диске примера (//LTR//SOURCE//ltr-212//example//Delphi) выдается сообщение о неправильном типе крейта. Устройство LTR021 из этой программы никак не пожелало открыться.
Еще одна небольшая проблемка: функция LTR212_ProcessData() выдает данные в кодах АЦП только если число точек на канал не превышает 31, далее она выдает данные исключительно в вольтах, несмотря на то, что Volt=False.
В завершении, маленькое пожелание тем, кто программирует на Дельфи. Во всех файлах LTRXXXapi.pas для функции GetErrorString() тип возвращаемых данных следует указывать как PChar (указатель на строку, оканчивающуюся нулем), а не string. Этот тип данных так же предпочтительнее использовать в объявлении переменной, содержащей путь файла *.bio, тогда не потребуются конструкции типа «@S[1]».

Проделайте, пожалуйста, следующий эксперимент.
Полностью отсоедините кабельную часть 37-контактного сигнальный разъёма и запустите сбор данных надолго (в 4-канальном режиме средней точности, число точек на канал - четверть частоты, т.е. 1920). Показания будут не валидными без подсоединённых входных цепей, но важно то, возникает ли сообщение "нарушена целостность последовательности семплов"? Или при отсоединённом сигнальном разъёме этой проблемы нет? По результатам этого эксперимента будем смотреть, что делать дальше...

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

Еще можно попробовать повводить данные с помощью нового ЛГрафа (http://www.lcard.ru/forumthreads/8528). В его дистрибутиве лежит новая ltr212api.dll.

Попробовал сегодня как Вы написали: отключил разъем DB-37 запустил программу. Моя программа проработала 1.5 часа, UTS - 15 минут. Затем установил новый LGraph2. О самом Л-графе отдельный разговор. А сейчас я заменил старую библиотеку LTR_212api.dll на новую, из дистрибутива LGraph2. затем запустил программы, сначала свою, затем UTS. Моя проработала 20 минут, UTS - почти 2 часа. В общем ничего не понятно.
Теперь О LGraph. Устанавливал я её на два компьютера: на старый, где стоит у меня плата L-783 и новый, куда подключен крейт. Везде она установилась без проблем. На новом компьютере она никак не пожелала распознать крейт. В списке подключенного оборудования было пусто.
На старом она легко распознала карту L-783, показsвать измерения не пожелала никак. после настройки каналов при нажатии на кнопки "показать" или "записать" неизменно происходил системный сбой и выскакивал "синий экран". На старом компьютере крейт так же не распознался.
Конфигурация старого компьютера: motherboard- Intel D815EPEA2, CPU- PIII, Winows2000.
Нового: m/b: ASUS X48-DS5, Dual Core2, Win XP pro.
В понедельник попробую погонять программы ещё.

P.S/ В измерениях использовал следующие установки: 4-х канальный режим средней точности, опорное напряжение - 5в, измер. диапазон: ±10мВ. Задействованы все 4 канала. Сопротивления мостов по 400 ом. В процессе прогона программ уровень сигналов был постоянный и не превышал 2мВ.

2 часа прогона маловато, желательно погонять подольше (допустим, 8 часов), чтобы точно убедиться, что с отключенным DB-37 программные ошибки не возникают.
Если не возникают, то это указывает на чисто электрический характер проблемы - значит,  LTR-U-1 работает в условиях сильных помех, вызывающих сбой на передачи данных, и предстоит заняться оптимизацией Вашего подключения. Для начала опишите, пожалуйста, состав оборудования Вашей системы, каким образом сделано заземление (что именно и как заземлено)? Какие имеются окружающие источники помех? Это позволит мне сформулировать конкретные рекомендации...
Простите, как Вас по имени, чтобы удобно было обращаться?

Для корректной работы LGraph2 необходимо, чтобы дрова были самые свежие (http://www.lcard.ru/download/lcomp.exe) и свежий ltrserver 1.5.2.1 (http://www.lcard.ru/download/ltr_binary.zip).

В понедельник погоняем модуль с Вашей конфигурацией.

Я, наверное, не совсем ясно написал в предыдущем сообщении. Дело в том, что при отключенном разъеме DB-37 до появления сообщения о нарушении целостности семплов моя программа проработала 1.5 часа, а UTS - 15 минут.А после замены версии LTR_212api.dll на новую, с точностью до наоборот: моя программа смогла проработать только 20 минут, а UTS - 2 часа. Да, ещё забыл ранее написать про особенность: при появлении сбоя  в передаче данных, индикатор-лампочка крейта вела себя так, как будь то передача данных не прекращалась. И только после нажатия кнопки стоп она начинала мигать,а программа зависала. Правда после замены LTR_212api.dll на новую версию программа уже наглухо не зависала, но через 3-5 секунд появлялось сообщение: "Не могу остановить сбор данных". И вернуть крейт в рабочее состояние можно было только выдернув шнур USB. Ну а насчет заземления системы измерений, так я ей пользовался раньше с помощью карты L-783 и проблем не возникало. Да и заземлял я её по Вашим рекомендациям.
Извиняюсь, что не представился. Меня зовут Сергей.
В понедельник загружу новые дрова и погоняю программы, в т.ч. и LCard2.

Сергей. В понедельник Вашу конфигурацию мы тоже потестируем. Обратите внимание, после возникновении сбоя в диспетчере устройств в каком состоянии находится это USB-устройство? Каким USB-кабелем подключаете (входящим в комплект или своим)? Если последнее, какая длина, тип? Я правильно понял, Вы используете стационарный компьютер с питанием от сети? Если так, то какие USB-порты используете: основные (сзади системного) блока или дополнительные (выносные, как правило спереди или сбоку системного блока)? Дополнительные USB-хабы используете?
Если электрический характер проблемы подтвердится, к заземлению и помехам ещё вернёмся...

Основные USB-порты - это те, которые на материнской плате непосредственно на внешний USB-разъём выходят (без кабеля-удлинителя).

1)Примеры для Delphi перепроверяю
2)3 часа уже работают два одноместных крейта одновременно, всё нормально, да и раньше нормально было. Вероятно что-то у вас сбивает нормальную работу Крейта.
   Попробуете скачать всё последнее с сайта,и установить на компьютер с  ХР, удалив предварительно весь старый слфт.
   Обновите Драйвер, Сервер, Библиотеки и УТС.
3)Проверьте компьютер, У одноместного крейта не очень большой аппаратный буфер, различные тяжёлые программы запускающиеся в фоновом режиме теоретически могут оказывать влияние, если займут систему на несколько секунд.
4)Попробуйте поднять приоритет сервера
5)Посмотрите при приёме данных на информационное поле в сервере, для LTR212 там есть пункт "Заполнение буфера сервера: 0.05%" - Значение параметра не должно расти, может прыгать, но недолжно доходить до 100%.
6)Если вы используете Антивирусные программы, или любые программы активно использующие технологию "SOCKET" то желательно попробовать их временно отключить. Или попробовать на компьютере со свеже установленной системой, только Windows драйвера аппаратуры, крейт и наш софт.

Здравствуйте. Установил сегодня новые lComp ltrserver. Шнур USB использую штатный. Переключился на "задний" порт USB. На новых дровах UTS проработала до сбоя 3 часа. Сразу проверил Диспетчер задач. Там все было нормально. Проверил журнал LTRServer, там были сообщения о переполнении буфера LTR021. Хотел скопировать содержание журнала, но не смог - нет такой функции. Затем запустил свою программу - там у меня фиксируются каждое неправильное срабатывание Recv() без останова измерений. Примерно через час появилось сообщение о 3-х неправильных срабатываниях. Одновременно появилось сообщение в журнале сервера о переполнении буфера LTR021, но выдача измерений не прекратилась. Через 20 минут функция Recv стала возвращать сплошные нули. Появилось ещё одно сообщение о переполнении буфера LTR021. Затем был следующий запуск. На 75 минуте появилось сообщение о двух неправильных срабатываниях Recv(), сообщений о переполнении буфера в журнале не появилось, а показ измерений по-прежнему продолжался. Поскольку рабчий день заканчивался я попытался закрыть приложение штатным способом, но тут опять появилось сообщение "Не могу остановить сбор данных", которое обычно появляется только при закрытии приложения после сбоя.
Завтра попробую отключить антивирус и проследить заполнение буфера из сервера. Спасибо за поддержку.

Очень похоже что какая-то тяжёлая программа таки мешает своевременному приёму данных от крейта, вероятно всё-таки антивирус. (для статистики скажите какой у вас)
    Но это могут быть любые программы-агенты, висящие в Трее, к примеру какие-то задачи по обновлению тоже могут мешать (Adobe Reader, или сам Windows, к примеру, очень любят обновляться)

Запустил проверку на более длительный срок. На нашей тестовой машине нет антивирусных программ, и нет каких-то других программ кроме необходимых для LTR.

У меня стоит Касперский. Попробую его отключить. Процессор 4-х ядерный. Да. ещё в режиме высокой точности таких сбоев почему-то нет.Гонял программу в этом режиме более 5 часов и всё нормально. Количество точек на канал было четверть частоты сбора данных 38.

Например, был реальный случай с Avast: отключение не помогало, помогла только деинсталляция...

Всю ночь и весь вчерашний рабочий день работают два 1-местных крейта с LTR212 без проблем. Запущены оба на одном и том же компе (работают 2 копии UTS).

>Хотел скопировать содержание журнала, но не смог - нет такой функции

Вообще-то журнал в файле ltrserver.log (если в ltrserver.ini не указано иначе).

...и клавиши Ctrl-C либо Ctrl-Ins в окне журнала работают, просто в меню не вынесено.

А сообщение о переполнении - это Crate LTR21 Buffer Overflow? Если да, то это ошибка самого крейта, т.е. данные не вычитываются по USB.

У процесса ltrserver.exe приоритет high?

Сегодня отключил Касперского, почистил из диспетчера задач программы, находящиеся в трее запустил программу. Из диспетчера задач понаблюдал за загрузкой ЦП. Общая загрузка не превышала 4-5%. LTRServer грузил процессор на 0-1-2%, остальные процессы были по нулям. Сбой произошел через полчаса с характерным сообщением в журнале ...Crate LTR021 Buffer Overflow. Приоритет сервера - высокий.
После этого гонял свою программу в режиме высокой точности более 7 часов и ни одного сбоя.

Регулярные ошибки LTR021 могут ли означать что он не исправен? или это программные ошибки?

Ошибка "переполнение буфера LTR021" происходит если сервер не успел вовремя откачать данные из крейта.
Такое возникает, как правило, если Windows слишком задумался, а в крейте идёт сбор данных на больших скоростях.
Работа модуля LTR212 в режиме средней точности это где-то 1/3 от предельной загрузки одноместного крейта, достаточно секунду не принимать данные - и может возникнуть сбой.

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

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

Понять на 100% в чём-же дело на конкретном компьютере можно только если переустановить операционную систему, поставить только ПО для LTR и драйверы, отключить компьютер от локальной сети, отключить всевозможные задачи по расписанию.
Убедившись что аппаратура работает на чистой системе можно добавлять остальной софт, периодически проверяя работоспособнось.

К сожелению сейчас слишком большая вероятность что какое-то нежелательное ПО просочилось на компьютер, и невозможно зарание учесть все влияния.

Арсений, в сервере я не нашел информационное поле, где отображается заполнение буфера. Оно находится в журнале? Но там при нормальной работе не появляется никаких сообщений.

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

Два дня гонял программу, наблюдая за заполнением буфера сервера. Значение его составляло 0.03-0.04%, редко 0.05%.В момент сбоя и после него каких либо изменений в окне статистики не происходило и заполнение буфера сервера не превышало 0.04%, всё так же считалось количество  принятых и отправленных слов. В общем в окне статистики всё было так же, как до сбоя, только данных не поступало, а функция Recv() возвращала сплошные нули. Индикатор на крейте всё так же имитировал исправную передачу данных.
И ещё, почему функция LTR021_Open() возвращает ошибку при обращении к крейту? Может быть это как то всё связано...