rotaries.lua with Leo Bodnars card

[alaxus]

Hi Pete,

I have a few questions regarding the rotaries.lua that was posted a few days ago. I copied it and modified it to the amount of rotaries that I have connected to the card.

The rotaries are set correctly at quarter wave using the encoder utility. There are 16 de-tents per revolution.

Q1. One issue I am having is that it misses steps when using the lua code and writing to Joy #64 button 1,3, ie it isn't catching all the virtual button presses. In some cases it doesn't catch any of the virtual button presses at all. Is this because the polling rate is to slow? Yet when I use the direct assignment Joy #3 button 30 ,31 it catches all the button presses. This issue may be related to Q3 below.

Q2. One thing I have noticed is that when I turn the encoder (left, right), when in the button and switches tab of fsuipc, I get a response on Joy #3 button 30 ,31 and Joy #64 button 1,3. Is this correct?

In this case I assigned the VOR OBS 1 INC , DEC to Joy #64 button 1,3 respectively.

Q3. Am I correct in thinking that the following piece of code increments the Joy #64 button to 2 and 4 if I give the encoder a fast twist?

if (LastTimes[j] ~= nil) and ((Time - LastTimes[j]) < FastTimeLimit) then
	   thisbutton = buttonbit + buttonbit -- Use next higher button for fast
	  end
[/CODE]

Which I would the assign VOR OBS 1 FAST INC , FAST DEC? If this is true, where would I make the assignment as I don't see Joy #64 button 2 and 4 show up in the button and switches tab. Would it have to be added to the fsuipc.ini?

Here is the code:

[CODE]
-- Set device details here (use HidScanner to find these if not known)
Vendor = 0X1DD2
Product = 0X1001
Device = 0 -- Multiple devices of the same name need increasing Device numbers.
-- Use separate Lua plug-ins for separate cards!
-- NOTE: this can handle up to 16 rotaries only, using the first 64 "virtual buttons"
-- List the pairs here:
Rotaries = {31,30,29,28,27,26,25,24,23,22}
-- Example { 31, 30, 25, 22 } would be 31+30 for one, 25+22 for the next, and so on
-- Which is clockwise and which counterclockwise doesn't matter -- you'll get
-- fast and slow of each in any case
dev, rd, wrf, wr, init = com.openhid(Vendor, Product, Device, Report)
if dev == 0 then
ipc.log("Could not open HID")
ipc.exit()
end
-- Set the boundary time in milliseconds between
-- "fast" (shorter) and "slow" (longer) signalling
FastTimeLimit = 90 -- Adjust to taste
-- Polling time in milliseconds: should be much shorter than
-- the boundary time
Pollrate = 10 -- same as 50 times per second
-- Initialise variables used to keep track of things
LastTimes = {}
Buttons = 0
PrevButtons = 0
Diff = 0
-- This function will be called by a time event, set at the end of the program before exit.
function poll(Time)
-- read any data available from the device (only need most recent report)
data, n = com.readlast(dev, rd)
if n ~= 0 then
-- Data was returned, so get the status of all the possible "buttons" we are using
-- one value of 32 bits
Buttons = com.gethidbuttons(dev, data)
-- See if any changes occurred:
Diff = logic.Xor(Buttons, PrevButtons)
PrevButtons = Buttons
if Diff ~= 0 then
offset = 0x3340
buttonbit = 1
j = 1
while Rotaries[j] ~= nil do
mask = logic.Shl(1, Rotaries[j])
if logic.And(Diff,mask) ~= 0 then
-- This one changed
-- See if changed in less than the "boundary" time
thisbutton = buttonbit
if (LastTimes[j] ~= nil) and ((Time - LastTimes[j]) < FastTimeLimit) then
thisbutton = buttonbit + buttonbit -- Use next higher button for fast
end
LastTimes[j] = Time
-- Toggle a virtual button accordingly
ipc.togglebitsUD(offset, thisbutton)
end
j = j+1
buttonbit = 4 * buttonbit
if logic.And(j,15) == 0 then
buttonbit = 1
offset = offset + 4
end
end
end
end
end
event.timer(Pollrate, "poll")
[/CODE]

Thanks for your great work

Jeff

Edit I had a look at the fsuipc log for the button presses, the only ones I could see were Joy #64 button 1,3.

ps Whats the difference between VOR OBS 1 FAST INC and VOR OBS 1 INC FAST?

[Pete Dowson]

The rotaries are set correctly at quarter wave using the encoder utility. There are 16 de-tents per revolution.

I'm not familiar with such technicalities, sorry. I'm just used to something which sets or clears a flag in the input from the Windows joystick interface.

Q1. One issue I am having is that it misses steps when using the lua code and writing to Joy #64 button 1,3, ie it isn't catching all the virtual button presses

What, exactly, is "missing" virtual button presses? What is looking at them? If you mean FSUIPC is actually making virtual button presses faster than it is scanning them, then, if you want to catch them all (why?) you'd have to increase the button scanning rate -- an FSUIPC INI file parameter. But, generally, the rate is good enough for normal value increments and decrements and it then doesn't matter if some are missed. Are you counting the clicks or something?

In some cases it doesn't catch any of the virtual button presses at all. Is this because the polling rate is to slow?

Without knowing what you mean by "it" I can't really answer, sorry. You can experiment with the button polling rate, rate I'm not sure what you are trying to achieve.

Note that the event.timer method of calling the routine depends on Windows timer calls, which are not guaranteed to provide calls at exactly the intervals requested. It depends on the loading on the rest of the system. If the Lua threads were run at a higher priority then it would probably be more predictable, but at the cost of affecting FS performance, something I'm not willing to risk.

