PDA

Просмотр полной версии : ПЛК110.60[М2] + энкодер + счетчик.



Sulfur
15.03.2016, 13:43
Добрый день!
Интересует возможность одновременной работы на "быстрых" входах ABZ-энкодера и высокоскоростного счетчика в ПЛК110-60.М2.
Энкодер достаточно медленный, 360имп\об, частота вращения максимум 30 об\мин. А вот счетчик должен уметь считать импульсы в это же самое время с частотой до 50кГц, причем по достижению некоего значения выключать один из "быстрых" выходов. Допустима небольшая погрешность для счетчика (1-2% от общего количества импульсов). Энкодер же должен просчитываться абсолютно точно.
Реализуема ли такая "хотелка" на данном ПЛК?

lara197a
15.03.2016, 13:54
Если 110.60 м2 есть в продаже. то с такой задачей он справится.

Вольд
15.03.2016, 14:24
Легко справится.

Дмитрий Артюховский
15.03.2016, 15:20
вот совсем не факт - 50 кГц много - если только рекламируемый реалтайм.

свой счетчик (на таймере) не 50 кгц не организовать, а насколько быстрый доступ к счетчику конфигуратора из быстрого прерывания мне не понятно

Филоненко Владислав
15.03.2016, 15:33
Счетчики и энкодеры без плясок с прерываниями работают с частотами импульсов до 100кГц (и даже несколько выше :) )

А вот для реализации времени реакции на значение счётчика на уровне микросекунд - уже OwenLogicRT, никак иначе в принципе невозможно.

Владимир Ситников
15.03.2016, 15:46
Дата выпуска OwenLogicRT секретна?

Филоненко Владислав
15.03.2016, 18:09
Тут тот случай, когда от активной позиции пользователей зависит результат. Заказчиков нет, пара человек проявила интерес.

Newcomer
15.03.2016, 18:23
Тут тот случай, когда от активной позиции пользователей зависит результат. Заказчиков нет, пара человек проявила интерес.

Пара + еще один стало трое. ;) Пора бы фирме "ОВЕН" уже и разродиться.

Алексей Геннадьевич
15.03.2016, 21:46
Тут тот случай, когда от активной позиции пользователей зависит результат. Заказчиков нет, пара человек проявила интерес.
Чтобы проявить интерес, нужно знать, к чему его проявляешь.

Scream
16.03.2016, 07:50
Чтобы проявить интерес, нужно знать, к чему его проявляешь.

+

я один раз увидел слово OwenLogicRT, а что за зверь и как готовить?

Sulfur
16.03.2016, 08:40
+

я один раз увидел слово OwenLogicRT, а что за зверь и как готовить?
Присоединяюсь к вопросу - что за зверь и с чем его едят?

Newcomer
16.03.2016, 09:31
Счетчики и энкодеры без плясок с прерываниями работают с частотами импульсов до 100кГц (и даже несколько выше :) )

А вот для реализации времени реакции на значение счётчика на уровне микросекунд - уже OwenLogicRT, никак иначе в принципе невозможно.

А где у автора темы сказано, что время реакции на событие должно быть на уровне микросекунд ? 50 кГц - это 1 импульс за 20 мкс. Какое количество импульсов надо отсчитывать автор не написал.

Newcomer
16.03.2016, 09:35
Присоединяюсь к вопросу - что за зверь и с чем его едят?

Об этом звере подробно написано здесь: http://www.owen.ru/forum/showthread.php?t=22169

В.Филоненко об этом торжественно объявил и дело встало. А народ ждет. ;)

Sulfur
16.03.2016, 13:29
А где у автора темы сказано, что время реакции на событие должно быть на уровне микросекунд ? 50 кГц - это 1 импульс за 20 мкс. Какое количество импульсов надо отсчитывать автор не написал.
Малость проясню ситуацию. Данный ПЛК берется для модернизации системы управления термоформовочной машины. В машине есть главный двигатель, который крутит редуктор, на выходном валу этого редуктора стоит энкодер. В зависимости от градуса поворота этого энкодера включаются всякие могрушки-хлопушки, а так же в определенный момент включается транспорт материала. Транспорт приводится в действие сервоприводом. С этого сервопривода можно снять "энкодерный" сигнал обратной связи, который и должен считать быстрый счетчик. Минимально я могу выставить "энкодер" в сервоприводе 512 имп\об двигателя. Частота вращения фиксирована и составляет 3000 об\мин. Сам цикл работы транспорта физически занимает 0.4-0.8 сек., за это время отматывается от 100 до 250 мм материала. Важно не абсолютное количество импульсов, а стабильность. Т.е. если стоит уставка, к примеру, мотать 231 мм за цикл, то каждый цикл он должен мотать 231-+0.5мм. Иначе имеем увеличение процента брака. В данный момент импульсы считает старый аппаратный специфический счетчик жутко буржуйского производства.
ЗЫ: Да, я знаю, что есть специальные инверторы с функцией позиционирования и управления по цифре. Но на такую дорогую модернизацию руководство не подпишется.

Newcomer
16.03.2016, 13:41
(512 х 3000) / 60 = 25 600 Гц = 25,6 кГц. А вы писали про 50 кГц.

Вам надо поддерживать стабильным цикл работы транспорта или что-то другое ?

Владимир Ситников
16.03.2016, 13:55
Сам цикл работы транспорта физически занимает 0.4-0.8 сек... Т.е. если стоит уставка, к примеру, мотать 231 мм за цикл, то каждый цикл он должен мотать 231-+0.5мм

0.5мм (на ошибку) / ( 231мм/0.8сек (скорость подачи) ) == 1.7мс

Иными словами, если отключение подачи ошибётся на 2мс, то за нужные вам 0.5мм выйдете.

Судя по тому, что использовать цикл менее 1мс не рекомендуют (со словами "отвалится ethernet и много чего ещё"), то варианта 2:
1) Присоединяться к клубу любителей PRU программирования (http://www.owen.ru/forum/showthread.php?t=22169&highlight=OwenLogicRT). У быстрых выходов обещают время реакции 0.02мс, что в 100 раз точнее необходимого вам.
2) Понижать скорость.
3) Использовать стохастическое управление: подавать в программе отключающий сигнал "чуть раньше", чтобы в реальности он происходил "тогда, когда нужно" с учётом задержек транзистора реального ПЛК. По РЭ обещают, что не больше 5мс, и думаю, задержка срабатывания конкретного выхода конкретного экземпляра ПЛК должна быть более-менее стабильной.

Newcomer
16.03.2016, 14:05
В обновленном ПЛК110 можно организовать проверку состояния счетчика, например, каждые 40 мкс (Timer(20mks)). За 40 мкс энкодер выдает 2 импульса. В ПЛК110 есть быстрые выхода, которые срабатывают за 20 мкс. Если отсчитывать на 2...3 импульса меньше положенного (действие с упреждением), то все будет чики-пики.

Владимир Ситников
16.03.2016, 14:10
В обновленном ПЛК110 можно организовать проверку состояния счетчика каждые 40 мкс. В ПЛК110 есть быстрые выхода, которые срабатывают за 20 мкс.

Чем это отличается от пункта 1?
Нужно, конечно, проверять, но если между "брак" и "не брак" разница в 1-2мс, то надеяться, что "цикл 1мс на ПЛК" обеспечит точность в 1мс, по-моему, оптимистично => нужно PRU.

Newcomer
16.03.2016, 14:25
Чем это отличается от пункта 1?
Нужно, конечно, проверять, но если между "брак" и "не брак" разница в 1-2мс, то надеяться, что "цикл 1мс на ПЛК" обеспечит точность в 1мс, по-моему, оптимистично => нужно PRU.

Все критичные по времени действия надо делать в прерывающей подпрограмме, которая стабильно вызывается каждые 40 мкс. Все прочие действия можно делать в основном цикле.

PRU - это вещь в себе. Пока В.Филоненко доведет это дело до ума пройдет мноооооооооооого времени. Будет куча всяких прошивок-перепрошивок и прочей головной боли.

Дмитрий Артюховский
16.03.2016, 14:25
Малость проясню ситуацию. Данный ПЛК берется для модернизации системы управления термоформовочной машины. В машине есть главный двигатель, который крутит редуктор, на выходном валу этого редуктора стоит энкодер. В зависимости от градуса поворота этого энкодера включаются всякие могрушки-хлопушки, а так же в определенный момент включается транспорт материала. Транспорт приводится в действие сервоприводом. С этого сервопривода можно снять "энкодерный" сигнал обратной связи, который и должен считать быстрый счетчик. Минимально я могу выставить "энкодер" в сервоприводе 512 имп\об двигателя. Частота вращения фиксирована и составляет 3000 об\мин. Сам цикл работы транспорта физически занимает 0.4-0.8 сек., за это время отматывается от 100 до 250 мм материала. Важно не абсолютное количество импульсов, а стабильность. Т.е. если стоит уставка, к примеру, мотать 231 мм за цикл, то каждый цикл он должен мотать 231-+0.5мм. Иначе имеем увеличение процента брака. В данный момент импульсы считает старый аппаратный специфический счетчик жутко буржуйского производства.
ЗЫ: Да, я знаю, что есть специальные инверторы с функцией позиционирования и управления по цифре. Но на такую дорогую модернизацию руководство не подпишется.

1. задача решиться, если импульсы энкодера сервопривода поделить, хотя бы на 4(8,16)
2. энкодерный сервопривод с большой долей вероятности имеет режим управления "по положению", в котором можно управлять длительностью и скоростью вращения подачей импульсов

Sulfur
16.03.2016, 14:27
(512 х 3000) / 60 = 25 600 Гц = 25,6 кГц. А вы писали про 50 кГц.

Вам надо поддерживать стабильным цикл работы транспорта или что-то другое ?

По умолчанию стоит 1024 имп\об.
Мне нужно, что бы транспорт всегда отрабатывал стабильное количество материала.



Судя по тому, что использовать цикл менее 1мс не рекомендуют (со словами "отвалится ethernet и много чего ещё"), то варианта 2:
1) Присоединяться к клубу любителей PRU программирования (http://www.owen.ru/forum/showthread.php?t=22169&highlight=OwenLogicRT). У быстрых выходов обещают время реакции 0.02мс, что в 100 раз точнее необходимого вам.
2) Понижать скорость.
3) Использовать стохастическое управление: подавать в программе отключающий сигнал "чуть раньше", чтобы в реальности он происходил "тогда, когда нужно" с учётом задержек транзистора реального ПЛК. По РЭ обещают, что не больше 5мс, и думаю, задержка срабатывания конкретного выхода конкретного экземпляра ПЛК должна быть более-менее стабильной.

