А не связано это с тем, что приоритет операции логического отрицания выше, чем побитовое «и»? Мб скобки переставить:

if (EncPortData[1]&0x01 && !(EncPortData[0]&0x01))//нарастающий фронт по А!
if (EncPortData[1]>>1)&0x01 && !(EncPortData[0]>>1)&0x01)//нарастающий фронт по B!

В первой строчке вообще не понятно зачем скобки вокруг элемента массива…

реле, катушка которого рассчитана на переменное напряжение 220В, не?

Код указанный выше. И в нем есть очень неявная ошибка.
Задача кода — устанавливать выход в единицу по фронту сигнала А, а сбрасывать — по фронту сигнала Б.
Два «независимых» условия, каждое смотрит текущее и предыдущее состояния и в стучае фронта — делает свое дело.
Вот только если сначала появляется фронт А, а потом Б — все работает как надо (что идеально работает как раз с упомянутой кнопкой).
Но вот если крутить наоборот, т.е. сначала Б, потом А, то операция (EncPortData[1]>>1) портит данные. Именно этим меня утром и осенило :) Попытался найти подобный случай в Макконнелле(Совершенный код), но нашел только приведенную выше цитату на первой же странице результатов поиска :)

Что это за реле такое, на катушку которого подается 220В переменки?

Вчера я его не смог приладить к энкодеру, догадайтесь почему.

Телепаты, ау?

Вопрос знатокам — почему код правильно отрабатывает свое предназначение при вращении энкодера в одну сторону и взрывает мозг в другую?

Какой код? Что за предназначение?

«Я не тупой» © Гомер Симпсон.

Ложась спать, меня вдруг покоробило «Но я же видел Правильные осциллограммы!»
Утром я буквально вскочил за пол часа до будильника с пониманием того, где закралась проблема. Разумеется, состояние энкодера выводится на семисегментник.

Считывается состояние так:

EncPortData[1]=(ENCODERINPORT>>5)&0x03;//прочли сырое значение

Выводится это состояние так:

PORTC&=~0x30; PORTC|=(EncPortData[1]<<4);

А между ними код, подавляющий дребезг контактов. К слову сказать работающий без сбоев для какой-то там кнопки, где-то на реальной железке. Вчера я его не смог приладить к энкодеру, догадайтесь почему. Код фиксирует фронты по друм линиям. По фронту одной линии сетит, другой — ресетит.

if ((EncPortData[1])&0x01 && !(EncPortData[0])&0x01)//нарастающий фронт по А!
if ((EncPortData[1]>>1) & 0x01 && !(EncPortData[0]>>1) & 0x01)//нарастающий фронт по B!

Вопрос знатокам — почему код правильно отрабатывает свое предназначение при вращении энкодера в одну сторону и взрывает мозг в другую?

В одну сторону крутишь, выдает последовательность 0/3
в другую сторону крутишь, выдает последовательность 1/2
Тут, правда, с определением направления вращения еще проще — XOR(a,b) и делов.
Взял с полки непаянный — та же хрень.

А что тогда?

Забавно. У распаянного на плате энкодера сигнал на выходе — НЕ код Грея.

Ну если визуально, то можно еще неонку с резистором.

Механика на высоких скоростях крайне ненадежна.
Посему либо Холл, либо оптика.

А защита от дребезга… Расскажу через пару часов про нее.

Надо тоже попробовать Hg, спасибо за статью. На работе же у меня во всю юзается Perforce и SVN

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

В качестве визуального оповещателя можно использовать такую схему

Если запустить генератор ночью, то и ночью пищать будет — не вижу в этом проблемы.

Если вы испольуете проводник (эм), total commander или что-то в таком духе, то нужно щелкнуть правой кнопкой мышки и выбрать:

Небольшое уточнение: в тотале точно так же можно сделать копипаст в командную строку.

А по ночам тоже пищит?
Напомнило: www.liveinternet.ru/users/d_s/post197291584/

Блин, не подумал, что там Холл. У тех механических энкодеров, которыми мне доводилось пользоваться на фронтах дребезг был ядреный.

Генератор автоматически включаться/выключаться не умеет потому, что нет автоматического ввода резерва и микроконтроллер тут не поможет. А покупать контакторы и лепить еще один щиток я морально не готов.

И у меня второй ответ вытекает из первого :) Звонок зазвонил — а выключать или нет генератор решает уже человек. Такой себе биологический таймер.