Расчет подключаемого энкодера

[AlekseyK]

C:=C + ((оттуда - M) and 65535);

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

Например возврат с 30-го импульса на 27-й:

С:=30+((27-30) and 65535);
C:=30+((-3) and 65535); где -3 будет рассматриваться как dword, то есть = FFFFFFFD и ее результат с and 65535 даст FFFD=65533;
C:=30+65533;
С:=65563; а не 27 как положено.



Второй вариант перемещения в минус засчитывает в плюс.
Тот же вариант возврат от 30-го импульса к 27-му:

C:=C + (abs(word_to_int(оттуда - M)) mod 16#10000);
С:=30+(abs(word_to_int(27-30)) mod 16#10000);
C:=30+(abs(-3) mod 16#10000); вот тут, из-за abs() мы потеряли направление движения
C:=30+(3 mod 65536); ; немного не понял зачем тут MOD, ведь разность значений регистра "оттуда" не может быть больше 65535 вообще никак.
C:=30+3;

Если MOD в конце операции подсчета стоит для приведения положения энкодера к его разрядности, то очевидно что данный вариант работать не будет. Так как операция MOD должна применяться к абсолютному положению энкодера подсчитанному в DWORD, это следует из того, что при переполнения регистра "оттуда" положение энкодера резко сбрасывается в ноль со значения [65535 MOD "разрядность энкодера"]. И при каждом переполнении эти значения будут складываться. То же самое и при обратном переходе через ноль. В регистре "отттуда" был ноль, стало резко [65535 MOD "разрядность энкодера"].

Если я в чем-то ошибаюсь или не понял вашу мысль, прошу не ругать. Потому как обе приведенные формулы проверил на ПЛК с подключенным энкодером и говорю только о том, что наблюдаю в отладчике.

[capzap]

C:=30+((-3) and 65535); где -3 будет рассматриваться как dword, то есть = FFFFFFFD и ее результат с and 65535 даст FFFD=65533;

почему DWORD, обе переменные объявлены как word значит и результат будет ворд, для страховки можете добавить DWORD_TO_WORD

[AlekseyK]

А вы пост #55 из этой темы читали: http://www.owen.ru/forum/showthread.php?t=23600&page=6

Да, читал. Но ведь получается как.
При входе в прерывание 20мкс уже сформировано значение регистра энкодера (модуля "Fast encoder", не "direct control"). Да, возможно на предыдущем заходе в прерывание (или в основном цикле программы) там было 125, а сейчас 130. Да, я не могу отреагировать на 126 импульс. Но главное, что эти импульсы не потеряны. Допустим я вернусь к нему, уменьшив скорость объекта. Тогда и точность увеличится.

Это всё вопросы точности позиционирования. И на сколько я знаю ОВЕН не заявлял что обеспечивает точное позиционирование с частотой входного сигнала 100 кГц. Заявлено, что есть поддержка входного сигнала 100кГц, это выполняется.

Сейчас я со всей дури кручу в руках энкодер на 2000 имп/об и при сведении нулевой метки оказываюсь на том же инкременте откуда начал движение. Меня это вполне устраивает. Как это будет выглядеть на конечном станке - увижу чуть позже.

[Newcomer]

не задумывались, что здесь люди конфигурируют входа и сами в таймере20мкс создают собственный енкодер, а не то что Вы думаете

capzap, посты в теме надо читать все и внимательно, а не через один.

[AlekseyK]

почему DWORD, обе переменные объявлены как word значит и результат будет ворд, для страховки можете добавить DWORD_TO_WORD

"С" объявлена как DWORD. Как я понимаю тут будет работать неявное приведение WORD-значения (оттуда - M) к DWORD. Иначе операция AND 65535 теряет смысл, а так lara197a "зачищает" верхнее слово перед сложением.

[Владимир Ситников]

AlekseyK, попробуйте так:
m : WORD; (* текущее значение fast encoder *)
ottuda : WORD; (* прошлое показание encoder'а *)
c: DINT; (* абсолютное положение encoder'а, без проблем с 65535 *)

c := c + WORD_TO_INT(m - ottuda);
ottuda := m;

[capzap]

"С" объявлена как DWORD. Как я понимаю тут будет работать неявное приведение WORD-значения (оттуда - M) к DWORD. Иначе операция AND 65535 теряет смысл, а так lara197a "зачищает" верхнее слово перед сложением.

а то что там куча скобок Вам ни о чем не говорит?

[Newcomer]

Да, читал. Но ведь получается как.
При входе в прерывание 20мкс уже сформировано значение регистра энкодера (модуля "Fast encoder", не "direct control"). Да, возможно на предыдущем заходе в прерывание (или в основном цикле программы) там было 125, а сейчас 130. Да, я не могу отреагировать на 126 импульс. Но главное, что эти импульсы не потеряны. Допустим я вернусь к нему, уменьшив скорость объекта. Тогда и точность увеличится.

Это всё вопросы точности позиционирования. И на сколько я знаю ОВЕН не заявлял что обеспечивает точное позиционирование с частотой входного сигнала 100 кГц. Заявлено, что есть поддержка входного сигнала 100кГц, это выполняется.

Сейчас я со всей дури кручу в руках энкодер на 2000 имп/об и при сведении нулевой метки оказываюсь на том же инкременте откуда начал движение. Меня это вполне устраивает. Как это будет выглядеть на конечном станке - увижу чуть позже.

Разработчики фирмы "ОВЕН" решили вопрос с максимальной частотой, которую можно подавать на вход энкодера и быстрого счетчика. Для этого они ввели в схему ПЛК аппаратный счетчик. Но пока не решен вопрос с оперативным опросом этого счетчика. Была анонсирована технология PRU, которая решает эту проблему, но до ее полной реализации еще далеко.

[AlekseyK]

Почему же, говорит.
Говорит что сначала будет выполняться вычитание, затем к его результату применят AND, а затем уже результат битового "И" добавят к аккумулятору "С".
Или я что-то путаю?

[AlekseyK]

AlekseyK, попробуйте так:
m : WORD; (* текущее значение fast encoder *)
ottuda : WORD; (* прошлое показание encoder'а *)
c: DINT; (* абсолютное положение encoder'а, без проблем с 65535 *)

c := c + WORD_TO_INT(m - ottuda);
ottuda := m;

Почти хорошо. )) После перехода через максимальное значение регистра энкодера появляется один лишний такт в "С".