1. На "присоединиться" как обычно нет времени и всё нужно готовое и "уже вчера". Сомневаюсь, что со своими скромными знаниями в программировании могу быть полезен этому сообществу.
2. При понижении скорости подачи материала так же имеем увеличение процента брака.
3. Не вопрос. Подгонка физического количества импульсов и фактического расстояния подачи материала будет привязываться к переменной в миллиметрах.

Newcomer
16.03.2016, 14:32
Мне нужно, что бы транспорт всегда отрабатывал стабильное количество материала.

А что для этого надо, отсчитывать одинаковое количество импульсов ?

Newcomer
16.03.2016, 14:37
1. задача решиться, если импульсы энкодера сервопривода поделить, хотя бы на 4(8,16)
2. энкодерный сервопривод с большой долей вероятности имеет режим управления "по положению", в котором можно управлять длительностью и скоростью вращения подачей импульсов

И зачем все это надо ?

Владимир Ситников
16.03.2016, 14:56
Все критичные по времени действия надо делать в прерывающей подпрограмме, которая стабильно вызывается каждые 40 мкс. Все прочие действия можно делать в основном цикле.
Имеется ввиду "System events -> Timer 20mks"?

Если оно реально может что-то выполнять раз в 20мкс, то должно подойти.

Филоненко Владислав
16.03.2016, 15:00
В обновленном ПЛК110 можно организовать проверку состояния счетчика, например, каждые 40 мкс (Timer(20mks)). За 40 мкс энкодер выдает 2 импульса. В ПЛК110 есть быстрые выхода, которые срабатывают за 20 мкс. Если отсчитывать на 2...3 импульса меньше положенного (действие с упреждением), то все будет чики-пики.
Нельзя из прерывания проверить значение счётчика

Владимир Ситников
16.03.2016, 15:04
Нельзя из прерывания проверить значение счётчика
А что можно?

Т.е. только PRU, только хардкор?

Newcomer
16.03.2016, 15:05
Имеется ввиду "System events -> Timer 20mks"?

Если оно реально может что-то выполнять раз в 20мкс, то должно подойти.

Это проверено и работает.

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

Владимир Ситников
16.03.2016, 15:06
1. На "присоединиться" как обычно нет времени и всё нужно готовое и "уже вчера". Сомневаюсь, что со своими скромными знаниями в программировании могу быть полезен этому сообществу.
А за осмотр денег не берут. Напишите, что, мол, так и так, есть задача, где нужно быстрая реакция/управление.

Там в первую очередь как раз не программисты нужны, а те, кому конечный продукт нужен.

Дмитрий Артюховский
16.03.2016, 15:27
И зачем все это надо ?

достаточно одного пункта )) при понижении скорости входных импульсов - их можно будет считать черех "быстрый таймер" и адекватно формировать сигнал на остановку, а при переключение в "по положению" - количеством импульсов задаем требуемую подачу

Newcomer
16.03.2016, 15:42
достаточно одного пункта )) при понижении скорости входных импульсов - их можно будет считать черех "быстрый таймер" и адекватно формировать сигнал на остановку, а при переключение в "по положению" - количеством импульсов задаем требуемую подачу

Я думаю количество импульсов на оборот у энкодера не с потолка взято и понизить волевым решением их количество в N раз не получится.

Дмитрий Артюховский
16.03.2016, 16:26
Импульсы встроенных энкодеров прежде всего нужны для адекватной работы драйвера. Как правило, на сервоприводах имеется дополнительная возможность использовать эти импульсы для своих хотелок - организован сквозной канал. То, что я их поделю никак не скажется на работе самого привода. И кстати, требуемое количество импульсов зависит от необходимости в точном регулировании положения и скорости, чего в данной задаче не прослеживается.

Филоненко Владислав
16.03.2016, 18:38
А что можно?

Т.е. только PRU, только хардкор?

Для таких времён реакции (и что самое главное стабильности реакции) только хардкор.
Одни накладные расходы самой среды CoDeSys на цикл составляют до 300 мкс.

Будет это PRU, отдельная плата с МК на 1 задачу управления движением (я всегда так делаю для шаговиков, несмотря на то, что мог бы "подкрутить" цикл для себя в прошивке, но понимаю, что стабильность (низкий джиттер) важнее экономии на спичках) - не важно.

Newcomer
16.03.2016, 18:57
Нельзя из прерывания проверить значение счётчика

Это как понять ? Что может помешать проверить в программе, которая вызывается по прерыванию от таймера, состояние счетчика ?

Дмитрий Артюховский
16.03.2016, 19:42
Это как понять ? Что может помешать проверить в программе, которая вызывается по прерыванию от таймера, состояние счетчика ?

базовый принцип работы ПЛК: установка входов (данных регистров) -> обработка -> установка выходов === это все ОСНОВНОЙ цикл... в таймере вы конечно можете считать регистр, но там будет одно и тоже значение

Владимир Ситников
16.03.2016, 20:00
базовый принцип работы ПЛК: установка входов (данных регистров) -> обработка -> установка выходов === это все ОСНОВНОЙ цикл... в таймере вы конечно можете считать регистр, но там будет одно и тоже значение

А зачем тогда вообще быстрый таймер нужен?

Newcomer
16.03.2016, 20:01
базовый принцип работы ПЛК: установка входов (данных регистров) -> обработка -> установка выходов === это все ОСНОВНОЙ цикл... в таймере вы конечно можете считать регистр, но там будет одно и тоже значение

Тогда возникает вопрос: на кой хрен нужны быстрые счетчики если их состояние можно сосчитать не чаще одного раза за основной цикл работы ПЛК. Основной цикл работы ПЛК может быть и 10 мс и более если программа большая. За это время быстрый счетчик может и переполнится. И что тогда ? Безобразие !

Newcomer
16.03.2016, 20:03
А зачем тогда вообще быстрый таймер нужен?

Через быстрый таймер можно напрямую управлять быстрыми выходами и вести опрос быстрых входов. О, это хорошая лазейка для обхода базового принципа работы ПЛК. ;)

А с быстрыми счетчиками и энкодером получается все плохо, т.к. нет никакого толка от их быстродействия. :mad::mad::mad:

Владислав, даете PRU. Это вопрос вашей чести. Надо срочно спасать положение.

Дмитрий Артюховский
16.03.2016, 22:17
быстрый таймер - это "лайфхак" от овена, который подарил нам возможность использовать ПЛК110 для решения задач поднимаемых, до этого, на устройствах совершенно другого ценового диапазона!!! так что ваша реакция описывается одним словом - "слишком много кушать" )))

Филоненко Владислав
17.03.2016, 05:49
Когда генералы начинаю речи о чести солдат - значит они крупно облажались и солдатам придётся умирать за их ошибки.
Как связаны PRU и моя честь?

Newcomer
17.03.2016, 08:58
Когда генералы начинаю речи о чести солдат - значит они крупно облажались и солдатам придётся умирать за их ошибки.
Как связаны PRU и моя честь?

На самом деле облажались разработчики фирмы "ОВЕН" с обновленным ПЛК110. Но если В.Филоненко и Ко оперативно запустят технологию PRU в полном объеме, то честь фирмы будет спасена.

Sulfur
17.03.2016, 09:29
1. задача решиться, если импульсы энкодера сервопривода поделить, хотя бы на 4(8,16)
2. энкодерный сервопривод с большой долей вероятности имеет режим управления "по положению", в котором можно управлять длительностью и скоростью вращения подачей импульсов
1. Не хотелось бы городить колхоз-монтаж. Хотя все равно придется делать преобразователь уровня, т.к. выход с привода имеет амплитуду 5V.
2. Lenze 9300 servo, режима "по положению" нет (не та модификация), управления импульсами нет, управление цифрой только по CAN, либо дискретными сигналами через внешние терминалы.

Дмитрий Артюховский
17.03.2016, 11:01
Все есть внутри, нужно мануал читать. Также можно нетривиально использовать сигналы, например, там есть "формирование метки нуля" - константа позволяющая сформировать импульс через определенное количество меток энкодера - чем это не делитель на сколько угодно?
Также можно использовать "поиск нуля" - привод поворачивается на заданный угол по входному сигналу - чем не дозатор?
Да и "положение" там есть - это в манулале называется "angle" - т.е. угол - привод синхронизирует текущий угол по внешнему заданию.

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

Филоненко Владислав
17.03.2016, 15:43
На самом деле облажались разработчики фирмы "ОВЕН" с обновленным ПЛК110. Но если В.Филоненко и Ко оперативно запустят технологию PRU в полном объеме, то честь фирмы будет спасена.
Даже интересно, кто платит за такую топорную антирекламу?
Дело чести, разработчики облажались. Высокий слог, комментарии только по сути, проффесионализм и прочее, что в Ваших постах отсутствует напрочь.

Newcomer
17.03.2016, 18:44
Даже интересно, кто платит за такую топорную антирекламу?
Дело чести, разработчики облажались. Высокий слог, комментарии только по сути, проффесионализм и прочее, что в Ваших постах отсутствует напрочь.

Комментарии по сути мне бы хотелось услышать от вас по моему не профессиональному посту #36.

Филоненко Владислав
17.03.2016, 19:08
Вам уже ответили пользователи форума на этот вопрос. Чтобы использовать прямой доступ к I/O

Newcomer
17.03.2016, 20:23
Вам уже ответили пользователи форума на этот вопрос. Чтобы использовать прямой доступ к I/O

У нас с вами странный разговор получается. Повторю вопрос еще раз.

На кой хрен нужны быстрые счетчики если их состояние можно сосчитать не чаще одного раза за основной цикл работы ПЛК. Основной цикл работы ПЛК может быть и 10 мс и более если программа большая. За это время быстрый счетчик может далеко убежать и даже переполниться. И что тогда ?

С энкодером то же самое.

capzap
17.03.2016, 21:22
У нас с вами странный разговор получается. Повторю вопрос еще раз.

На кой хрен нужны быстрые счетчики если их состояние можно сосчитать не чаще одного раза за основной цикл работы ПЛК. Основной цикл работы ПЛК может быть и 10 мс и более если программа большая. За это время быстрый счетчик может далеко убежать и даже переполниться. И что тогда ?

С энкодером то же самое.

Вы чего на самом деле троллингом стали заниматься, ну есть скоростная задача, которая берет с быстрых входов значения и записывает в глобальную переменную, остальные задачи эту глобальную переменную должны только читать. И все должны остаться довольными, в каком бы месте ни была прочитана эта переменная, в ней будут почти актуальные данные. Вы чего нам здесь изллагаете свои страхи?

