Проблема со считыванием данных с ЛИР-940Р
Модератор: Денис Кашин
Проблема со считыванием данных с ЛИР-940Р
Добрый день.
Мы купили линейки ЛИР-7 и интерфейсную плату ЛИР-940Р.
Используя команду UpdateData_LIR для первого и второго канала, получаю такие данные: по первому каналу выдаётся постоянное значение, вне зависимости от реального положения датчика; по второму каналу данные изменяются, но их величина непонятным образом связана с реальным перемещением.
При этом программа СКИФ работает нормально.
Отсюда возникают вопросы:
1) Почему неверно опрашивается первый канал?
2) Как преобразовать получаемые значения в реальные миллиметры, т.е. каким образом производится калибровка?
3) Описание процедуры закрытия драйвера под дельфи будет выглядеть примерно так:
procedure Close_Driver_LIR(hFile:THANDLE);stdcall;external 'lir940pci.dll' name 'Close_Driver_LIR';
Я правильно понял?
Мы купили линейки ЛИР-7 и интерфейсную плату ЛИР-940Р.
Используя команду UpdateData_LIR для первого и второго канала, получаю такие данные: по первому каналу выдаётся постоянное значение, вне зависимости от реального положения датчика; по второму каналу данные изменяются, но их величина непонятным образом связана с реальным перемещением.
При этом программа СКИФ работает нормально.
Отсюда возникают вопросы:
1) Почему неверно опрашивается первый канал?
2) Как преобразовать получаемые значения в реальные миллиметры, т.е. каким образом производится калибровка?
3) Описание процедуры закрытия драйвера под дельфи будет выглядеть примерно так:
procedure Close_Driver_LIR(hFile:THANDLE);stdcall;external 'lir940pci.dll' name 'Close_Driver_LIR';
Я правильно понял?
-
- СКБИС
- Сообщения: 79
- Зарегистрирован: 06 фев 2008, 16:10
Добрый день !
1) Проверьте правильно ли Вы подсоединили преобразователь к плате.
Скачайте пример для работы с платой ЛИР940Р
http://www.skbis.ru/soft/code_examples/lir940p/
2) Для получения реального перемещения необходимо домножить получаемое значение на дискретность преобразователя. Например, если дискретность вашего преобразователя 1мкм, то для получения перемещения в миллиметрах необходимо домножить на 0.001.
Также следует учесть, что счетчик в плате - беззнаковый, то есть при переходе через 0 счетчик будет равен значению, близкому к 16777215 (2^24-1).
3) Да, правильно. Даже если не вызывать эту процедуру, то при закрытии программы она вызовется автоматически.
1) Проверьте правильно ли Вы подсоединили преобразователь к плате.
Скачайте пример для работы с платой ЛИР940Р
http://www.skbis.ru/soft/code_examples/lir940p/
2) Для получения реального перемещения необходимо домножить получаемое значение на дискретность преобразователя. Например, если дискретность вашего преобразователя 1мкм, то для получения перемещения в миллиметрах необходимо домножить на 0.001.
Также следует учесть, что счетчик в плате - беззнаковый, то есть при переходе через 0 счетчик будет равен значению, близкому к 16777215 (2^24-1).
3) Да, правильно. Даже если не вызывать эту процедуру, то при закрытии программы она вызовется автоматически.
Если бы всё было так просто, то я бы и не спрашивал. То, что вы мне рекомендуете, я уже обдумывал и пробовал.
Значение первого канала считывается как примерно 4,5 миллиона, значение второго канала - примерно 6 миллионов. Перемещение датчика на 1 мм вызывает изменение считываемого значения на примерно 0,5 миллиона. Поэтому если получаемые значения нормировать на это значение, то получаемые перемещения будут кратны примерно 140 микронам. Т.е. деление на такое большое число загрубляет измерения с 0,5 микрона (дискретность линеек) до 140 микрон. Так что этот вариант не приемлем.
У меня объяснение сложившейся ситуации только одно: считываются совсем не те данные, что нужно. Может быть контроллер платы перед этим нужно каким-то образом конфигурировать, либо как-то сбрасывать ноль.
СКИФ же выдаёт правильные координаты и по обеим осям. Спрашивается: как ему это удаётся с использованием того же драйвера, тех же линеек и той же платы?
Значение первого канала считывается как примерно 4,5 миллиона, значение второго канала - примерно 6 миллионов. Перемещение датчика на 1 мм вызывает изменение считываемого значения на примерно 0,5 миллиона. Поэтому если получаемые значения нормировать на это значение, то получаемые перемещения будут кратны примерно 140 микронам. Т.е. деление на такое большое число загрубляет измерения с 0,5 микрона (дискретность линеек) до 140 микрон. Так что этот вариант не приемлем.
У меня объяснение сложившейся ситуации только одно: считываются совсем не те данные, что нужно. Может быть контроллер платы перед этим нужно каким-то образом конфигурировать, либо как-то сбрасывать ноль.
СКИФ же выдаёт правильные координаты и по обеим осям. Спрашивается: как ему это удаётся с использованием того же драйвера, тех же линеек и той же платы?
-
- СКБИС
- Сообщения: 79
- Зарегистрирован: 06 фев 2008, 16:10
А тестовый пример отсюда http://www.skbis.ru/soft/code_examples/lir940p/
работает ?
Там исходники и exe-шник.
Если не получится - присылайте код.
работает ?
Там исходники и exe-шник.
Если не получится - присылайте код.
Всё, разобрался. Когда сказали, что счётчик контроллера EP1K10 24-разрядный, всё сразу стало ясно. Он считает до 2^24=16777216, этого хватает на перемещение в 32 мм. Следовательно, чтобы отнормироваться, нужно делить на 16777216/32=524288. После перемещения на очередные 32 мм, вторая переменная (ident) получает смещение на 1. Сразу бы так и сказали.
Просто надо бы вам уже перейти на другой контроллер, имеющий 32-разрядные счётчики, и тогда вообще никаких проблем не будет: тогда можно будет пользоваться линейками длиной до 8192 мм, т.е. более 8 метров.
Просто надо бы вам уже перейти на другой контроллер, имеющий 32-разрядные счётчики, и тогда вообще никаких проблем не будет: тогда можно будет пользоваться линейками длиной до 8192 мм, т.е. более 8 метров.
-
- СКБИС
- Сообщения: 79
- Зарегистрирован: 06 фев 2008, 16:10
24-х разрядного счетчика хватает на 16777216*0,0005 (дискретность преобразователя в миллиметрах) = 8388,608 мм. То есть как раз на 8 метров.
Переменна ident позволяет судить о приходе референтной метки или внешнего сигнала на плату.
0 - нет референтной метки и внешнего сигнала
1 - внешний сигнал
2 - референтная метка
Переменна ident позволяет судить о приходе референтной метки или внешнего сигнала на плату.
0 - нет референтной метки и внешнего сигнала
1 - внешний сигнал
2 - референтная метка
В-общем, совсем запутался. Моё первоначальное предположение о том, что переполнение счётчика происходит на 32 мм, оказалось не верным. Переполнение происходит на 31,24 мм. Внутри диапазонов в 125 микрон значение счётчика смасштабировано относительно реальной величины в 256 раз. И, при каждом переходе через очередные 125 микрон, происходит скачкообразное изменение значения до нужного. Так и должно быть, или линейки испорчены?
По опросу каналов: когда позавчера я включал компьютер, считывался только второй канал, вчера - оба, а сегодня - только первый.
Тестовая программа и программа СКИФ показывают те же результаты, что и получаются у меня. Т.е. один из каналов не работает (или, соответственно, работают оба); данные при выборе миллиметров миллиметрами совершенно не являются; считываемые значения скачкообразно изменяются через каждые 125 микрон.
При этом программа той фирмы, которая продала нам линейки и плату, работает нормально. Т.е. оба канала всегда работают, миллиметры являются миллиметрами и никаких скачков в значениях нет, координаты изменяются плавно.
Отсюда делаю вывод, что эти ребята что-то специально переделали либо в линейках, либо поменяли прошивку платы для того, чтобы, так сказать, никто не догадался.
По опросу каналов: когда позавчера я включал компьютер, считывался только второй канал, вчера - оба, а сегодня - только первый.
Тестовая программа и программа СКИФ показывают те же результаты, что и получаются у меня. Т.е. один из каналов не работает (или, соответственно, работают оба); данные при выборе миллиметров миллиметрами совершенно не являются; считываемые значения скачкообразно изменяются через каждые 125 микрон.
При этом программа той фирмы, которая продала нам линейки и плату, работает нормально. Т.е. оба канала всегда работают, миллиметры являются миллиметрами и никаких скачков в значениях нет, координаты изменяются плавно.
Отсюда делаю вывод, что эти ребята что-то специально переделали либо в линейках, либо поменяли прошивку платы для того, чтобы, так сказать, никто не догадался.
-
- СКБИС
- Сообщения: 79
- Зарегистрирован: 06 фев 2008, 16:10
Да, скорее всего, это так.
Номер платы (может быть версия прошивки; то, что написано на наклейке): 09.2850.
Как-то можно туда записать обычную прошивку, или для этого требуется специальный программатор?
Думаю, смена прошивки должна решить проблему.
Или проще купить новую плату с нормальной прошивкой? Надеюсь, линейки у нас стандартные, а не тоже спец, как прошивка платы, и они заработают как должны работать в штатном режиме.
Номер платы (может быть версия прошивки; то, что написано на наклейке): 09.2850.
Как-то можно туда записать обычную прошивку, или для этого требуется специальный программатор?
Думаю, смена прошивки должна решить проблему.
Или проще купить новую плату с нормальной прошивкой? Надеюсь, линейки у нас стандартные, а не тоже спец, как прошивка платы, и они заработают как должны работать в штатном режиме.
-
- СКБИС
- Сообщения: 79
- Зарегистрирован: 06 фев 2008, 16:10
не получается перевести данные получаемые от UpdateData_LIR в миллиметры:Михаил Поляков писал(а):Добрый день !
1) Для получения реального перемещения необходимо домножить получаемое значение на дискретность преобразователя. Например, если дискретность вашего преобразователя 1мкм, то для получения перемещения в миллиметрах необходимо домножить на 0.001.
Также следует учесть, что счетчик в плате - беззнаковый, то есть при переходе через 0 счетчик будет равен значению, близкому к 16777215 (2^24-1).
данные из программы примера: 0 байт, из программы СКИФ: 11130.0 мкм
-/- 10 байт; -/- 11160,0 мкм
-/- 150 байт; -/- 11280,0 мкм
-/- 500 байт; -/- 11631,0 мкм
-/- 16766076 байт; -/- -10,0 мкм
-/- 16766086 байт; -/- 0,0 мкм
-/- 16765986 байт; -/- -100,0 мкм
Подскажите пожалуйста.
-
- СКБИС
- Сообщения: 272
- Зарегистрирован: 07 фев 2008, 09:52
Смотрите http://www.skbis.ru/pdf/interfaces/Lir940P.pdf главу "Квадратурный счетчик"
Пожалуйста, поделитесь примером алгоритма считывания на языке программированияДмитрий Ряполов писал(а):Смотрите http://www.skbis.ru/pdf/interfaces/Lir940P.pdf главу "Квадратурный счетчик"
-
- СКБИС
- Сообщения: 79
- Зарегистрирован: 06 фев 2008, 16:10
hardCounter - текущее значение data = UpdateData_LIR
prevHardCounter - предыдущее значение data
int d = (int)hardCounter - (int)prevHardCounter;
prevHardCounter = hardCounter;
if (Math.Abs(d) > 1 << 23) // math.abs - модуль
{
d -= Math.Sign(d) * (1 << 24); // math.sign -
сигнум
}
relativeCounter += d; // программно-аппаратный счетчик
prevHardCounter - предыдущее значение data
int d = (int)hardCounter - (int)prevHardCounter;
prevHardCounter = hardCounter;
if (Math.Abs(d) > 1 << 23) // math.abs - модуль
{
d -= Math.Sign(d) * (1 << 24); // math.sign -
сигнум
}
relativeCounter += d; // программно-аппаратный счетчик