Rotary support request
 

Sorry if this is in english, but i feel better when i have to explain thing if i know what i am writing.
So here it goes:
i'd like to see support for some kind of encoders in FSBUS.
I think that it can be just a software thing, using the current FSKEY card.
You just have to set 2 inputs as an encoder, and then the software would do the rest, decoding the direction.
This would also allow to use any type of encoder (gray, quadrature, whatever) since it may be defined by software.
I think this would be a solution that prevents us from looking for this functionality in other systems...
USing two different hardware systems may be complex...
Thanks

You could have told me it was already there...
Nevermind :rolleyes:

Hi Claudio,

i will make the answer short. The fsbus key controller scans up to ~100 keys in a matrix. This is done by time multiplexing.

The direction of a quadrature encoding rotarie can only be detected in the very short moment, when the edge of one switch changes. This cannot be done in any polling mode. Only interrupt driven code may work, but this allows using only 1,2 or max. 3 rotaries per controller.

never say never, but I don't give this a chance.

kind regards Dirk

Yes i know

Dirk....
?
The conditional you used says this thing is not there...
While it is there!?!
Look here
This is a small movie made with my coolpix camera today evening.
It is FSBUS running with an ALPS ec11e type encoder.
Why do you say that?

Meant today morning

Sorry, the download is ok, but my videoplayer doesn't show it. What format is it. What is your player ?

Dirk

free apple quicktime

Hi Dirk!

Basically it seems like the "Knitter" encoding happens to work for some weird reason for me, and for Claudio, the "ALPS" mode seems to do it.

What seems to happen is that the encoder sends +-++-++-++... which, when you sum them up, makes "+++" - just a lot of back-and-forth moving.

The Knitter mode with a phase-shifted rotary seems to work a lot better here - good enough that I plan on using them (no jerking at all), I am very surprised. Maybe it is some strange timing that just happens to go right here, but I wired a panasonic "phase shifted" rotary and configured it as "knitter" and hooked it to the QNH knob - and it works very well.

I am kind of surprised that it accidentally works..

Maybe the thing could be made to work by just filtering out the certain "++-++-++-" -pattern? Havent got a scope so I dont know exactly what happens, but it is pretty funny that it works.

I understand the issues for decoding them, so I trust what you say, I dont know much about this stuff anyway - and there's the "REDEC" circuit anyway which is told to work.

//Tuomas

Yes, what Toumas sais is true.
I discovered it accidentally by looking at a rotary object in fsbus.
When i saw "alps" i thought it was for phase-shifted encoders.
And tried and it worked.
Not very good, but worked.
What Toumas says about ++-++-++- is half true, because when you look at FSBUS you effectively see the minus reported but it kind of doesn't get sent to ms. I do not have a back and forth on this, although it is reported by the visual indicator in the fsbus rotary object.
Now if you set the type to knitter, it goes even better: only plus and minus.
Just straight one.
Perfect.
I know the problem about the matrix scanninc versus interrupt, but this thing already works... that's the point.
I am not loosing any number.
IF i have a "refresh rate" for the value, too small (as to say fast), the value jumps a little because fsbus reads when it is still updateing.
So setting the scan delay to big numbers (like 8 seconds) gets rid of this problem, and everything is perfectly smooth.
If you have an encoder give it a try.
And please do not touch anything in te future!
I do not want this "accidental" feature to be removed ;)

The forum doesn't let me edit my messages, so sorry Tuomas i wrote your name wrong every time in the message above :P