Newcomer
17.03.2016, 22:00
Вы чего на самом деле троллингом стали заниматься, ну есть скоростная задача, которая берет с быстрых входов значения и записывает в глобальную переменную, остальные задачи эту глобальную переменную должны только читать. И все должны остаться довольными, в каком бы месте ни была прочитана эта переменная, в ней будут почти актуальные данные. Вы чего нам здесь изллагаете свои страхи?

Речь не о быстрых входах, с ними проблем нет. Речь о быстрых счетчиках и энкодере. Тут что можете предложить ? Такое чувство, что вы тему не читали.

capzap
18.03.2016, 06:21
Речь не о быстрых входах, с ними проблем нет. Речь о быстрых счетчиках и энкодере. Тут что можете предложить ? Такое чувство, что вы тему не читали.
это принципиально разные вещи что ли? один суммирует приходящие на быстрый вход, другой еще сравнивает на каком быстром входе пришел раньше положительный фронт

Владимир Ситников
18.03.2016, 06:39
это принципиально разные вещи что ли? один суммирует приходящие на быстрый вход, другой еще сравнивает на каком быстром входе пришел раньше положительный фронт

capzap, дело в том, что на текущий момент Владислав говорит следующее:
1) В быстром таймере к быстрым счётчикам обращаться нельзя. В смысле "невозможно наблюдать за актуальным значением быстрых счётчиков из быстрого таймера". По-моему, странно.
2) В то же самое время, за значениями простых быстрых входов смотреть можно (неясно будут ли они актуальными, но, судя по риторике, они будут актуальными). Тут пункт №1 становится ещё более странным.
3) Из PRU можно работать с быстрыми входами/счётчиками. Это и ежу понятно, что из PRU должно быть возможно. Но, прежде чем шарашить PRU, хотелось бы понять можно ли получать актуальные значения счётчиков каждые, скажем, 40 мкс простыми способами.

Тут я соглашусь с Newcomer: непонятно можно ли оперативно (~40us) читать значения счётчиков и оперативно (~40us) реагировать на это командами на быстрые выходы. В документации про быстрые таймеры как-то скудно. Да и про быстрые входы/таймеры тоже не особо сказано.

Вариация "обращаться-то к быстрым счётчикам можете, но они своё значение обновляют раз в главный цикл" совсем не радует. Неужели весь смысл "быстрых счётчиков" только в том, что они "правильно посчитают"? А как же управление организовывать? Неужели только PRU?

Newcomer, полегче с риторикой. Понятно, что ничего не понятно. В то же время, никому не приятно, когда хренами ругаются. Стоит один-два раза Владислава спугнуть -- так вообще ничего не дождёшься потом.

capzap
18.03.2016, 06:56
так и встарых модификациях такого не было, получать знаечения счетчиков/энкодеров можно было в конфигураторе, который работал от основного цикла, а формирование значений происходило в подобии "быстрого таймера". Чтоб было возможно в быстром таймере обработать какое то значение счетчика/енкодера потребуется сверхбыстрый таймер и т.д.
По поводу хотелок Newcomer-а, на сколько я понял его рассуждения, так можно дойти до того что в основной программе он создаст бесконечный цикл чтоб отловить нужное значение счетчика/энкодера, тем самым поймав "злую собаку". Поэтому ему и подсказывают, что обрабатывать значение получиться один раз в цикл

Владимир Ситников
18.03.2016, 07:02
так и встарых модификациях такого не было, получать знаечения счетчиков/энкодеров можно было в конфигураторе, который работал от основного цикла, а формирование значений происходило в подобии "быстрого таймера". Чтоб было возможно в быстром таймере обработать какое то значение счетчика/енкодера потребуется сверхбыстрый таймер и т.д.
По поводу хотелок Newcomer-а, на сколько я понял его рассуждения, так можно дойти до того что в основной программе он создаст бесконечный цикл чтоб отловить нужное значение счетчика/энкодера, тем самым поймав "злую собаку". Поэтому ему и подсказывают, что обрабатывать значение получиться один раз в цикл

Ну, "доходить" никто не собирается. Никто тут и не хочет "в while цикле крутиться и ждать погоды, пока значение входа изменится".
"сверхбыстрый таймер" -- штатная функция М02 (в документации даже описано, правда не сказано зачем, какие ограничения и т.п.). 20 или 40мкс, но конкретная цифра не важна. Главное, что этот таймер гораздо быстрее обычного цикла ПЛК.

Внимание, вопрос: какая польза от этого "сверхбыстрого", если в нём IO всё равно выполнять бесполезно?
Или всё-таки, какое-то IO выполнять можно? Если можно, то какое?

BETEP
18.03.2016, 09:03
Топикстартер хочет это реализовать?

В процессе работы текущее значение счетчика (PV) может сравниваться со
значениями, предварительно зарегистрированными в таблице сравнения.
Когда выполняется соответствующее условие, может быть запущена
указанная задача обработки прерывания (зарегистрированная в таблице).
Можно применить один из двух способов сравнения: сравнение с
заданным значением и попадание в заданный диапазон.
Для регистрации таблицы сравнения используется инструкция
CTBL(882).
Для запуска операции сравнения используется либо инструкция
CTBL(882), либо инструкция INI(880).
Для прекращения операции сравнения используется инструкция
INI(880).

Сравнение с заданным значением
Когда текущее значение высокоскоростного счетчика совпадает с
заданным значением, зарегистрированным в таблице, выполняется
указанная задача обработки прерывания.

Условия сравнения (заданные значения и направления счета)
регистрируются в таблице сравнения вместе с соответствующим
номером задач обработки прерывания. Указанный обработчик
прерывания будет запущен, когда значение PV высокоскоростного
счетчика совпадет со значением, зарегистрированным в таблице.

В таблице сравнений можно зарегистрировать до сорока восьми
заданных значений (от 1 до 48).

Для каждого заданного значения можно зарегистрировать отдельную
задачу обработки прерывания.

Сравнение выполняется со всеми заданными значениями, независимо
от порядка, в котором эти значения зарегистрированы.
Если значение PV изменяется, измененное PV будет сравнено с
заданным значением в таблице, даже если PV изменяется в тот момент,
когда выполняется процедура сравнения с заданным значением.

В задаче обработки прерывания можно немедленно включить (выключить) обычный выход контроллера.

У меня кстати старый позиционер H8PS-8BFP под абсолютный энкодер валяется, нужен?

Филоненко Владислав
18.03.2016, 10:42
Обмен между ЦПУ и PRU (где крутятся счётчики) не такой быстрый, как хотелось бы.
поэтому в режиме прямого управления всё работает иначе чем в режиме счетчиков.

Newcomer
18.03.2016, 10:48
базовый принцип работы ПЛК: установка входов (данных регистров) -> обработка -> установка выходов === это все ОСНОВНОЙ цикл... в таймере вы конечно можете считать регистр, но там будет одно и тоже значение

Владислав, подтвердите, что Дмитрий Артюховский истину глаголит и делу конец.

Филоненко Владислав
18.03.2016, 14:15
Да, так и есть. Для быстрой обработки есть OwenLogicRT

Sulfur
25.05.2016, 14:45
Получил комплект ПЛК110-60 + СП307Б. Перетащил предыдущий проект в новый ПЛК, наладил связь и пр.
Появились проблемы, а значит и вопросы.
1. Как посчитать время выполнения программного кода? Интересует кусок, который работает по прерыванию таймера 20мкс:

24566

2. Возможны ли обрывы связи из за того, что в таймере крутится слишком длинный код?

Наблюдается пропадание связи ПЛК<>ОП при рекомендуемых значениях (115200). При снижении скорости до 19200 обрывы случаются крайне редко, но всё же есть. На скорости 9600 обрывов связи не замечено. Теряет связь именно ПЛК, т. к. перезагрузка ОП к восстановлению связи не приводит. После перезагрузки только ПК при включенной ОП связь восстанавливается. ПЛК-слейв, ОП-мастер, Модбас РТУ. При написании программы правило, что переменная должна записываться только в одном месте соблюдено.
ЗЫ: И еще один маленький вопросик: как на ST прописать действие по переднему фронту импульса без применения ФБ?

Филоненко Владислав
26.05.2016, 11:14
1. Время можно получить через SysLibTime, есть 2 поля, где время в мкс. Считайте.
2. Возможны. прерывание высокоприоритетно (по сравнению с задачами) и забивает (если длинное) всю остальную работу ПЛК.
3. if ((new_val<>old_val)AND (new_val)) then Действие(); old_val:=new_val; end_if

Sulfur
27.05.2016, 06:59
1. Спасибо, буду разбираться.
2. Сокращал код, временно отключая разные участки - эффекта не дало. На ПЛК110.60 старой модификации в таймере крутится тот же код (до 13 строчки), проблем со связью на 115200 не наблюдается. Правда там ОП ИП320.
3. Спасибо. Но слишком сложная конструкция в плане времени работы. Думал, что есть специализированная команда.

Филоненко Владислав
27.05.2016, 15:02
Цикл меняли? Код увидеть можно?

Sulfur
30.05.2016, 10:19
Цикл таймера? Нет, он стоит по умолчанию 20мкс. Минимальный цикл основной программы ПЛК менял в диапазоне 5-50мс. В данный момент при 5 мкс и скорости 9600 обрывов не наблюдается. При МинЦикле до 50мс обрывы случаются на любой скорости, выше 19200, но жутко тормозит отображение реалтайм переменных на ОП. В самой программе нет мощных вычислений, примитивная релейная логика. Правда есть несколько таймеров.
24635

Филоненко Владислав
01.06.2016, 08:14
1. Снизьте цикл ПЛК до 2 мс. увеличивать стоит только при очень больших программах.
2. Прошейтесь 0.3.53
3. Попробуйте увеличить период вызова таймера до 50 мкс.
4. При цикле 50 мс отображение переменных и должно тормозить.

Sulfur
02.06.2016, 13:10
2. Сделано. Проблема есть.
3. Как я уже говорил, по моим наблюдения проблемы со связью не зависят от количества кода в прерывании таймера. Я пробовал сокращать, пробовал вообще крутить там "пустую" программу - безрезультатно.

Филоненко Владислав
03.06.2016, 15:11
Значит дело не в прерывании. У нас такое поведение не встречалось

Филоненко Владислав
03.06.2016, 15:14
Попробуйте пустую программу с прерыванием. И проверьте гальванику на порту, возможны наводки. Заземлите кабель (перед заземлением проверьте разность потенциалов) или воспользуётесь usb/ethernet