Q2. One thing I have noticed is that when I turn the encoder (left, right), when in the button and switches tab of fsuipc, I get a response on Joy #3 button 30 ,31 and Joy #64 button 1,3. Is this correct?

If the device is connecting as Joystick #3 and that rotary is operating buttons 30 and 31, they would surely be seen. Of course. How not?

Q3. Am I correct in thinking that the following piece of code increments the Joy #64 button to 2 and 4 if I give the encoder a fast twist?

if (LastTimes[j] ~= nil) and ((Time - LastTimes[j]) < FastTimeLimit) then
	   thisbutton = buttonbit + buttonbit -- Use next higher button for fast
	  end
[/CODE]

That is the intention, of course. You have to adjust the "FastTimeLimit" to suit, as it states in the comments.

Which I would the assign VOR OBS 1 FAST INC , FAST DEC? If this is true, where would I make the assignment as I don't see Joy #64 button 2 and 4 show up in the button and switches tab.

If they are not showing up you'll need to adjust the time, or turn the knob faster, or reduce the polling time, or al three.

ps Whats the difference between VOR OBS 1 FAST INC and VOR OBS 1 INC FAST?

No idea. Where are you seeing those? FSUIPC adds "vor1 obi inc fast", one of the additional FSUIPC controls listed in the Advanced User's guide. There are several added to make up for omissions in FS's supply of controls.

REgards

Pete

[alaxus]

I'm not familiar with such technicalities, sorry. I'm just used to something which sets or clears a flag in the input from the Windows joystick interface.

Don't worry about that, the firmware on the card takes care of the type of encoders anyway. It was a FYI not a question as such.

I have since spent quite a number of hours experimenting on the following variables.

FastTimeLimit , Pollrate and the PollInterval rate in the FSUIPC.INI

So far the best numbers that I have come up with are:

FastTimeLimit=33

Pollrate=10

PollInterval=10

By playing with the FastTimeLimit I have managed to get consistent responses on Joy #64 button 0,1 and Joy #64 button 2,3

So on Joy #64 button 0,1 I assigned them to VOR OBS 1 INC , DEC respectively. And Joy #64 button 2,3 to VOR OBS 1 FAST INC , FAST DEC. So that worked ok.

My issue is, I can't seem to get the code to switch from Joy #64 button 0,1 to Joy #64 button 2,3 with any consistency. 32ms favours Joy #64 button 0,1 and barely ever switches up to Joy #64 button 2,3 whereas 34ms is so erratic its all over the place even when the encoder is being turned real slow, and 33ms isn't much better.

After reading this in the Guide for Advanced users;

A polling rate of 40 per second is more than adequate for all normal button programming. It is only when you come to the more advanced uses that you may want to change this. Rotary switches, for instance, may give pulses so fast that some are missed at such a rate.

I think my issue is a lot of the pulses coming off the encoder are being missed.

So just a question on this, would it be more efficient if the encoder inputs were sent direct to the required offsets, rather than to virtual buttons? Or is it more efficient to have an external app write straight to the offsets like FS2Phidgets?

No idea. Where are you seeing those? FSUIPC adds "vor1 obi inc fast", one of the additional FSUIPC controls listed in the Advanced User's guide. There are several added to make up for omissions in FS's supply of controls.

They both showed up in the buttons assignment list for fsuipc ver 3.988q

So I am coming to the conclusion that this method maybe little inefficient for what I need.

Anyway

Thanks again for all your help, even if this doesn't work out for me I still managed to learn a fair bit.

Jeff

[Pete Dowson]

My issue is, I can't seem to get the code to switch from Joy #64 button 0,1 to Joy #64 button 2,3 with any consistency. 32ms favours Joy #64 button 0,1 and barely ever switches up to Joy #64 button 2,3 whereas 34ms is so erratic its all over the place even when the encoder is being turned real slow, and 33ms isn't much better.

This is all probably down to the fact that the Lua script is a script interpreted by an interpreter running in a thread which is being restricted in its processor usage so as not to affect FS unduly.. If you really do want consistency I think you would need to write a driver in a programming language and compile it as a separate process. You are probably just expecting too much from a general-purpose plug-in script system.

I think my issue is a lot of the pulses coming off the encoder are being missed.

I don't see why that can possibly matter, provided you can adjust values at a reasonably speed. You are trying to run a script which probably takes several milliseconds in any case to run at 100 times per second, and you are wanting FS to keep up with that too. If your FS frame rate is of the order of 200 fps then this might well be achievable -- provided you limited it to less to give enough time to other threads. If it is only achieving 20-40 then you are probably asking the impossible. I have several encoders being interpreted by Lua plug-ins and have no problem using them to make adjustments at normal rates, but I limit the frame rate on FS so that other threads and processes get enogh time.

In the end, you judge by the readouts you are getting, not by counting the "clicks" from the encoder.

So just a question on this, would it be more efficient if the encoder inputs were sent direct to the required offsets, rather than to virtual buttons?

Yes, of course, but you lose the assignment flexibility. And at 100 increments per second you'd probably over-control because the display would not keep up.

Or is it more efficient to have an external app write straight to the offsets like FS2Phidgets?

A proper driver will always be more efficient than an interpreted plug-in. The plug-in system is merely a way of adding minor facilities to a system which would otherwise necessitate me continuously adding things to fSUIPC. It is designed for flexibility and to avoid FSUIPC getting more complicated all the time..

So I am coming to the conclusion that this method maybe little inefficient for what I need.

Yes, it seems so.

Regards

Pete