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

[AlekseyK]

Кажется нашел решение своей проблемы. При объявлении скоростных входов как "Fast encoder" позиция энкодера не теряется.

С моим разрешением энкодера (2000 имп/об) можно делать до 32 оборотов в одном направлении, не переполняя регистр энкодера. Если в одну сторону крутить его максимально быстро, а в обратную медленно, то в первом случае (при объявлении быстрых входов как "direct control") появлялась ошибка, так как в прямом направлении происходила потеря импульсов. И при сведении метки на валу подсчитанное положение отличалось от нуля.

Если же мы берем объявление как "Fast encoder", то импульсы не теряются. Но появляются две другие проблемы. На 33-м обороте будет переполнение регистра энкодера и как следствие потеря позиции объекта. То есть необходимо увеличить разрядность регистра энкодера до 32бит.

Для этого выполняем следующий код:

IF ((Old_enc-Enc) > 25000) OR ((Enc-Old_Enc) > 25000) THEN (*Резкое изменение значение регистра означает переполнение в плюс или минус*)
	IF (Enc < Old_Enc) THEN                                                 (*Enc - значение регистра "Fast Encoder"*)
		Kol_Oborotov:=Kol_Oborotov+1;
	ELSE
		Kol_Oborotov:=Kol_Oborotov-1;
	END_IF;
END_IF;

Enc32:=Kol_Oborotov*65535+Enc;                                     (*Enc32 - положение энкодера в DWORD*)
Old_Enc:=Enc;

Вторая проблема в том, что нельзя задать разрешение подключенного энкодера (в старом ПЛК110 это опция присутствовала), в новом счет идет жестко от 0 до 65535. Но она опять же решается, если по переменной Enc32 сделать операцию MOD 2000 - получим угловую позицию энкодера 2000 имп/об без ограничения на 32 оборота.

Код можно размещать в основном цикле программы, так как сравниваются значения регистра энкодера на предыдущем цикле и на текущем. Все промежуточные значения всё равно не могут быть обработаны из-за длины цикла программы. Если хотим чтобы ПЛК максимально часто "присматривался" к позиции энкодера, то размещаем код в прерывание 20 мкс. Анализировать позицию (и реагировать на нее) быстрее чем там, всё равно не получится.

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

Остается только одно непонятно. Зачем ОВЕН в своем онлайн-курсе предлагает реализовывать обработку энкодера через "direct control"? Ведь даже видео-пример про это сняли. Или есть какие-то нюансы, которые я упускаю?

Ну и вопрос к документации. Вот открываем Руководство пользователя, которое хоть на веб-страничке нового ПЛК110, хоть на диске, который вместе с ним приходит, и видим на странице 71 описание модуля Fast Encoder. А в нем описание параметра "Range of encoder 1" и нигде ни слова о том, что данный параметр актуален только для старого ПЛК. В результате вместо спокойной работы с документацией начинаются недоумения "а куда пропал параметр? А не кривой-ли у меня таргет? А может на моем ПЛК прошивка старая?" и изучение постов форума. Деталь, мелочь, но думаю многие заходят на форум с вопросами как раз из-за таких деталей.

[Newcomer]

Кажется нашел решение своей проблемы. При объявлении скоростных входов как "Fast encoder" позиция энкодера не теряется.

С моим разрешением энкодера (2000 имп/об) можно делать до 32 оборотов в одном направлении, не переполняя регистр энкодера. Если в одну сторону крутить его максимально быстро, а в обратную медленно, то в первом случае (при объявлении быстрых входов как "direct control") появлялась ошибка, так как в прямом направлении происходила потеря импульсов. И при сведении метки на валу подсчитанное положение отличалось от нуля.

Если же мы берем объявление как "Fast encoder", то импульсы не теряются. Но появляются две другие проблемы. На 33-м обороте будет переполнение регистра энкодера и как следствие потеря позиции объекта. То есть необходимо увеличить разрядность регистра энкодера до 32бит.

Для этого выполняем следующий код:

IF ((Old_enc-Enc) > 25000) OR ((Enc-Old_Enc) > 25000) THEN (*Резкое изменение значение регистра означает переполнение в плюс или минус*)
	IF (Enc < Old_Enc) THEN                                                 (*Enc - значение регистра "Fast Encoder"*)
		Kol_Oborotov:=Kol_Oborotov+1;
	ELSE
		Kol_Oborotov:=Kol_Oborotov-1;
	END_IF;
END_IF;

Enc32:=Kol_Oborotov*65535+Enc;                                     (*Enc32 - положение энкодера в DWORD*)
Old_Enc:=Enc;

Вторая проблема в том, что нельзя задать разрешение подключенного энкодера (в старом ПЛК110 это опция присутствовала), в новом счет идет жестко от 0 до 65535. Но она опять же решается, если по переменной Enc32 сделать операцию MOD 2000 - получим угловую позицию энкодера 2000 имп/об без ограничения на 32 оборота.