Sulfur
07.06.2016, 10:56
Пробовал сокращать программу в прерывании до одной банальной операции присваивания. Проблемы со связью наблюдаются.
ПЛК и ОП в данный момент пользую на столе, различных наводок быть не должно, т. к. рядом нет никаких источников помех. В качестве провода связи использовал витую пару длиной 30 см. Проблема все равно наблюдается. На скорости 9600 проблема отсутствует. Ставил прерывание таймера на 40мкс - результата это тоже не дало. Ethernet пользовать не получится, т. к. ОП не имеет этого порта (СП307-Б).
Заметил одну особенность: в момент подвисания обмена ПЛК продолжает работать, обсчет энкодера идет, счет не срывается.
Скорость отображения на 9600 устраивает вполне. Высокая скорость обмена не принципиальна для моей задачи, в приоритете надежность работы.
Сейчас работаю над изготовлением блока согласования уровней ПЛК-сервопривод. Решил всё же сделать предварительный счетчик-делитель для снижения частоты импульсов по высокоскоростному счетному входу. Поскольку использовать встроенные в ПЛК модули энкодера и высокоскоростного счетчика одновременно не получится, придется их обсчет организовывать программно.

IIeroniux
01.08.2016, 08:31
Добрый день! Не буду создавать новую тему, напишу здесь - тем более, что тема полностью отражает мой вопров.

Задача - отслеживать положение плиты, которую перемещает винтовой домкрат.

Асинхронный двигатель нагружен на винтовой домкрат (двухвальный, с одной стороны двигатель, с другой стороны установлен инкрементальный энкодер), домкрат перемещает плиту.
Двигатель вращается со скоростью 1500 об/мин, энкодер - 1024 имп/об, т.е. получается 25,6 кГц (1500*1024/60). Необходимо определять текущее положение плиты с точностью +/- 0,5 мм.
Планируем приобрести ПЛК 110 М02 - сможет ли он подсчитывать импульсы при такой частоте без пропусков?
Спрашиваю потому, что первая редакция ПЛК110, при заявленных 10 кГц, реально работала до 2-3 кГц, об этом немало писали на форуме.

Спасибо.

IVM
01.08.2016, 09:29
А какова цена одного импульса энкодера ?

IIeroniux
01.08.2016, 10:23
За 1 импульс (всего их 1024 на оборот вала энкодера) плита проезжает 0,00022 мм.
Но мне бы не хотелось, что бы ПЛК пропускал импульсы. Т.к. текущее положение будет хранится в ретейне, и, как я понимаю, со временем будет накапливаться ошибка. Если только не обнулять счетчик в нижнем положении, там ход плиты небольшой - порядка 500 мм.

maximov2009
01.08.2016, 10:46
Добрый день. Может проще взять энкодер с меньшим разрешением. В Вашем случае за один полный оборот перемещение плиты быдет 0,225мм. (согласно Вашим данным). Тогда, чтобы уложится в погрешность достаточно одного индуктивного датчика и болтика на валу, чтобы получить приемлемы результат. Или хотя бы энкодер 180имп/оборот. Тогда с частотой проблем не будет.
С уважением.

IIeroniux
01.08.2016, 10:59
Ну это понятно - разрешение энкодера ещё можно уменьшить. А болт куда предлагаете - на винт? Так по нему плита ходит, вкручивать не вариант.

По расчетам получается 25,6 кГц, что, в теории, укладывается в способность МО2 с четырехкратным запасом. Вот и хотелось узнать, оставлять 1024 импульса или подстраховаться и уменьшать разрешение.

maximov2009
01.08.2016, 11:35
Насчёт болтика я образно. Обычно делается выступ, типа шпонки, чтобы индуктивный датчик не реагировал на вал, а только на этот выступ. Поставить можно или в месте, где вал двигателя соединяется с винтом, или там где устанавливаете энкодер. Обычно используется для определения скорости вращения, если сильно большая точность не нужна. Да и как писал в Вашем случае её бы хватило вполне.
А насчёт Вашего энкодера - если уже куплен такой, то пробуйте. Если нет, я бы взял с меньшим разрешением.
У нас в основной массе на станках для определения цикла стоят на 360. Вполне хватает и проблем с проглатыванием импульсов нет.
С уважением.

Вольд
01.08.2016, 11:52
Ну это понятно - разрешение энкодера ещё можно уменьшить. А болт куда предлагаете - на винт? Так по нему плита ходит, вкручивать не вариант.

По расчетам получается 25,6 кГц, что, в теории, укладывается в способность МО2 с четырехкратным запасом. Вот и хотелось узнать, оставлять 1024 импульса или подстраховаться и уменьшать разрешение.

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

IIeroniux
01.08.2016, 11:54
to maximov2009: Понятно, спасибо за совет. Установку с домкратом пока ещё чертят конструктора, так что поменять всё можно. В крайнем случае возьму ~120 импульсов/оборот, порядка 3 кГц.


Автор темы сам себе проблему создал. Энкодер для данной задачи выбран неверно, я бы даже сказал бездарно. Нормальное решение вопроса - это замена энкодера.
Вольд, ты уж расскажи как правильно энкодер выбирать. Я за советом пришел, а не выслушивать ''ты косяк, а как правильно я тебе не скажу":)

Вольд
01.08.2016, 12:36
Вольд, ты уж расскажи как правильно энкодер выбирать. Я за советом пришел, а не выслушивать ''ты косяк, а как правильно я тебе не скажу":)

Вопрос детский. Тебе надо не улыбаться, а плакать. Если нужна точность позиционирования +/- 0,5 мм, то количество импульсов на 1 оборот энкодера должно быть таким, чтобы цена одного импульса была скажем 0,1 мм. Этого хватит с лихвой для обеспечения заданной точности позиционирования.

IIeroniux
01.08.2016, 13:06
Спасибо за информацию, ты классный. Энкодер заложили конструкторы, попросили узнать - подходит или нет под наши приборы. Я подсчитал частоту и спросил реальный опыт применения.
Я только не понял - зачем c порога насмешка. Вежливо зашел, поздоровался... Ладно, проехали.

По теме: ПЛК ОВЕН используем постоянно, наверняка будут другие задачи с энкодерами. Как ведет себя [М02] при частоте 25 кГц, не пропускает импульсы?

Филоненко Владислав
01.08.2016, 14:34
Добрый день! Не буду создавать новую тему, напишу здесь - тем более, что тема полностью отражает мой вопров.

Задача - отслеживать положение плиты, которую перемещает винтовой домкрат.

Асинхронный двигатель нагружен на винтовой домкрат (двухвальный, с одной стороны двигатель, с другой стороны установлен инкрементальный энкодер), домкрат перемещает плиту.
Двигатель вращается со скоростью 1500 об/мин, энкодер - 1024 имп/об, т.е. получается 25,6 кГц (1500*1024/60). Необходимо определять текущее положение плиты с точностью +/- 0,5 мм.
Планируем приобрести ПЛК 110 М02 - сможет ли он подсчитывать импульсы при такой частоте без пропусков?
Спрашиваю потому, что первая редакция ПЛК110, при заявленных 10 кГц, реально работала до 2-3 кГц, об этом немало писали на форуме.

Спасибо.

да, может работать.

IIeroniux
02.08.2016, 06:05
Владислав, спасибо!

Sulfur
04.10.2016, 13:48
В продолжении темы быстрого счетчика и энкодера в одном флаконе.
Покурил мануалы касательно Fast Encoder + Counter, появился вопрос.
Правильно ли я понимаю работу регистра быстрого счетчика?
26832
Т. е. насколько я понял, регистр счетчика %IW0.1 обнуляется в конце цикла ПЛК. Что бы счет не прерывался, мне необходимо аккумулировать состояние в начале каждого цикла. Сброс глобального счета выполняется обнулением переменной-аккумулятора CounTransport.
При использовании этого способа скорость счета будет составлять заявленные 100кГц?

Филоненко Владислав
04.10.2016, 20:40
В продолжении темы быстрого счетчика и энкодера в одном флаконе.
Покурил мануалы касательно Fast Encoder + Counter, появился вопрос.
Правильно ли я понимаю работу регистра быстрого счетчика?
26832
Т. е. насколько я понял, регистр счетчика %IW0.1 обнуляется в конце цикла ПЛК. Что бы счет не прерывался, мне необходимо аккумулировать состояние в начале каждого цикла. Сброс глобального счета выполняется обнулением переменной-аккумулятора CounTransport.
При использовании этого способа скорость счета будет составлять заявленные 100кГц?

Это описание работы счётчика на ПЛК1хх без буковок M01 или M02. С буковками не обнуляется.

Sulfur
05.10.2016, 06:27
А как в таком случае обнулять счет на ПЛК с буковками М02?

Филоненко Владислав
05.10.2016, 12:09
Никак. Это технически невозможно. "Обнуление" должно происходить в основной программе

Sulfur
05.10.2016, 13:11
Уважаемый Владислав, я понимаю, что краткость - сестра таланта, однако можно по подробнее пояснить про обнуление быстрого счетчика в 110М2? Если обнулять счетчик в принципе невозможно вообще никак и нигде, то какой смысл в этом счетчике?
Формат регистра счетчика - WORD, т. е. 0…65535 по абсолютному значению, т. е. придется программно учитывать переполнение аппаратного счетчика?

Владимир Ситников
06.10.2016, 12:11
Если обнулять счетчик в принципе невозможно вообще никак и нигде, то какой смысл в этом счетчике?
У вас установлен счётчик электричества?

Теперь примените к нему свои слова "Если обнулять счетчик в принципе невозможно вообще никак и нигде, то какой смысл в этом счетчике?"
И как? Нет смысла в "счётчике электричества" или есть?

Теперь вернёмся к "быстрому счётчику". Да, он просто считает, и когда достигает максимума, то сбрасывается.
"Учитывать переполнение" это пара строк кода:
total : DWORD;
newValue, prevValue : WORD;

newValue := counter;
total := total + WORD_TO_DWORD(newValue - prevValue);
prevValue := newValue;


Разумеется, и "total" тоже рано или поздно может переполниться.

Какая конечная задача требуется от этого счётчика?

Sulfur
06.10.2016, 12:37
Какая конечная задача требуется от этого счётчика?
В начале темы я описывал задачу. Но повторюсь:
1. На валу двигателя транспорта подачи материала установлен энкодер с разрешением 500 имп\об.
2. Частота вращения двигателя - максимум 3000 об\мин (обычно 2000 об\мин)
3. Двигатель работает от частотника.
4. Время, достаточное для подачи нужного количества материала ~0.4-0.6 сек за цикл.
5. Энкодер подключен к счетчику, который управляет частотником двигателя.
6. Двигатель низкоинерционный, остальная механика транспорта тоже. Останов происходит практически мгновенно, переезды есть, но они не критичны и их можно попытаться компенсировать программно.
От данного счетчика требуется отсчитать нужное количество импульсов и остановить двигатель. В следующем цикле счетчик должен быть обнулен до старта двигателя (переменная total в Вашем примере).
Т. е. счетчик должен уверенно и без пропусков считывать от одной фазы энкодера сигнал частотой до 30 кГц.

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


