Страница 4 из 7 ПерваяПервая ... 23456 ... ПоследняяПоследняя
Показано с 31 по 40 из 67

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

  1. #31

    По умолчанию

    Цитата Сообщение от capzap Посмотреть сообщение
    AlekseyK хотя бы на практике проверяет свои идеи, а Вы пытаетесь свои измышления довести до окружающих ни чем/ни кем не подтвержденные. Работа по прерываниям ни чем не отличается от отдельной задачи, которая бы считала результат энкодера из конфигуратора в свободном цикле например
    Поиграется с энкодером, вернется на прямое управление, Ваши посты ему ни как не помогут, они просто не в тему, да он уже и высказался
    А вы место и время не перепутали ? Тут не армия, где все делается на ать-два.
    Последний раз редактировалось Newcomer; 20.03.2016 в 14:16.

  2. #32

    По умолчанию

    Цитата Сообщение от AlekseyK Посмотреть сообщение
    Прочитал, и пример посмотрел. При активации строки "Назад" переменная C растет. Разве так должно быть?
    Направление вращения автоматически не определяется, тут надо подумать как выбирать расчетную формулу.

    Главная ценность формулы в том, что она защищает от переполнения.
    Вложения Вложения
    • Тип файла: rar Enc.rar (12.8 Кб, Просмотров: 114)

  3. #33

    По умолчанию

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

  4. #34

    По умолчанию

    Цитата Сообщение от Newcomer Посмотреть сообщение
    Направление вращения автоматически не определяется, тут надо подумать как выбирать расчетную формулу.

    Главная ценность формулы в том, что она защищает от переполнения.
    А вот формула от vladimirisitnikov учитывает и направление и защищена от переполнения. Ну и просто логичней.
    Последний раз редактировалось AlekseyK; 20.03.2016 в 14:20.

  5. #35

    По умолчанию

    Цитата Сообщение от AlekseyK Посмотреть сообщение
    А вот формула от vladimirisitnikov учитывает и направление и защищена от переполнения. Ну и просто логичней.
    Приведите эту формулу в окончательном виде, я ее проверю и засундучу.

  6. #36

    По умолчанию

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

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

    Проверил на железе, у меня вопросов нет.

  7. #37
    Пользователь Аватар для capzap
    Регистрация
    25.02.2011
    Адрес
    Киров
    Сообщений
    10,224

    По умолчанию

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

    В третьих, судя по экспериментам AlekseyK, слова Владислава, похоже, подтверждаются: попытка обработать fast inputs из 20мкс таймера пропускает сигналы. По крайней мере, исходная программа выглядит логично, и на ум приходит только то, что реально fastcounters нельзя читать из таймера.
    Хотя, конечно, странно это, особенно, учитывая, что именно так рекомендуют делать в "видео от ОВЕН".
    во первых (#55) - в правом верхнем углу есть тоже ссылка, не обязательно указывать страницу и говорить какой пост прочитать
    во вторых, ни какого подтверждения там нет, есть просьба что то подтвердить или опровергнуть (докопаляся до какой то ерунды)
    в третьих и я обозначил что так с энкодером можно работать в отддельной задача или в главном цикле, не важно
    в четвертых по мне так подход в исходной программе не совсем логичный, за основу берется условие состояния одного из входов и внутри этого условия анализируется состояние второго входа, хоть и правильно всё но в железе мало ли могут быть ошибки из-за дребезгов и т.п. Я бы анализировал что пришел импульс по поднятию обоих входов, а направление учитывал, кто из входов в предыдущей итерации был false
    Bad programmers worry about the code. Good programmers worry about data structures and their relationships

    среди успешных людей я не встречала нытиков
    Барбара Коркоран

  8. #38

    По умолчанию

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

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

    Проверил на железе, у меня вопросов нет.
    У меня то же. Спасибо автору.

  9. #39

    По умолчанию

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

  10. #40
    Пользователь Аватар для capzap
    Регистрация
    25.02.2011
    Адрес
    Киров
    Сообщений
    10,224

    По умолчанию

    Цитата Сообщение от AlekseyK Посмотреть сообщение
    а как вы отличите полезный сигнал от дребезга? Если на первом высокий уровень, на втором тоже высокий но от дребезга, то по условию, что на втором в предыдущей итерации был 0 надо засчитывать движение в одну из сторон. Алгоритм получается абсолютно такой же, только момент засчитывание такта сместиться на четверть периода вперед.
    с дребезгом может и погорячился, хотя есть фильтрация, но от неё может быть больше вред чем польза
    только Вы от сигнала берете передний фронт, в это единичный момент времени на входах может произойти всё что угодно, просело напряжения и вместо логической единицы получили логический ноль, вот и произошло неверное трактование сигнала и как следствие неверный подсчет импульсов, не трудно же написать что то подобное
    Код:
    IF in.0 AND in.1<>oldIn1 THEN
    ELSIF in.1 AND in.0<>oldIn0 THEN
    
    или (но с дополнительным отдельным учетом обработки направления)
    
    foo:=in.0 AND in.1;
    IF foo<>oldFoo THEN
    Последний раз редактировалось capzap; 20.03.2016 в 16:51.
    Bad programmers worry about the code. Good programmers worry about data structures and their relationships

    среди успешных людей я не встречала нытиков
    Барбара Коркоран

Страница 4 из 7 ПерваяПервая ... 23456 ... ПоследняяПоследняя

Похожие темы

  1. Расчет в отчете.
    от VVS_123 в разделе Master SCADA 3
    Ответов: 5
    Последнее сообщение: 12.10.2015, 16:24
  2. Расчет радиатора и нагревателя
    от rovki в разделе Трёп (Курилка)
    Ответов: 48
    Последнее сообщение: 11.11.2014, 10:10
  3. Расчет охладителя для ТТР Кипприбор
    от Iroha Uta в разделе Твердотельное реле
    Ответов: 12
    Последнее сообщение: 24.01.2014, 19:58
  4. ФБ расчет и long
    от LordN в разделе Master SCADA 3
    Ответов: 1
    Последнее сообщение: 07.03.2012, 08:07
  5. Master SCADA расчет
    от kanava в разделе Master SCADA 3
    Ответов: 1
    Последнее сообщение: 27.08.2008, 12:12

Ваши права

  • Вы не можете создавать новые темы
  • Вы не можете отвечать в темах
  • Вы не можете прикреплять вложения
  • Вы не можете редактировать свои сообщения
  •