Вид для печати
Уважаемые профессионалы!
Не поможите разрешить такой вопрос: я подключаю к ПЛК-100 линейный энкодер согласно описанию на ПЛК, и все вроде бы работает, только в инструкции энкодера сказано, что один оборот колеса равен 200 импульсов, а контроллер у меня насчитиывает аш 800. С чем это связано?
С чем связано - не знаю. Абсолютно то же самое. Просто пользуйтесь, как есть. Скорее всего, если помучать разработчиков вопросами, выяснится, что подсчет импульсов в целях повышения точности идет как по фронту так и по спаду (х2). А изменение регистра происходит как от импульса фазы А, так и от импульса фазы Б (еще раз х2). Итого х4.
Это может быть от того, что кто то подумал: "а если детское питание заваривать не на воде, как в инструкции, а на молоке - будет вкуснее". А в итоге - у ребеночка - понос.
Сам налетал на эти грабли, когда энкодер на 2500... Выбирался для работы на длинном рельсовом пути. И все в итоге переполнялось. Пришлось уродоваться - ловить отдельно Z, и организовывать самому еще один регистр со "старшими разрядами", прибавляя или вычитая единичку в зависимости от направления движения телеги. Сам энкодер, разумеется, описывался в ПЛК как RING.
Можно, конечно, предложить сделать "когда нибудь" по аналогии с одним из счетчиков - так в настройках есть опции "По фронту", "По спаду" и "Оба". Но во первых не факт, что это будет сделано. Во вторых - если будет сделано, то откуда нам знать, с какими сюрпризами?
Так что, как кажется, пусть остается как есть. Просто за собственные деньги и потерянное на дописывание процедуры обслуживания "переполнения" буду в следующий раз выбирать энкодер вчетверо меньшей разрешающей способности, чем цена деления "линейки". Для тех прошивок ПЛК, которые есть сейчас.
Досадная неточность в документации. Исправим.Цитата:
Сообщение от D_O_K
Действительно, модуль энкодера работает по 2 фронтам и 2 фазам. Но что в этом плохого?
Диапазон настроек числа импульсов для энкодера до 65000, поставьте вместо 200 - 800 импульсов.
Это было сделано для повышения точности, к-я очень бывает нужна в нек-х случаях.
А если хочется снизить точность, то просто делите значение на 4.
Плохого - ничего. Предупреждать надо. На работе из-за этого был грандиозный скандал.Цитата:
Сообщение от Филоненко Владислав
На высокоточном энкодере 2500 отсчетов на диске. Рельс длинный. Выбирали как раз так, чтобы 16-разрядный регистр не переполнялся. Банально не хватило 65000 импульсов на рельсовый путь.
Ладно, подтвердили, и ладно. В конце концов - "Овен", не рекордсмен по потерянному времени. Прощаем )))
Собственно, вот текст той "кривой козы", на которой объезжали недостаточную разрядность регистра кодесисовского "encoder":
Во первых, в настройках модуля "энкодер" указывается RING - энкодер будет кольцевым, и количество импульсов, равное тому, который считает ПЛК на цикл. Т.е. 200-импульсному энкодеру соответствует 800 в настройках.
Далее, определяем программно направление вращения вала энкодера:
STATE1.0 := ENCODER_A; - вход с фазой А
STATE1.1 := ENCODER_B; - вход с фазой В
IF STATE0 = 1 AND STATE1 = 3 THEN
DIRECT_MOVE :=TRUE;
END_IF;
IF STATE0 = 3 AND STATE1 = 2 THEN
DIRECT_MOVE :=TRUE;
END_IF;
IF STATE0 = 2 AND STATE1 = 0 THEN
DIRECT_MOVE :=TRUE;
END_IF;
IF STATE0 = 0 AND STATE1 = 1 THEN
DIRECT_MOVE :=TRUE;
END_IF;
IF STATE0 = 0 AND STATE1 = 2 THEN
DIRECT_MOVE :=FALSE;
END_IF;
IF STATE0 = 2 AND STATE1 = 3 THEN
DIRECT_MOVE :=FALSE;
END_IF;
IF STATE0 = 3 AND STATE1 = 1 THEN
DIRECT_MOVE :=FALSE;
END_IF;
IF STATE0 = 1 AND STATE1 = 0 THEN
DIRECT_MOVE :=FALSE;
END_IF;
STATE0 := STATE1;
Синтезировать последовательностные схемы на языках МЭК можно, но было лень. Поэтому и была сделана поочередная проверка на направление вращения. Два бита фаз энкодера образовывали число, которое менялось либо так:
1->3->2->0->1...
либо так:
0->2->3->1->0...
В зависимости от направления вращения.
Делаем из уровня фронт:
Z_TRIG(CLK := ENCODER_Z ); - третий вывод энкодера, Z
При наезде на концевик телегой происходило следующее:
IF SW1_END_RAIL THEN
HI_BITS_ENCODER :=0; - это переменная, в которой запоминается, сколько оборотов (через через метку Z) сделал вал телеги
END_IF;
После чего телега ехала в сторону увеличения координат до тех пор, пока не случался первый Z. Он и становился меткой начала пути.
IF ENCODER_Z THEN
ENCODER_PT := ADR(ENCODER); - а это - волшебная штука, которая
ENCODER_PT^:= 0; работает только на самой последней прошивке ПЛК Овен - обнуление регистра "энкодера" через указатель.
Иначе говоря, проходя каждый оборот, синхронизируется метка Z и счетчик импульсов энкодера.
END_IF;
А при возникновении фронта импульса Z в дополнительно созданном регистре, где хранятся "старшие биты" - а точнее - количество полных оборотов вала телеги учитываем их в зависимости от заранее определенного направления движения.
IF Z_TRIG.Q AND DIRECT_MOVE THEN
HI_BITS_ENCODER := HI_BITS_ENCODER + 1;
END_IF;
IF Z_TRIG.Q AND (NOT DIRECT_MOVE) THEN
HI_BITS_ENCODER := HI_BITS_ENCODER - 1;
END_IF;
Таким способом, можно учитывать пробег энкодером существенных расстояний. При этом в переменной, не совсем удачно названной HI_BITS_ENCODER, можно хранить огромное количество полных оборотов вал, а точный "хвост" внутри каждого оборота считывать собствеенно из регистра модуля "энкодер".
С какой частотой следуют импульсы с ЭНкодера? Если это >1 кГц, то такая программа будет давать ошибку, т.к. к моменту обработки сигнала Z в цикле ПЛК энкодер уже насчитает неск. импульсов и обнуление будет не корректным.
Если же частота <500 Гц - то модуль энкодера в принципе не нужен - его можно реализовать программно с любой разрядностью
Владислав, а не все так страшно!Цитата:
Сообщение от Филоненко Владислав
ЦИКЛИЧЕСКИЙ режим энкодера реализуется как? Аппаратно. Т.е. "хвост" - позиция "внутри" одного оборота, если ее НЕ сбрасывать каждый цикл - существует вне цикла пересчета программы контроллера.
Это не программа, а нарезка фрагментов, поясняющая идею. Обнуление аппаратного регистра (или как он у вас организован) происходит единожды при поиске ближайшего к концевику рельсового пути Z. При этом происходит синхронизация начала отсчета циклического изменения энкодера с сигналом Z.
В дальнейшем энкодер типа RING живет своей жизнью - "крутится" в обе стороны, переполняется, переходит через "0" и.т.д.
Подсчет же количества оборотов вала энкодера по метке Z - происходит отдельно. И лишь тогда, когда возникает необходимость вновь синхронизировать начало "кольцевого" реверсивного счетчика с Z - при выполнении установки ноля - на малой скорости подачи, производится обнуление регистра энкодера.
В результате имеем два, независимых процесса - "аппаратный" кольцевой энкодер и "программный" реверсивный счетчик полных оборотов.
Если же производить обнуление энкодера при каждом высоком уровне Z - ноль действительно "уплывет".
Почему я так прицепился к этому примеру?
Потому что это-прекрасная иллюстрация разницы между мышлением разработчика АСУ ТП и разработчиков ЧПУ станка.
Дело в том, что процессы, наблюдаемые в АСУ ТП носят хаотический характер. И очень сильно приучают думать категориями неопределенности, как при построении различных ПИД-регуляторов.
А в станках ЧПУ мы сами вольны создавать условия, при которых будет осуществляться та или иная операция. Например подойти к концевику с той скоростью, чтобы не пролететь концевик, затем медленно поехать ловить начало координат, и далее действовать как угодно. Например, организовать плавное снижение скорости на основании ожидаемого числа полных оборотов, переходя на низкую скорость... Т.е. главным становится не скорость считывания данных, а их "сохранность". А условия для считывания мы создаем сами, снижая скорость подачи так, как нам удобно.
Это принципиально различные подходы. И уже не первый раз наблюдаю, как у специалистов по АСУ ТП наблюдается некий ступор перед подходами ЧПУ-шников. Именно потому, что события в АСУ ТП чаще всего менее управляемые по сравнению с событиями, происходящими в механизмах станков.
У ЛИРов (к примеру) за один самый младший разряд считаются 4 импульса, посмотрите на формулу, которую они приводят в документации, там есть (помимо прочих) коэффициент 4...Цитата:
Сообщение от clockwise