ЗЫ: Про сервопривода с функцией позиционера я знаю, однако задача стоит именно в таком способе позиционирования.

Владимир Ситников
06.10.2016, 13:05
В принципе, я примерно так и сделал, как в предоставленном примере, но надеялся, что вдруг есть какая-нибудь другая возможность управления аппаратным счетчиком.
А какая точность/стабильность получилась?
Устраивает?
Объект сдан или ещё подобное планируется?

Раз вы написали "В продолжении темы быстрого счетчика и энкодера в одном флаконе", поэтому я подумал, что у вас какая-то новая задача, т.к. исходная тема обсуждалась в марте:

16.03.2016, 14:27: 1. На "присоединиться" как обычно нет времени и всё нужно готовое и "уже вчера". Сомневаюсь, что со своими скромными знаниями в программировании могу быть полезен этому сообществу.

Попробую ещё разок:

Судя по тому, что использовать цикл менее 1мс не рекомендуют (со словами "отвалится ethernet и много чего ещё"), то варианта 2:
1) Присоединяться к клубу любителей PRU программирования (http://www.owen.ru/forum/showthread.php?t=22169&highlight=OwenLogicRT). У быстрых выходов обещают время реакции 0.02мс, что в 100 раз точнее необходимого вам.

Если видели тему по PRU программированию, то могли заметить, что я уже сделал ФБ для управления ШД с разгоном и поэтессами (http://www.owen.ru/forum/showthread.php?t=22169&page=47&p=222937#post222937).

Можно сделать PRU ФБ и для вашей задачи. Пока ФБ делаю только я, но, возможно, скоро их смогут делать все желающие.

Например:
1) На вход "количество импульсов" -- длина пробега, и параметр "поехали"
2) По команде "поехали" блок будет активировать один из быстрых выходов
3) При достижении нужного количества импульсов, выход отключается
4) На выходе ФБ возвращается "пройденное расстояние" (на всякий случай) и "состояние" (ждём команды, едем, приехали)
5) В состоянии "приехали" счёт импульсов продолжается (чтобы можно было понять "какой перелёт оказался")
6) В состоянии "ждём команды" импульсы просто игнорируются. Или с ними что-то нужно делать?

Такой ФБ сможет без проблем отрабатывать на частотах порядка 100кГц, при этом 485, ethernet и прочее отваливаться не будет.

Sulfur
06.10.2016, 13:55
А какая точность/стабильность получилась?
Устраивает?
Объект сдан или ещё подобное планируется?


1. По сравнению с полноценными позиционерами - хуже.
2. Среднее расстояние подачи - 100-120мм, настоящий позиционер "гуляет" в пределах +-0,5 мм (возможно из за деформации материала и люфтов в механике), подобная реализация (не на ПЛК) "гуляет" на +-2мм, однако на %% брака это практически не сказывается, только немного увеличивается расход материала.
3. Данный проект находится в вялотекущей разработке, на реальной машине работает несколько другая система, но она морально и физически устарела, и просится на замену. Реализация этого счетчика средствами ПЛК позволит исключить один жутко импортный блок.


Если видели тему по PRU программированию, то могли заметить, что я уже сделал ФБ для управления ШД с разгоном и поэтессами.


Это замечательно. Тему я просматривал, разработка нужная и полезная, но в моем случае. Т. к. имеющиеся привода не поддерживают принцип управления Step\Dir.


Можно сделать PRU ФБ и для вашей задачи. Пока ФБ делаю только я, но, возможно, скоро их смогут делать все желающие.

Например:
1) На вход "количество импульсов" -- длина пробега, и параметр "поехали"
2) По команде "поехали" блок будет активировать один из быстрых выходов
3) При достижении нужного количества импульсов, выход отключается
4) На выходе ФБ возвращается "пройденное расстояние" (на всякий случай) и "состояние" (ждём команды, едем, приехали)
5) В состоянии "приехали" счёт импульсов продолжается (чтобы можно было понять "какой перелёт оказался")
6) В состоянии "ждём команды" импульсы просто игнорируются. Или с ними что-то нужно делать?