Код можно размещать в основном цикле программы, так как сравниваются значения регистра энкодера на предыдущем цикле и на текущем. Все промежуточные значения всё равно не могут быть обработаны из-за длины цикла программы. Если хотим чтобы ПЛК максимально часто "присматривался" к позиции энкодера, то размещаем код в прерывание 20 мкс. Анализировать позицию (и реагировать на нее) быстрее чем там, всё равно не получится.

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

Остается только одно непонятно. Зачем ОВЕН в своем онлайн-курсе предлагает реализовывать обработку энкодера через "direct control"? Ведь даже видео-пример про это сняли. Или есть какие-то нюансы, которые я упускаю?

Ну и вопрос к документации. Вот открываем Руководство пользователя, которое хоть на веб-страничке нового ПЛК110, хоть на диске, который вместе с ним приходит, и видим на странице 71 описание модуля Fast Encoder. А в нем описание параметра "Range of encoder 1" и нигде ни слова о том, что данный параметр актуален только для старого ПЛК. В результате вместо спокойной работы с документацией начинаются недоумения "а куда пропал параметр? А не кривой-ли у меня таргет? А может на моем ПЛК прошивка старая?" и изучение постов форума. Деталь, мелочь, но думаю многие заходят на форум с вопросами как раз из-за таких деталей.

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

Читать состояние регистра энкодера из прерывания по таймеру 20 мкс бесполезно.

При частоте следования импульсов 10 кГц получается 10 импульсов за 1 мс. Это не много. При длительности цикла основной программы ПЛК 2 мс абсолютная погрешность будет не больше 20 импульсов на интервал измерения длины.

[capzap]

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

Читать состояние регистра энкодера из прерывания по таймеру 20 мкс бесполезно.

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

[Newcomer]

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

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

[capzap]

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

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

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

AlekseyK хотя бы на практике проверяет свои идеи, а Вы пытаетесь свои измышления довести до окружающих ни чем/ни кем не подтвержденные

Во-первых Newcomer ссылается на "подтверждение Владислава Филоненко".
Во-вторых, Newcomer правильно подметил, что AlekseyK упускает из виду, что "использование 20мкс таймера реально бесполезно". Текущий проект будет работать с тем же качеством из простого PLC_PRG.

В третьих, судя по экспериментам AlekseyK, слова Владислава, похоже, подтверждаются: попытка обработать fast inputs из 20мкс таймера пропускает сигналы. По крайней мере, исходная программа выглядит логично, и на ум приходит только то, что реально fastcounters нельзя читать из таймера.
Хотя, конечно, странно это, особенно, учитывая, что именно так рекомендуют делать в "видео от ОВЕН".

[AlekseyK]

Во-вторых, Newcomer правильно подметил, что AlekseyK упускает из виду, что "использование 20мкс таймера реально бесполезно". Текущий проект будет работать с тем же качеством из простого PLC_PRG.

Код можно размещать в основном цикле программы, так как сравниваются значения регистра энкодера на предыдущем цикле и на текущем. Все промежуточные значения всё равно не могут быть обработаны из-за длины цикла программы. Если хотим чтобы ПЛК максимально часто "присматривался" к позиции энкодера, то размещаем код в прерывание 20 мкс. Анализировать позицию (и реагировать на нее) быстрее чем там, всё равно не получится.

То что данный код будет одинаково работать и в таймере и в основном цикле я написал сразу как его выложил. Поэтому относительно возможностей таймера 20 мкс иллюзий нет.

[capzap]

Во-первых Newcomer ссылается на "подтверждение Владислава Филоненко".
Во-вторых, Newcomer правильно подметил, что AlekseyK упускает из виду, что "использование 20мкс таймера реально бесполезно". Текущий проект будет работать с тем же качеством из простого PLC_PRG.

В третьих, судя по экспериментам AlekseyK, слова Владислава, похоже, подтверждаются: попытка обработать fast inputs из 20мкс таймера пропускает сигналы. По крайней мере, исходная программа выглядит логично, и на ум приходит только то, что реально fastcounters нельзя читать из таймера.
Хотя, конечно, странно это, особенно, учитывая, что именно так рекомендуют делать в "видео от ОВЕН".

во первых (#55) - в правом верхнем углу есть тоже ссылка, не обязательно указывать страницу и говорить какой пост прочитать
во вторых, ни какого подтверждения там нет, есть просьба что то подтвердить или опровергнуть (докопаляся до какой то ерунды)
в третьих и я обозначил что так с энкодером можно работать в отддельной задача или в главном цикле, не важно
в четвертых по мне так подход в исходной программе не совсем логичный, за основу берется условие состояния одного из входов и внутри этого условия анализируется состояние второго входа, хоть и правильно всё но в железе мало ли могут быть ошибки из-за дребезгов и т.п. Я бы анализировал что пришел импульс по поднятию обоих входов, а направление учитывал, кто из входов в предыдущей итерации был false

[Newcomer]

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

А вы место и время не перепутали ? Тут не армия, где все делается на ать-два.

[Linan]

Была похожая проблема, нужно было расчитать, спасибо)