Это будет просто прекрасно.
Я даже прикидывал примерную схему тут (http://www.owen.ru/forum/showthread.php?t=22169&p=209664&viewfull=1#post209664)
Параллельно с данным счетчиком должен работать ABZ энкодер с небольшой добавкой в виде детектора физического нуля после включения ПЛК.

Владимир Ситников
06.10.2016, 14:03
Это будет просто прекрасно.
Если будет блок, сделаете "фото/видео" отчёт об установке?


Параллельно с данным счетчиком должен работать ABZ энкодер с небольшой добавкой в виде детектора физического нуля после включения ПЛК.
Это как?
"мотать материал пока не достигнем Z метки"?

Sulfur
06.10.2016, 14:30
Если будет блок, сделаете "фото/видео" отчёт об установке?

Фото\видео - без проблем. Только не гарантирую когда это будет. В среднесрочной перспективе могу только провести эксперимент на реальной машине, если она встанет на долгий ремонт по железу. В условиях лаборатории проверить весь комплекс просто нет возможности.

Это как?
"мотать материал пока не достигнем Z метки"?

Немного не так. ABZ-энкодер стоит на главном валу машины, это другой двигатель и другой частотник. Разрешение этого энкодера 360имп\об, По показаниям этого энкодера включаются и выключаются разные другие устройства, в том числе и транспорт. Детектор физического нуля необходим для того, что бы не включались устройства до тех пор, пока физический ноль не будет найден. Это связано с тем, что регистр энкодера в момент включения ПЛК равен нулю, а машина практически никогда не останавливается в 0 (обычно 150-190*), появляется "смещение", которое может привести к поломке оснастки и другой механики, если устройства включатся не в свое время. После определения физ.нуля детектор не оказывает никакого влияния на работу машины до следующего выключения.
В одном проекте я реализовал этот детектор программно ( на ПЛК110-60 старой модели), т. к. и модуль энкодера делал тоже программно, а показания энкодера сохранял а Retain.

petera
06.10.2016, 14:52
Уважаемый Владислав, я понимаю, что краткость - сестра таланта, однако можно по подробнее пояснить про обнуление быстрого счетчика в 110М2? Если обнулять счетчик в принципе невозможно вообще никак и нигде, то какой смысл в этом счетчике?
Формат регистра счетчика - WORD, т. е. 0…65535 по абсолютному значению, т. е. придется программно учитывать переполнение аппаратного счетчика?


......
От данного счетчика требуется отсчитать нужное количество импульсов и остановить двигатель. В следующем цикле счетчик должен быть обнулен до старта двигателя (переменная total в Вашем примере).

1. Ненужно учитывать переполнение.
2. Зачем считать обязательно с нуля? Совершенно ни к чему обнулять регистр счетчика, нужно продолжать считать импульсы с того состояния, которое осталось в нем от предыдущего цикла.

Просто из текущего значения в счетчике нужно вычитать значение, которое было в нем перед стартом, т.к. WORD - без знаковое целое число, то результат арифметической операции "вычитание" всегда будет правильным, не смотря не то, что после 65535 счетчик начнет считать с 0.
Например
в счетчике было 65530
после старта значения в нем будут увеличиваться 65530, 65531, 65532, 65533, 65534, 65535, 0, 1, 2 ....
т.е. начальное значение в счетчике было 65530.
Теперь каждый раз при обращении в программе к регистру счетчика нужно вычитать начальное значение, в нашем случае получим
65530-65530=0
65531-65530=1
65532-65530=2
65533-65530=3
65534-65530=4
65535-65530=5
0 - 65530=6
1 - 65530=7
2 - 65530=8
3 - 65530=9
и т.д.
Т.е. никакое переполнение учитывать не надо.

Sulfur
06.10.2016, 15:03
Спасибо, проверим в реале.

Newcomer
06.10.2016, 15:11
1. Ненужно учитывать переполнение.
2. Зачем считать обязательно с нуля? Совершенно ни к чему обнулять регистр счетчика, нужно продолжать считать импульсы с того состояния, которое осталось в нем от предыдущего цикла.

Просто из текущего значения в счетчике нужно вычитать значение, которое было в нем перед стартом, т.к. WORD - без знаковое целое число, то результат арифметической операции "вычитание" всегда будет правильным, не смотря не то, что после 65535 счетчик начнет считать с 0.
Например
в счетчике было 65530
после старта значения в нем будут увеличиваться 65530, 65531, 65532, 65533, 65534, 65535, 0, 1, 2 ....
т.е. начальное значение в счетчике было 65530.
Теперь каждый раз при обращении в программе к регистру счетчика нужно вычитать начальное значение, в нашем случае получим
65530-65530=0
65531-65530=1
65532-65530=2
65533-65530=3
65534-65530=4
65535-65530=5
0 - 65530=6
1 - 65530=7
2 - 65530=8
3 - 65530=9
и т.д.
Т.е. никакое переполнение учитывать не надо.

petera, вы попробуйте в симуляторе CoDeSys сделать A := 0 - 65530; , где A объявлено как WORD и посмотрите что получается.

Владимир Ситников
06.10.2016, 15:14
petera, вы попробуйте в симуляторе CoDeSys сделать A := 0 - 65530; , где A объявлено как WORD и посмотрите что получается.

petera всё правильно написал, но тут нужно не только счётчик получать, но и реагировать на него быстрее, чем ПЛК цикл.

Такой код (http://www.owen.ru/forum/showthread.php?t=23600&p=222948&viewfull=1#post222948) работает в симуляторе: total := total + WORD_TO_DWORD(newValue - prevValue);

Но это не решает проблему "быстрого управления" -- эта проблема решится PRU программой.

petera
06.10.2016, 15:24
petera, вы попробуйте в симуляторе CoDeSys сделать A := 0 - 65530; , где A объявлено как WORD и посмотрите что получается.
A: WORD;
С: WORD := 65530;

A:=0-C;
Получится "6".
Простой пример


PROGRAM PLC_PRG
VAR
old: WORD;
curr_count: WORD := 65500;
NOTAL_count: WORD;
PUSK: BOOL;
TON1: TON;
state: INT;
END_VAR

TON1(IN:=NOT TON1.Q , PT:= t#100ms );
CASE state OF
0:
IF PUSK THEN
old:=curr_count;
state:=1;
END_IF
1:
curr_count:=curr_count + BOOL_TO_INT(TON1.Q);
NOTAL_count:=curr_count-old;
IF NOT PUSK THEN
NOTAL_count:=0;
state:=0;
END_IF
END_CASE

https://www.youtube.com/watch?v=bDNrHoHE73U

Владимир Ситников
06.10.2016, 15:27
Получится "6".
Простой пример

Поменяйте тип NOTAL_count на DWORD и ваш пример "сломается".

И, да, если отслеживать достаточно не более 65535 импульсов, то можно и WORD'ом обойтись.

Newcomer
06.10.2016, 15:38
petera всё правильно написал, но тут нужно не только счётчик получать, но и реагировать на него быстрее, чем ПЛК цикл.

Такой код (http://www.owen.ru/forum/showthread.php?t=23600&p=222948&viewfull=1#post222948) работает в симуляторе: total := total + WORD_TO_DWORD(newValue - prevValue);

Но это не решает проблему "быстрого управления" -- эта проблема решится PRU программой.

total := total + WORD_TO_DWORD(0 - 65530); Если total равно 0, то результат операции получится 4294901766 , а не 6.

petera
06.10.2016, 15:39
Поменяйте тип NOTAL_count на DWORD и ваш пример "сломается".

И, да, если отслеживать достаточно не более 65535 импульсов, то можно и WORD'ом обойтись.

Да, в этом виде сломается.
Просто хотел ответить на частный вопрос

Если обнулять счетчик в принципе невозможно вообще никак и нигде, то какой смысл в этом счетчике?
Формат регистра счетчика - WORD, т. е. 0…65535 по абсолютному значению, т. е. придется программно учитывать переполнение аппаратного счетчика?
И показал, что обнулять счетчик не надо.

petera
06.10.2016, 15:41
total := total + WORD_TO_DWORD(0 - 65530); Если total равно 0, то результат операции получится 4294901766 , а не 6.

Да не константы 0 и 65530 надо использовать, а переменные WORD

Newcomer
06.10.2016, 15:41
Правильно будет так: total := total + WORD_TO_INT(newValue - prevValue);

Newcomer
06.10.2016, 15:48
Да не константы 0 и 65530 надо использовать, а переменные WORD

Вы свою запись приведите, как я привел в посте #99. И не надо много кода писать и кино показывать. Всего одна строчка.

Newcomer
06.10.2016, 16:08
Да не константы 0 и 65530 надо использовать, а переменные WORD

total := total + WORD_TO_DWORD(newValue - prevValue); дает не верный результат.

total := total + WORD_TO_INT(newValue - prevValue); дает верный результат.

Владимир Ситников
06.10.2016, 16:38
total := total + WORD_TO_DWORD(newValue - prevValue); дает не верный результат.

total := total + WORD_TO_INT(newValue - prevValue); дает верный результат.

Откуда такой вывод?

WORD_TO_DWORD нужно когда считаем "общее количество проделанных импульсов" (именно такая задача у автора темы) -- тут в prevValue/nextValue нужно брать счётчик.

WORD_TO_INT это когда пытаемся определить "абсолютное положение энкодера", но тогда и в prevValue/nextValue нужно брать не "счётчик", а реально "значение энкодера"

26881

Newcomer
06.10.2016, 17:13
Откуда такой вывод?

WORD_TO_DWORD нужно когда считаем "общее количество проделанных импульсов" (именно такая задача у автора темы) -- тут в prevValue/nextValue нужно брать счётчик.

WORD_TO_INT это когда пытаемся определить "абсолютное положение энкодера", но тогда и в prevValue/nextValue нужно брать не "счётчик", а реально "значение энкодера"

26881

Это для petera.

petera
06.10.2016, 19:04
Вы свою запись приведите, как я привел в посте #99. И не надо много кода писать и кино показывать. Всего одна строчка.

Зачем мне Ваши глупости повторят?
Я же сказал, что т.к. WORD - без знаковое целое число, то результат арифметической операции "вычитание" всегда будет правильным, не смотря не то, что после 65535 счетчик начнет считать с 0.
Т.е. именно для без знаковых целых переменных
0 - 65530=6
А Вы мне подсовываете КОНСТАНТЫ
Откуда компилятору знать, что эти константы надо рассматривать как без знаковые целые формата WORD, а не REAL или INT?
По этому только так
A: WORD;
С: WORD := 65530;
A:=0-C;
Получится "6"

Sulfur
07.10.2016, 06:41
Господа программисты, малость облегчу задачу для моего случая. Время работы двигателя транспорта программно ограничено по времени (1 сек) при любом состоянии счетчика и любой ситуации. Это сделано для предотвращения недопустимых ситуаций из за поломки энкодера и\или ошибки оператора станка при его настройке. По расчетам у меня получается примерно следующее: частота вращения двигателя транспорта 3000об\мин = 50 об\с, при разрешении энкодера 500 имп\об имеем 25000 импульсов. При среднем фактическом времени работы 0.4 сек имеем 10000 импульсов. Типы DWORD и DINT в моей задаче не актуальны.

Scream
07.10.2016, 08:20
Добрый день, немного оффтоп
Пришел плк110-220.60-K-М цвета корпуса такие же как на плк 160, это значит старая линейка?
М02 обновленный стиль корпуса ведь?

Sulfur
07.10.2016, 08:30
М02 обновленный стиль корпуса ведь?

ПЛК110[М2] (http://www.owen.ru/catalog/programmiruemij_logicheskij_kontroller_oven_plk110/opisanie)
ПЛК110[старый] (http://www.owen.ru/catalog/plc110_old/opisanie)

Владимир Ситников
07.10.2016, 12:14
Господа программисты, малость облегчу задачу для моего случая. Время работы двигателя транспорта программно ограничено по времени (1 сек) при любом состоянии счетчика и любой ситуации. Это сделано для предотвращения недопустимых ситуаций из за поломки энкодера и\или ошибки оператора станка при его настройке. По расчетам у меня получается примерно следующее: частота вращения двигателя транспорта 3000об\мин = 50 об\с, при разрешении энкодера 500 имп\об имеем 25000 импульсов. При среднем фактическом времени работы 0.4 сек имеем 10000 импульсов. Типы DWORD и DINT в моей задаче не актуальны.

А кто вас спрашивает? Шутка.

Держите программу: 26911

Порядок пользования:
"online -> write file to plc -> PRU0.prg"
перезагружаем ПЛК

ФБ PRU_ABZ и PRU_CUTTER.
Через PRU_ABZ.ZERO_DETECTED можно узнать "обнаружен ли уже ноль"
Через PRU_CUTTER управляем мотором (указываем нужное количество импульсов и говорим "поехали!").


Энкодер подключать к 1-ым трём входам.
На какие именно фронты сигнала энкодера реагировать это, похоже, тот ещё вопрос, поэтому я сделал первое что пришло в голову: блок реагирует на вообще все фронты A и B сигналов. Фильтрации от дребезга нет. Возможно, стоит добавить.


FUNCTION_BLOCK PRU_ABZ
VAR_INPUT
(*
A -- in1
B -- in2
Z -- in3
*)
END_VAR
VAR_OUTPUT
VALUE : WORD; (* increases or decreases depending on encoder direction *)
COUNTER : WORD; (* always increases *)
ZERO_DETECTED: BOOL; (* true when Z was detected at least once *)
END_VAR


FUNCTION_BLOCK PRU_CUTTER
(*
When ENABLE=TRUE, the block activates out1 until RUN_LENGTH encoder pulses observed.
RUN_LENGTH can be changed at any time.
*)
VAR_INPUT
ENABLE: BOOL;
RUN_LENGTH: DWORD; (* pulses *)
END_VAR
VAR_OUTPUT
STATE : PRU_CUTTER_STATE; (* INIT -> RUN -> STOP *)
OFFSET: DWORD; (* actual offset *)
END_VAR

TYPE PRU_CUTTER_STATE : (
INIT_CUTTER, (* CUTTER is waiting for new configuration and activation ENABLE=TRUE signal *)
RUN_CUTTER, (* CUTTER is moving *)
STOP_CUTTER (* CUTTER is stopped and it is waiting for ENABLE=FALSE to switch to INIT state *)
);
END_TYPE




Собственно, программа:
26908

PRU_ABZ:
26909

PRU_CUTTER:
26910

petera
07.10.2016, 12:46
На какие именно фронты сигнала энкодера реагировать это, похоже, тот ещё вопрос, поэтому я сделал первое что пришло в голову: блок реагирует на вообще все фронты A и B сигналов.
Что значит "тот еще вопрос". Все должно быть однозначно.
26912

http://www.owen.ru/forum/showthread.php?t=22717&p=187362&viewfull=1#post187362

Владимир Ситников
07.10.2016, 12:57
Что значит "тот еще вопрос". Все должно быть однозначно.
26912

http://www.owen.ru/forum/showthread.php?t=22717&p=187362&viewfull=1#post187362

Z метка в какой момент должна положение сбрасывать?

Если я правильно понимаю, то "во время, когда Z=TRUE" запросто могут фронты A и B приходить.

Вольд
07.10.2016, 12:58
На какие именно фронты сигнала энкодера реагировать это, похоже, тот ещё вопрос, поэтому я сделал первое что пришло в голову: блок реагирует на вообще все фронты A и B сигналов. Фильтрации от дребезга нет. Возможно, стоит добавить.


Нет тут никаких вопросов. Считать надо фронты и срезы сигналов А и В.

Владимир Ситников
07.10.2016, 13:01
Нет тут никаких вопросов. Считать надо фронты и срезы сигналов А и В.

Сбрасывать, сбрасывать когда?

Если сбрасывать просто по фронту Z, то момент сброса будет зависеть от фактического направления вращения.

Как вариант, можно следить за направлением вращения и искать конкретный фронт в зависимости от направления вращения.

Ну или просто забить, и сбрасывать положение при любом фронте Z (что я и сделал)

Вольд
07.10.2016, 13:13
Сбрасывать, сбрасывать когда?

Если сбрасывать просто по фронту Z, то момент сброса будет зависеть от фактического направления вращения.

Как вариант, можно следить за направлением вращения и искать конкретный фронт в зависимости от направления вращения.

Ну или просто забить, и сбрасывать положение при любом фронте Z (что я и сделал)

А зачем сбрасывать по фронту Z ? Сброс будет по переполнению счетчика.

petera
07.10.2016, 13:14
Z метка в какой момент должна положение сбрасывать?

Если я правильно понимаю, то "во время, когда Z=TRUE" запросто могут фронты A и B приходить.

Про Z метку. Привязка к фронтам А и В
26915

Условно показан энкодер с одним "импульсом" на оборот.
Учтите, что один импульс - четыре такта изменения сигналов А и В.

Владимир Ситников
07.10.2016, 13:22
Про Z метку. Привязка к фронтам А и В
26915

Она всегда именно так выглядит?
Не будет ли того, что "длина Z" равна длине, скажем A?

Да даже если она привязана ко всем фронтам A и B, то всё равно "физический ноль" не может соответствовать сразу обоим фронтам Z метки.
Я и говорю: либо нужно эту погрешность проигнорировать, либо считать всегда один конкретный фронт Z метки (скажем, "левый"), который будет либо RTRIG, либо FTRIG в зависимости от направления вращения.

Вольд
07.10.2016, 13:22
Указатель нулевой отметки / импульс полного оборота (выход N)

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

Sulfur
07.10.2016, 13:24
Z метка в какой момент должна положение сбрасывать?
Если я правильно понимаю, то "во время, когда Z=TRUE" запросто могут фронты A и B приходить.

Сброс счетчика ABZ-энкодера должен происходить при True на всех его трех входах - это будет самый точный "ноль". Фронт значения особого не имеет (во всяком случае для моего применения), но предпочтительнее передний.

За программу спасибо! Не ожидал, что будет так быстро готово. Постараюсь на следующей неделе воплотить всё это в железе, но правда на столе. Заодно проверю свой вариант решения "стандартными" средствами.

Не совсем понятно назначение выходной переменной counter в блоке PRU_ABZ_ENCODER. Если это просто счет импульсов, то оно без надобности. Вполне достаточно детектора истинного нуля и регистра показаний.

Филоненко Владислав
07.10.2016, 13:25
В самом энкодере всегда сбрасывают по обоим сторонам Z.
А в программе управления, зная направление вращения - учитывают это при расчёте положения

Владимир Ситников
07.10.2016, 13:25
Не совсем понятно назначение выходной переменной counter в блоке PRU_ABZ_ENCODER. Если это просто счет импульсов, то оно без надобности. Вполне достаточно детектора истинного нуля и регистра показаний.
Вам без надобности, а кому-то может и пригодиться.

Как-никак, а ABZ энкодер не только вам может оказаться полезным.

petera
07.10.2016, 13:26
Она всегда именно так выглядит?
Не будет ли того, что "длина Z" равна длине, скажем A?

Да даже если она привязана ко всем фронтам A и B, то всё равно "физический ноль" не может соответствовать сразу обоим фронтам Z метки.
Я и говорю: либо нужно эту погрешность проигнорировать, либо считать всегда один конкретный фронт Z метки (скажем, "левый"), который будет либо RTRIG, либо FTRIG в зависимости от направления вращения.
Привязана к фронтам А и Б, как на рисунке
Условно показан энкодер с одним "импульсом" на оборот.
Учтите, что один импульс энкодера - четыре такта изменения сигналов А и В.
26917

Sulfur
07.10.2016, 13:35
Вам без надобности, а кому-то может и пригодиться.

Не смею оспаривать. Я просто исхожу из соображений минимизации кода.

Владимир Ситников
07.10.2016, 13:58
Расскажу о том, как тестируют эти ФБ.

Берём, например, блок для ABZ энкодера.
Из ST сам собой генерируется следущий java код.
Тут и команды для процессора, и вспомогательные методы, чтобы обращаться ко входам-выходам ФБ не через регистры процессора, а в человекопонятной форме setA/setB/getPosition и т.п.

26919


Потом пишем тест: подаём по очереди значения на входы A/B и смотрим правильно ли блок на них реагирует.
26918

Так же есть аналогичный тест на вращение в другую сторону.

Запускаем тесты, и видим, что работает:
26920

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


Аналогичный тест и для блока "управления мотором":
26921

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

Sulfur
10.11.2016, 14:21
Владимир Ситников
Наконец-то появилось время сесть на мой проект. Начал разбираться с PRU. Появились грабли.
Сделал простенький проект чисто для отработки моей темы, и при добавлении библиотеки pru_cutter.lib при компиляции практически пустого проекта получаю ошибку:
27514
Причем при неиспользовании FB PRU в проекте.

Так же не совсем понятно, как конфигурировать Fast Discrete Input и Fast Discrete Output в конфигурации ПЛК. Ставить Direct Control?

Насколько я понял, выходная переменная VALUE FB PRU_ABZ имеет тип WORD. В моей задаче используется энкодер 360имп\об, причем в работе установки есть ситуация, когда показания энкодера могут иметь отрицательные значения. Хотелось бы иметь тип этой переменной INT, что бы не заморачиваться с лишними преобразованиями.

Владимир Ситников
10.11.2016, 14:56
Владимир Ситников
Наконец-то появилось время сесть на мой проект. Начал разбираться с PRU. Появились грабли.
Сделал простенький проект чисто для отработки моей темы, и при добавлении библиотеки pru_cutter.lib при компиляции практически пустого проекта получаю ошибку:
27514
Причем при неиспользовании FB PRU в проекте.

Ошибки "PRU_FB_GETPARAMETER" означают, что нужно добавить библиотеку pruaccesslib.lib
Сама библиотека находится тут: http://www.owen.ru/forum/showthread.php?t=22169 (pack1.zip)


Так же не совсем понятно, как конфигурировать Fast Discrete Input и Fast Discrete Output в конфигурации ПЛК. Ставить Direct Control?
Без разницы как. Всё равно конфигуратор с этими выходами работать не будет. Вернее, через конфигуратор будут работать только fast out1 и fast out2.

out3 out4 же будут работать только через PRU0 (т.е. через программу)


Насколько я понял, выходная переменная VALUE FB PRU_ABZ имеет тип WORD. В моей задаче используется энкодер 360имп\об, причем в работе установки есть ситуация, когда показания энкодера могут иметь отрицательные значения. Хотелось бы иметь тип этой переменной INT, что бы не заморачиваться с лишними преобразованиями.
Пока WORD.

За время пути, PRU программирование успело подрасти, и можно всю программу для управления быстрыми входами-выходами написать в Hardella (https://github.com/vlsi/ide61131/releases) (ну, это на случай, если логика управления изменится)

Sulfur
22.11.2016, 12:23
Владимир Ситников

Залил все нужные библиотеки во все нужные места, загрузил программу, записал файл PRU0.PRG в ПЛК, разобрался с INT\WORD. Заработало.
Однако не так как ожидалось. Итак, проблемы:
1. Энкодер считает все импульсы по всем фронтам. В результате я имею показания -1440...1440. Решил банальным делением на 4 с отбрасыванием дробной части (TRUNC).
2. Счетчик считает по входу FDI1, т.е. с одного из входов энкодера. А должен считать со входа FDI4 (FDI1=A, FDI2=B, FDI3=Z энкодера).
3. После снятия сигнала enable со входа FB PRU_CUTTER выход FDO3 остается активным. Хотелось бы, что бы этот вход имел FALSE при enable = FALSE в любой ситуации. А так же, чтобы PRU_CUTTER не считал при enable=FALSE.
----------------
По поводу видео - пока еще не готово, но задумал собрать эмулятор сервопривода на шаговом движке, жду комплектующие.

Владимир Ситников
22.11.2016, 14:25
Итак, проблемы:
1. Энкодер считает все импульсы по всем фронтам. В результате я имею показания -1440...1440. Решил банальным делением на 4 с отбрасыванием дробной части (TRUNC).
Ну, можно пообсуждать бага это или фича.
А в целом обработка энкодера устраивает?


2. Счетчик считает по входу FDI1, т.е. с одного из входов энкодера. А должен считать со входа FDI4 (FDI1=A, FDI2=B, FDI3=Z энкодера).
Т.е. счётный вход совсем отдельно?
Я почему-то решил, что считать энкодер нужно.

Считать нужно передние фронты?


3. После снятия сигнала enable со входа FB PRU_CUTTER выход FDO3 остается активным. Хотелось бы, что бы этот вход имел FALSE при enable = FALSE в любой ситуации. А так же, чтобы PRU_CUTTER не считал при enable=FALSE.


Да, режим "аварийной остановки" не был предусмотрен.
В коде это видно: http://www.owen.ru/forum/showthread.php?t=23600&p=223074&viewfull=1#post223074 (см. последнюю картинку -- блок PRU_CUTTER)

Оттуда же следует и обходной вариант: если изменить runLength в 0, то блок остановится.
Но, да, логичнее будет, если оно и по сбросу enable будет останавливаться.


Я понемногу делаю сайт с документацией для среды -- можно пример использовать как "стандартный пример", если не возражаете.
Ну, с фотографией установки и т.п. По-моему, хороший пример. А "реальность" объекта сильно улучшит качество самого примера.

Sulfur
22.11.2016, 14:57
Ну, можно пообсуждать бага это или фича.
А в целом обработка энкодера устраивает?

Да. Мои опасения только в том, что насколько мне известно, операция деления занимает много процессорного времени. Именно поэтому я стараюсь свести к минимуму всю арифметику в главном цикле.




Т.е. счётный вход совсем отдельно?
Я почему-то решил, что считать энкодер нужно.

Счетный вход именно отдельно, т. к. на него идет сигнал с другого устройства.


Считать нужно передние фронты?

Без разницы. Главное, что бы не было пропусков.



Оттуда же следует и обходной вариант: если изменить runLength в 0, то блок остановится.
Но, да, логичнее будет, если оно и по сбросу enable будет останавливаться.

runLength в процессе работы меняться будет крайне редко, и поэтому лучше сделать останов счета и гашение выхода по сигналу enable.


Я понемногу делаю сайт с документацией для среды -- можно пример использовать как "стандартный пример", если не возражаете.
Ну, с фотографией установки и т.п. По-моему, хороший пример. А "реальность" объекта сильно улучшит качество самого примера.
Не возражаю. Готов даже предоставить весь проект модернизации термоформовочной машины Meaf серии BMS600, естественно, когда он будет готов. Однако с реальным "воплощением в железо" не могу назвать даже примерных сроков, т. к. работа ведется по остаточному принципу на перспективу.

Вольд
22.11.2016, 16:48
Считать нужно передние фронты?

Считать надо фронты и срезы сигналов А и В энкодера.

Владимир Ситников
22.11.2016, 17:04
Считать надо фронты и срезы сигналов А и В энкодера.

Не про энкодер речь. А про "сигнал с другого устройства". Раз "без разницы", то сделаю по переднему фронту.

Владимир Ситников
22.11.2016, 17:12
runLength в процессе работы меняться будет крайне редко, и поэтому лучше сделать останов счета и гашение выхода по сигналу enable.
А какой смысл останавливать счёт по остановке enable?
Я думал, что продолжение счёта будет отражать фактический выбег.
Но, конечно, ничто не мешает останавливать счёт.

Sulfur
23.11.2016, 06:41
А какой смысл останавливать счёт по остановке enable?
Я думал, что продолжение счёта будет отражать фактический выбег.
Но, конечно, ничто не мешает останавливать счёт.
Есть в логике машины ситуация, когда транспорт управляется в ручном режиме (заправка материала), причем движение может быть в любую сторону. Именно в этой ситуации и надо что бы счетчик не считал, что бы не накапливать "лишние" показания. Хотя, если сброс счетчика делается по переднему фронту сигнала enable, то данная проблемка не актуальна.

Sulfur
23.11.2016, 07:01
про "сигнал с другого устройства"

По факту, к этому входу будет подключаться либо настоящий энкодер с ценой 500-1024 имп\об (зависит от конкретной модели), либо выход сервопривода, который эмулирует "энкодерный" сигнал. Настоящий энкодер устанавливается непосредственно на вал двигателя привода транспорта. Будет использоваться только одна фаза, поскольку быстрых входов на ПЛК всего 4 шт, 3 из которых заняты под "главный" энкодер.

Владимир Ситников
19.12.2016, 17:25
Счетный вход именно отдельно, т. к. на него идет сигнал с другого устройства.

Задокументировал пример тут: https://hardella.com/docs/pru/examples/material-cutter/

Код входит в стандартную поставку Hardella 1.6.0 -- так что можете упражняться.

Sulfur
23.12.2016, 14:50
Владимир Ситников
Спасибо. Очень увлекательный ресурс. Как раз завершаю работу над эмулятором сервопривода. Вероятно после новогодних каникул предоставлю свою редакцию PRU-блоков, а так же, если все заработает, то и воплощение в "железе", но пока только эмуляцию. По поводу реализации на реальной машине не могу назвать даже примерных сроков, т. к. данное решение зависит не от меня.

Евгений Багаев
28.12.2016, 09:59
Последние сообщения, касающиеся Hardella, были перенесены в соответствующую тему:
http://www.owen.ru/forum/showthread.php?t=23013&page=29
Прошу все обсуждения, касающиеся данного ПО, вести в указанной теме, а также на форуме разработчика.

Sulfur
23.01.2017, 12:48
Сделал эмулятор сервопривода на автономном контроллере шагового двигателя (нонейм) + драйвер ТВ6600 + ШД Nema23 56mm + энкодер Baumer 500имп\об.
В виду невысоких скоростных параметров контроллера не получилось добиться максимальных оборотов ШД. Ориентировочная скорость вращения ШД получилась около 750 об\мин. Срывов счета не наблюдалось. Однако наблюдается переезд после снятия команды работы с контроллера ШД. Переезд примерно 4-6% от заданных параметров.
Во вложении файлы проекта и подправленный проект PRU.
Счет счетчика по входу FDI4 не останавливается после снятия команды enable, сброс происходит по переднему фронту enable.
Выходы FDO2..4 используются для управления приводом (частотником) транспорта. Выход FDO1 может при необходимости использоваться из хост-программы как обычный выход.

Newcomer
23.01.2017, 19:14
В виду невысоких скоростных параметров контроллера не получилось добиться максимальных оборотов ШД. Ориентировочная скорость вращения ШД получилась около 750 об\мин.

Шаг надо сильнее дробить, частоту повышать и все будет чики-пики.

Sulfur
24.01.2017, 10:15
Шаг надо сильнее дробить, частоту повышать и все будет чики-пики.

Автономный контроллер генерирует Степ в диапазоне 0-20000Гц. Шибко не разгонишься. Городить на ПЛК или ПК нет особого желания, да и не в этом стоит задача.
28903

Panalexfix
10.04.2017, 14:13
Доброго времени суток!!!
У меня ПЛК 110-60 К.М. (старый)и два энкодера подключенных на быстрые входа как Fast encoder. Один из энкодеров стоит на вибростоле через амартизирующие проставки и на самом энкодере нет вибрации, а на вал куда крепиться энкодер прикручен механизм подачи бетона и сам вал имеет возможность перемещения вперед-назад (от вибрации и "кривой" конструкции) на какие-то 1-2мм. Энкодер на 10000 имп/об. весь ход 960 имп вперед и назад до 0 имп. При выключеном вибростоле счет идет ровно и правильно, все работает а при включеном начинает бегать хаотично(из-за "кривой" конструкции) хотя сам механизм стоит на месте. Так вот вопрос: подскажите или направьте в правильном направлении, как обработать word который приходит с входов энкодера для игнорирования лишних движений вала??? Пробовал сделать retain переменную в которую по остановке писал положение энкодера, но тогда когда показания прыгали от 960-0 мне выдавало 65535 в этой переменной(максимальное word), а мне надо всего 960???

Panalexfix
10.04.2017, 17:04
никто разобраться помочь не желает?
ГУРУ вы где?:)

murdemon
10.04.2017, 17:10
Энкодеры на А и В подключены? Есть муфты как пружины гибкие... Они помогут.

Panalexfix
10.04.2017, 17:21
да А и В. Есть муфты, но дело в механике!!!! люфт во время вибрации между шестернями передается на вал энкодера и я так понимаю он в свою очередь считает ипульсы по фронту и в зависимости от того как остановился привод считает вперед или назад. Мой вопрос о том как остановить счет со входа энкодера когда он не используется (то есть привод доехал и встал, а энкодер должен перестать считать)????
Или программу пример как обработать энкодер и тогда во время простоя я ее буду выключать и вибрация не будет учитываться!!!

Владимир Ситников
10.04.2017, 20:48
Я смотрю бурное обсуждение на форуме)))))
тут живые есть????
А не нужно впадать в ступор.

Либо нужно проверить код работы со значением энкодера (если ПЛК не перегружать, то и вибрацию оно должно нормально отрабатывать)
Либо (если уж так не терпится завораживает обработку энкодера) действительно не учитывать энкодер в момент Ы.
Либо (если прямо совсем нужно ставить энкодер на паузу), то брать Hardella и обрабатывать энкодер там.

Но, наверняка достаточно будет привести КДС в порядок, и наверняка никакие паузы энкодера не нужны.

Panalexfix
11.04.2017, 08:10
А не нужно впадать в ступор.

Либо нужно проверить код работы со значением энкодера (если ПЛК не перегружать, то и вибрацию оно должно нормально отрабатывать)

Но, наверняка достаточно будет привести КДС в порядок, и наверняка никакие паузы энкодера не нужны.

К работе ПЛК нет притензий. Через fast encider все хорошо считает без пропусков и с большим запасом по скорости(я энкодер крутил с гораздо большей скоростью и он мне все считал без пропусков). ПЛК не перегружен. В том-то и дело, что привод стоит а импульсы идут то в++ то в-- их не одинаковое кол-во все от времени вибрации зависит и в каком месте остановился энкодер (я так понимаю на каком фронте энкодера). Просто конструкция такая, что между зубьями шестеренок есть люфт и энкодер считает все импульсы при вибрации, при чем в обе стороны.


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

как это сделать??? ведь записать в %IW0.0 ни чего не получается!!!!!


Либо (если прямо совсем нужно ставить энкодер на паузу), то брать Hardella и обрабатывать энкодер там.
я не знаю что это, но погуглю))))

Panalexfix
11.04.2017, 10:32
Это пока то что пришло в голову полазив по всем форумам((((
Чуть позже опробую этот кусок

Sulfur
11.04.2017, 11:05
Panalexfix
У Вас энкодер 10000 об\мин, а нужно всего лишь 960 импульсов. Может стОит присмотреть другую модель, с меньшим разрешением?

Другой вариант.

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

Ну и вариант с Hardella не стОит сбрасывать со счетов.

Panalexfix
11.04.2017, 18:09
Всем спасибо!!!!
Решил проблему координально без изменения программы, к стати или написал криво или на старых ПЛК 110-60 не работает вообще то, что выше выложил. В общем долго всматривался в работу энкодера и механизма. Косяк в том что агрегат находится далеко от компа и выяснил, что излишняя вибрация передается через соединительную муфту вала энкодера и привода, так-как сделана она из обычной резиновой шланги хоть и мягкой, но не на столько чтоб гасить вибрацию стола. Чтоб проверить догадки взял обычную пружину с нужным диаметром и через нее соединил. И тут все заработало. Еще раз спасибо всем!!!! А на счет Hardella обязательно посмотрю интересно уж очень)))))))

acs.ufk
25.03.2019, 06:48
Приветствую!
Впервые столкнулся со связкой плк+энкодер, не совсем ясно как реализовать задачу и какими средствами я обладаю в лице codesys и библиотек.

Задача: Асинхронный двигатель 750 об/мин с энкодером (сейчас экспериментирую с 250имп/об) на валу возит по салазкам устройство, в зависимости от позиции этого самого устройства включаются/выключаются другие вспомогательные устройства. С реализацией всего думаю вопросов не возникнет, проблема в обработке данных с энкодера. Устройство ездит вперед и назад (291 мм в одну сторону). При включении лини перед началом работы необходимо реализовать сброс на ноль по ВБИ. От позиции этого же устройства зависит скорость его перемещения, т.е. задание на ПЧ.

Так вот подключил AB на FDI1, FDI2 - показания вижу, считает в обе стороны, за оборот 1000имп, но думаю не проблема могу поделить на 4. Не пойму как реализовать обнуление по вкл DI? Возможно есть готовые функции для подобных задач?
Да, с ST знаком очень слабо, получится реализовать в CFC?


ps С библиотекой oscat работает, считает в обе стороны, сброс есть, по-прежнему 1000 имп. на оборот, но стоит чуть прибавить скорость считает меньше, если крутить еще быстрее начинает считать в противоположную сторону(пробую на столе).

Sulfur
28.03.2019, 09:04
acs.ufk
Стандартными библиотеками Овен НЕ получится сделать сброс энкодера по желанию. Столкнулся с подобной проблемой, решил с помощью HardellaIDE (разработка Владимира Ситникова).



ps С библиотекой oscat работает, считает в обе стороны, сброс есть, по-прежнему 1000 имп. на оборот, но стоит чуть прибавить скорость считает меньше, если крутить еще быстрее начинает считать в противоположную сторону(пробую на столе).
Пропуски и неадекватность счета происходит потому, что библиотека оскат работает в основном цикле ПЛК на основном просцессоре. Проект Hardella использует сопроцессор быстрых входов вне цикла основного процессора ПЛК, и поэтому не зависит от нагруженности ПЛК, и позволяет считать импульсы до 100кГц без пропусков и ошибок.