LUA script causes CTD under 4.833

[Delta14Sierra]

Pete,

I have been successfully using the below LUA script (DME.lua) in FSX to make a GoFlight GF-166 function as a DME. The ipcPARAMs 1 & 2 are assigned to the GF-166 encoder via FSUIPC.

Whether rotating the encoder slowly or quickly, this script has been working without any issue when using FSUIPC up to and including version 4.827.

However, with more recent versions of FSUIPC, including 4.833, this script causes a CTD. If I slowly rotate the encoder either way one click at a time, the DME script works just fine. But if I quickly over-rotate the encoder creating multiple clicks, that is when I get the CTD.

I have included the offending LUA script below along with the respective FSUIPC.log. If there are other files I need to forward, please let me know.

Dan

-- Launched from ipcReady.lua
-- Initialize
GFunit = 1
switch = ipc.readLvar("L:DME_Switch") -- Reads DME Selector State
gfd.SetBright(GF166,GFunit,15)
if ipcPARAM == 1 then
if switch > 0 then -- limits encoder switch from going below 0
  switch = switch - 1
ipc.writeLvar("L:DME_Switch", switch) -- DME Selector Rotate Left
ipcPARAM=0 -- Clears ipcPARAM
else
end
  ipc.sleep(10)
    end
if ipcPARAM == 2 then
if switch < 3 then -- limits encoder switch from going above 3
  switch = switch + 1
ipc.writeLvar("L:DME_Switch", switch) -- DME Selector Rotate Right
ipcPARAM=0 -- Clears ipcPARAM
else
end
  ipc.sleep(10)
end
if switch == 0 then
function Distance(offset, value)
end
function Speed(offset, value)
end
function Time(offset, value)
end
gfd.SetDisplay(GF166, GFunit, 0, "")
gfd.SetDisplay(GF166, GFunit, 1, "")
end
if switch == 1 then
gfd.SetBright(GF166,GFunit,15)
ipc.writeUW("0378", 1) -- Set to DME1
function Distance(offset, value)
  miles = ipc.readSTR("0C29", 4) -- Reads DME1 NM
  miles = "1  " .. miles -- Formats DME1 Distance Display
end
function Speed(offset, value)
  kts = ipc.readSTR("0C2E", 3) -- Reads DME1 Speed
end
function Time(offset, value)
  min = ipc.readUW("0304", 2) -- Reads DME1 MIN
   min = min / 10 -- convert data to seconds
   min = min / 60 -- convert seconds to minutes
  if min == 16.665 then
  min = 0
  else
   min = math.floor(min) -- rounds decimal down
  end
  gfd.SetDisplay(GF166, GFunit, 0, miles) -- Display DME1/NM L Window
  gfd.SetDisplay(GF166, GFunit, 1, kts .. (string.format(" %02.f", min))) -- Display DME1 KTS/MIN in R Window
end
end
if switch == 2 then
function Distance(offset, value)
end
function Speed(offset, value)
end
function Time(offset, value)
end
gfd.SetDisplay(GF166, GFunit, 0, "H  ---")
gfd.SetDisplay(GF166, GFunit, 1, "--- --")
end
if switch == 3 then
ipc.writeUW("0378", 2) -- Set to DME2
function Distance(offset, value)
  miles = ipc.readSTR("0C33", 4) -- Reads DME2 NM
  miles = "2  " .. miles -- Formats DME2 Display
end
function Speed(offset, value)
  kts = ipc.readSTR("0C38", 3) -- Reads DME2 Speed
end
function Time(offset, value)
  min = ipc.readUW("030A", 2) -- Reads DME2 MIN
   min = min / 10 -- convert data to seconds
   min = min / 60 -- convert seconds to minutes
  if min == 16.665 then
  min = 0
  else
   min = math.floor(min) -- rounds decimal down
  end
  gfd.SetDisplay(GF166, GFunit, 0, miles) -- Display DME2/NM L Window
  gfd.SetDisplay(GF166, GFunit, 1, kts .. (string.format(" %02.f", min))) -- Display DME2 KTS/MIN in R Window
end
end
event.offset("0C29", "STR", 4, "Distance")
event.offset("0C2E", "STR", 3, "Speed")
event.offset("0304", "STR", 2, "Time")
event.offset("0C33", "STR", 4, "Distance")
event.offset("0C38", "STR", 3, "Speed")
event.offset("030A", "STR", 2, "Time")
[/CODE]

[CODE]
********* FSUIPC4, Version 4.833 by Pete Dowson *********
User Name=""
User Addr=""
FSUIPC4 Key is provided
WIDEFS7 not user registered, or expired
Running inside FSX on Windows 7
Module base=61000000
468 System time = 05/06/2012 20:10:13
468 FLT path = "C:\Users\D14S\Documents\Flight Simulator X Files\"
500 Trying to connect to SimConnect Acc/SP2 Oct07 ...
531 FS path = "D:\Microsoft Flight Simulator X\"
2793 Run: "D:\Microsoft Flight Simulator X\Modules\linda.exe"
2902 Run: "D:\Microsoft Flight Simulator X\Modules\NAVCOM_v8a.exe"
2996 LogOptions=00000000 00000001
3011 Wind smoothing fix is fully installed
3011 G3D.DLL fix attempt installed ok
3011 SimConnect_Open succeeded: waiting to check version okay
3011 Trying to use SimConnect Acc/SP2 Oct07
10920 Running in "Microsoft Flight Simulator X", Version: 10.0.61637.0 (SimConnect: 10.0.61259.0)
10920 Initialising SimConnect data requests now
10920 FSUIPC Menu entry added
11061 C:\Users\D14S\Documents\Flight Simulator X Files\000-Sedona.FLT
11061 D:\Microsoft Flight Simulator X\SimObjects\Airplanes\RealAir Duke Turbine\RealAir_Duke_Turbine.AIR
89202 System time = 05/06/2012 20:11:42, Simulator time = 20:10:20 (03:10Z)
90715 Aircraft="RealAir Beech Duke Turbine Winglets Era"
225406 Starting everything now ...
225453 Using "D:\Microsoft Flight Simulator X\Modules\GFDEV.DLL", version 2.1.0.1
225453 GoFlight GFLGT detected: 1 device
225453 GoFlight GF166 detected: 5 devices
225453 GoFlight GFMCP detected: 1 device
225453 GoFlight GFRP48 detected: 3 devices
225453 LUA.0: beginning "D:\Microsoft Flight Simulator X\Modules\ipcReady.lua"
225453 LUA.0: ended "D:\Microsoft Flight Simulator X\Modules\ipcReady.lua"
225703 LUA.16:

225703 LUA.16: [INIT]LINDA:: Loading...
225796 LUA.16: LINDA:: Aircraft: RealAir Beech Duke Turbine Winglets
225812 LUA.16: LINDA:: Aircraft module detected: RealAir Duke Turbine
225890 LUA.1: LINDA:: AivlaSoft library loaded...
225890 LUA.1: LINDA:: FSX standard library loaded...
225905 LUA.1: LINDA:: IAO library loaded...
225905 LUA.1: LINDA:: RealityXP library loaded...
225905 LUA.1: LINDA:: A2A MAP library loaded...
225983 LUA.1: LINDA:: Loading RealAir Duke Turbine joysticks config...
225983 LUA.1: LINDA:: Module: RealAir Duke Turbine Started...
226139 LUA.1: LINDA:: Ready to go, Captain!
226139 LUA.1: LINDA::
226233 LUA.1: LINDA:: [S] LVars watching list cleared...
226295 LUA.1: LINDA:: [S] Offsets watching list cleared!
228058 Advanced Weather Interface Enabled
231756 PFC Menu entry added
256747 LogOptions changed, now 80000000 00000001
[/CODE]

[Pete Dowson]

Whether rotating the encoder slowly or quickly, this script has been working without any issue when using FSUIPC up to and including version 4.827.

However, with more recent versions of FSUIPC, including 4.833, this script causes a CTD. If I slowly rotate the encoder either way one click at a time, the DME script works just fine. But if I quickly over-rotate the encoder creating multiple clicks, that is when I get the CTD.

Hmmm. That's very srange, because there were several ways such actions could crash in the earlier version which were fixed! I've not met so far any Lua programming which could make a CTD.

If the access to the GoFlight 166 is commented out, so it doesn't need it, does it still crash? Because I'm going to need to be able to reprodce the problem. Maybe another GF device substituted will be needed? The other problem is the aircraft -- I do not have that aircraft, so will I be able to make it crash without it and without the L:Vars it is using?

Also, I see that you are using LINDA. Can you use this Lua program without LINDA? If so, does it still CTD?

Can you also please try GFDev 2.0.10.1 (the latest I have seen -- see the Download Links subforum here). When did 2.1.0.1 come out? Have you updated to that recently?

Finally, the main information I need on any CTD is the offending module name, the offset/address, and the error code. These things should be available in the Windows error log.

[LATER]

Fixed the bug -- please use 4.834 or 3.999n now available.

But please still note my comments in the other messages below. I think you'd be happier with a better performing plug-in. ;-)

Regards

Pete

[Pete Dowson]

There are some strange things in this Lua script which make no sense to me. Did you write it? Could you explain things for me, please?

1. It says at the top that it is run by ipcReady. The fact that it contains events (monitoring all sorts of things) means it is then resident -- i.e. always running, waiting for changes in the offsets it is monitoring. Yet you say "The ipcPARAMs 1 & 2 are assigned to the GF-166 encoder". Are those encoder actions to re-run this continuously running Lua, or merely to provide the Parameter (ipcPARAM) value via the "LuaValue" assignment?

It is rather odd, not to say downright dangerous, to have an event-based plug-in restarting at frequent intervals. If this is what you are doing then I'm amazed you never saw any problems with older versions of FSUIPC. It is very difficult to make the processing of these 100% foolproof against rogue programs. I do try, but there comes a point where the reduction in efficiency outwiighs the avoidance of wrong programming techniques.

It looks to be as if you really need two Lua programs, one to monitor offsets and maintain the displays, and the other to respond to your encoder. If you must put it into one you should use the LuaValue call for the encoder responses and the event.param function to process them. That way it is entirely event based and very safe. and probably 1000 times more efficient because it wouldn't need continuous reloading and recompilation.

2. What is meant by this section?

if switch == 2 then
   function Distance(offset, value)
   end
   function Speed(offset, value)
   end
   function Time(offset, value)
   end
   gfd.SetDisplay(GF166, GFunit, 0, "H  ---")
   gfd.SetDisplay(GF166, GFunit, 1, "--- --")
end
[/CODE]

The function lines are declaring functions which are actually re-declared later, twice more. These declarations are devoid of code so effectively do nothing. I'm surprised that the Lua compiler allows this without complaint. Are you actually intentionally changing the functions being used by the Events instead of simply processing the parameters in the functions? Maybe this is a legitimate Lua programming technique? I know it would be nonsense in any other language -- a function definition remains for the duration, but here you seem to want to declared them based on variable values. It is very strange to me.

3. You have the sequence "else" then "end" in at least two places. Why? Just to slow loading down? Because that's the same as just "end". Why an "else" with nothing else to do?

I would like to nail the CTD in any case, but quite honestly it might not be worth the extra inefficency in the interpreter.

Regards

Pete

[Pete Dowson]

In an attempt to understand this script i've tidied up the layout a little:

-- Launched from ipcReady.lua
-- Initialize
GFunit = 1
switch = ipc.readLvar("L:DME_Switch") -- Reads DME Selector State
gfd.SetBright(GF166,GFunit,15)

if ipcPARAM == 1 then
   if switch > 0 then -- limits encoder switch from going below 0
	  switch = switch - 1
	  ipc.writeLvar("L:DME_Switch", switch) -- DME Selector Rotate Left
	  ipcPARAM=0 -- Clears ipcPARAM
   end
   ipc.sleep(10)
end

if ipcPARAM == 2 then
   if switch < 3 then -- limits encoder switch from going above 3
	  switch = switch + 1
	  ipc.writeLvar("L:DME_Switch", switch) -- DME Selector Rotate Right
	  ipcPARAM=0 -- Clears ipcPARAM
   end
   ipc.sleep(10)
end

if switch == 0 then
   function Distance(offset, value)
   end
   function Speed(offset, value)
   end
   function Time(offset, value)
   end
   gfd.SetDisplay(GF166, GFunit, 0, "")
   gfd.SetDisplay(GF166, GFunit, 1, "")
end

if switch == 1 then
   gfd.SetBright(GF166,GFunit,15)
   ipc.writeUW("0378", 1) -- Set to DME1

   function Distance(offset, value)
	 miles = ipc.readSTR("0C29", 4) -- Reads DME1 NM
	 miles = "1  " .. miles -- Formats DME1 Distance Display
   end

   function Speed(offset, value)
	 kts = ipc.readSTR("0C2E", 3) -- Reads DME1 Speed
   end

   function Time(offset, value)
	 min = ipc.readUW("0304", 2) -- Reads DME1 MIN
	 min = min / 10 -- convert data to seconds
	 min = min / 60 -- convert seconds to minutes
	 if min == 16.665 then
		min = 0
	 else
		min = math.floor(min) -- rounds decimal down
	 end
	 gfd.SetDisplay(GF166, GFunit, 0, miles) -- Display DME1/NM L Window
	 gfd.SetDisplay(GF166, GFunit, 1, kts .. (string.format(" %02.f", min))) -- Display DME1 KTS/MIN in R Window
   end
end

if switch == 2 then
   function Distance(offset, value)
   end
   function Speed(offset, value)
   end
   function Time(offset, value)
   end
   gfd.SetDisplay(GF166, GFunit, 0, "H  ---")
   gfd.SetDisplay(GF166, GFunit, 1, "--- --")
end

if switch == 3 then
   ipc.writeUW("0378", 2) -- Set to DME2
   function Distance(offset, value)
	 miles = ipc.readSTR("0C33", 4) -- Reads DME2 NM
	 miles = "2  " .. miles -- Formats DME2 Display
   end
   function Speed(offset, value)
	 kts = ipc.readSTR("0C38", 3) -- Reads DME2 Speed
   end
   function Time(offset, value)
	 min = ipc.readUW("030A", 2) -- Reads DME2 MIN
	 min = min / 10 -- convert data to seconds
	 min = min / 60 -- convert seconds to minutes
	 if min == 16.665 then
		min = 0
	 else
		min = math.floor(min) -- rounds decimal down
	 end
	 gfd.SetDisplay(GF166, GFunit, 0, miles) -- Display DME2/NM L Window
	 gfd.SetDisplay(GF166, GFunit, 1, kts .. (string.format(" %02.f", min))) -- Display DME2 KTS/MIN in R Window
   end
end

event.offset("0C29", "STR", 4, "Distance")
event.offset("0C2E", "STR", 3, "Speed")
event.offset("0304", "STR", 2, "Time")
event.offset("0C33", "STR", 4, "Distance")
event.offset("0C38", "STR", 3, "Speed")
event.offset("030A", "STR", 2, "Time")
[/CODE]

First, as i said earlier, I'm actually rather amazed that Lua can make sense of this. In my 49 years of programming I've never actually seen conditional redefinition of functions like this. It may be a really well-known and powerful feature of Lua, but it is new to me. If I wanted those functions to do different things according to a switch setting I would test the switch setting inside the functions, not make the switch setting redfine the functions completely.

Second, since the encoder you are using looks like it is merely selecting a DME display mode, why on Earth does it need to be rotated quickly enough to generate a CTD?

Third, apart from the odd function methods, and the fact that it is a resident program which is continually recompiled and reloaded, there are definite mistakes. For instance offsets 0304 and 030A are 16 bit integers NOT 2-byte strings. Your events for these are wrong. I notice you realise they are numbers in the Time functions.

Fourth, the events supply the changing values as parameter "value", yet you are reading them again in the functions. That is really very inefficient. Why read them twice?

Fifth, the DME switch setting is only read when you operate the encoder or whatever is sending the ipcPARAM changes. Shouldn't that be read regularly?

----------------------

Would you like me to attempt to revise the program for you?

Regards

Pete

[Pete Dowson]

Found and fixed the bug causing the crash anyway ... 4.834 or 3.999n now in the Download Links sub-forum.

If you'd still like me to revise the plug-in for better operation, though, please say so.

Regards

Pete

[Delta14Sierra]

Pete,

If you have the time to revise the plug-in, I would certainly appreciate it and am confident that I would learn a lot by your doing so!

Just to confirm, I have downloaded/installed FSUIPC 4.834 and the CTD issue is gone.

To answer some of your questions that may still be relevant...

Can you use this Lua program without LINDA?

I use LINDA to interface with physical switches I have wired to two Leo Bodnar BU0836X boards.

When did GFDev 2.1.0.1 come out?

I am not sure where/when I got it. I have since downloaded and installed 2.0.10.1.

since the encoder you are using looks like it is merely selecting a DME display mode, why on Earth does it need to be rotated quickly enough to generate a CTD?

I first stumbled upon the CTD when using the encoder to turn the DME off. In that instance, rather than rotate the encoder one click at a time to simply turn the display off, I had rotated the encoder quickly resulting in multiple clicks and the subsequent CTD. So there really is no "need" to rotate the encoder quickly. That was simply the circumstance that happened to cause the CTD.

2. What is meant by this section?

if switch == 2 then

function Distance(offset, value)

end

function Speed(offset, value)

end

function Time(offset, value)

end

gfd.SetDisplay(GF166, GFunit, 0, "H ---")

gfd.SetDisplay(GF166, GFunit, 1, "--- --")

end

This section simply mimics the "HOLD" function of the Beech Duke DME by hashing out (---) the displays. While I do not recall for sure (I wrote this portion way back in October), I vaguely recall that either the gfd.SetDisplay would not display properly on the GF-166 or I would get some kind of error message without the inclusion of the FUNCTIONs. This section was purely the result of trial and error. For some reason, it worked.

In fact, this plugin was my very first attempt at working with LUA in conjunction with a GoFlight module. I repeatedly tinkered trying things I read in the manuals and found on the internet until the plugin worked. And in spite of the mess in coding I may have made, it has worked fine for me until recently.

If there is further input you need from me, let me know.

Thank you for your time and your help!

Dan

[Pete Dowson]

If you have the time to revise the plug-in, I would certainly appreciate it and am confident that I would learn a lot by your doing so!

Okay, try this. (I've not tested it for real of course as I don't have your setup, but I've "dry run" it to be sure it's okay in my opinion).

For this you must load it via ipcReady, as the comment stated in your original, but that's it. The one copy stays running all the time. You must change your assignments to use LuaValue <name> instead of Lua <name>, with parameters 1 and 2 as before. This causes the "param" event, which calls the "Select" function.

The displays are updated when necessary on a timer event. I've set that for 250 mSecs, or 4 times per second. You can adjust that to get the results you want.

Note that it also assumes that the L:Var "DME_Switch" actually exists -- the Select function updates it and the PollSwitch function reads it. If you want this to work will all aircraft, including those without that switch, just delete the line

	  switch = ipc.readLvar("L:DME_Switch") -- Reads DME Selector State[/CODE]

and it'll use the internally maintained "switch" value directly, instead.

Here's the code:

[CODE]-- Launched from ipcReady.lua

-- Initialize
GFunit = 1
gfd.SetBright(GF166,GFunit,15)
prevswitch = -1
switch = -1
min1 = 0
min2 = 0
miles1 = 0
miles2 = 0
kts1 = 0
kts2 = 0

local function ConvertTime(value)
min = value / 10 -- convert data to seconds
min = min / 60 -- convert seconds to minutes
if min == 16.665 then
min = 0
else
min = math.floor(min) -- rounds decimal down
end
return min
end

-- functions -- all called by events
function Select(val)
if val == 1 then
if switch > 0 then -- limits encoder switch from going below 0
switch = switch - 1
ipc.writeLvar("L:DME_Switch", switch) -- DME Selector Rotate Left
end
elseif val == 2 then
if switch < 3 then -- limits encoder switch from going above 3
switch = switch + 1
ipc.writeLvar("L:DME_Switch", switch) -- DME Selector Rotate Right
end
end
end

function Time1(offset, value)
min1 = ConvertTime(value)
prevswitch = -1
end

function Time2(offset, value)
min2 = ConvertTime(value)
prevswitch = -1
end

function Distance1(offset, value)
miles1 = "2 " .. value -- Formats DME1 Display
prevswitch = -1
end

function Distance2(offset, value)
miles2 = "2 " .. value -- Formats DME2 Display
prevswitch = -1
end

function Speed1(offset, value)
kts1 = value -- Reads DME2 Speed
prevswitch = -1
end

function Speed2(offset, value)
kts2 = value -- Reads DME2 Speed
prevswitch = -1
end

function PollSwitch()
switch = ipc.readLvar("L:DME_Switch") -- Reads DME Selector State
if switch ~= prevswitch then
if switch == 0 then
gfd.SetDisplay(GF166, GFunit, 0, "")
gfd.SetDisplay(GF166, GFunit, 1, "")
elseif switch == 1 then
ipc.writeUW("0378", 1) -- Set to DME1
gfd.SetDisplay(GF166, GFunit, 0, miles1) -- Display DME1/NM L Window
gfd.SetDisplay(GF166, GFunit, 1, kts1 .. (string.format(" %02.f", min1))) -- Display DME1 KTS/MIN in R Window
elseif switch == 2 then
gfd.SetDisplay(GF166, GFunit, 0, "H ---")
gfd.SetDisplay(GF166, GFunit, 1, "--- --")
elseif switch == 3 then
ipc.writeUW("0378", 2) -- Set to DME2
gfd.SetDisplay(GF166, GFunit, 0, miles2) -- Display DME2/NM L Window
gfd.SetDisplay(GF166, GFunit, 1, kts2 .. (string.format(" %02.f", min2))) -- Display DME2 KTS/MIN in R Window
end
prevswitch = switch
end
end

event.offset("0C29", "STR", 4, "Distance1")
event.offset("0C2E", "STR", 3, "Speed1")
event.offset("0304", "UW", "Time1")
event.offset("0C33", "STR", 4, "Distance2")
event.offset("0C38", "STR", 3, "Speed2")
event.offset("030A", "UW", "Time2")
event.param("Select")
event.timer(250, "PollSwitch") -- Allows 4 updates per sec -- adjust as needed
[/CODE]

Don't hesitate to ask questions if there's anything you don't understand, or if it doesn't do what you want.

Regards

Pete

[Delta14Sierra]

Pete,

We have a good start but there is a snag. When using the GF-166 encoder, the switch will move between the OFF and DME1 positions and display accordingly on both the GF-166 and the FSX panel. However, the switch will not move to the HOLD or the DME2 positions.

When rotating the switch on the FSX panel in the Beech Duke, everything displays just fine on the GF-166.

Thank you for doing this. I am drawing a lot of insight from looking over what you have done. This is most helpful and I am most appreciative!

Dan

[Pete Dowson]

We have a good start but there is a snag. When using the GF-166 encoder, the switch will move between the OFF and DME1 positions and display accordingly on both the GF-166 and the FSX panel. However, the switch will not move to the HOLD or the DME2 positions.

I assume you did change ALL the "Lua" assignments for this to "LuaValue"? Otherwise that would be the sort of problem you'd see, Otherwise I suspect that either multiple "LuaValue" executions are happening, or, more likely, the LVar write is taking longer, so it reads back differently. See if it works with the line reading the L:Var is commented out.

I notice you had

 ipc.sleep(10)[/CODE]

in your original, just after writing the L:Var. Maybe we need to take care of this possibility. Try changing the Select function, thus:

[CODE]
function Select(val)
switch = ipc.readLvar("L:DME_Switch") -- Reads DME Selector State
if val == 1 then
if switch > 0 then -- limits encoder switch from going below 0
switch = switch - 1
ipc.writeLvar("L:DME_Switch", switch) -- DME Selector Rotate Left
end
elseif val == 2 then
if switch < 3 then -- limits encoder switch from going above 3
switch = switch + 1
ipc.writeLvar("L:DME_Switch", switch) -- DME Selector Rotate Right
end
end
ipc.sleep(10)
end
[/CODE]

You may need to experiment with the Sleep value.

For use on arcraft in general you'd need to remove noth L:Var reads.

Regards

Pete

[Delta14Sierra]

Pete,

Thank you again for your time and help on this!

The problem remains the same. The switch will move between the OFF and DME1 positions and display accordingly on both the GF-166 and the FSX panel. However, the switch will not move to the HOLD or the DME2 positions.

I have made sure that the encoder is set in FSUIPC to LuaValue DME: 1=Rotate Left; 2=Rotate Right.

I have tested the plugin by commenting out the L:Var reads, first one, then the other, then both.

When both L:Var reads are commented out, I have to first rotate the GF-166 encoder to the left and then to the right before it will display on the GF-166. Also, with both L:Var reads commented out, the GF-166 display no longer responds to the DME switch changes on the FSX panel. Obviously, without the L:Var reads, the FSX panel in the Beech Duke looses interaction with the plugin.

I have tried altering the sleep value to 100, but that appears to have no affect whatsoever.

Again, when I use the mouse to rotate the DME switch on the FSX panel (with the L:Var reads), the display on the GF-166 responds appropriately.

The problem is in getting the encoder on the GF-166 to do the same thing.

I will have fun tinkering on my end until I hear back from you.

Dan

[Pete Dowson]

The problem remains the same. The switch will move between the OFF and DME1 positions and display accordingly on both the GF-166 and the FSX panel. However, the switch will not move to the HOLD or the DME2 positions.

So the "switch" value only ever gets to 0 and 1, never increases to 2 or 3. That makes no sense to me. If it can increment to 1 it can surely increment to 2 and so on.

Try setting the Lua debug logging option in the FSUIPC logging tab, and alo the "button" logging. No other selections. You'll then need to close FS and restart after since the Lua program will already be running. Then do a systematic test. Turn the dial slowly three times in each direction. Note what you see each time. then close down.

ZIP up the FSUIPC4.LOG and send it to me at petedowson@btconnect.com. I'll work out what is going on from that.

Unfortunately I am away from tomorrow (Friday) lunchtime till sometime monday morning, so this may all get delayed. But at least your original is still usable, right? I'd like to understand why this isn't working right though.

Regards

Pete

[Delta14Sierra]

Pete,

So the "switch" value only ever gets to 0 and 1, never increases to 2 or 3.

Just as a test... Using my original DME plugin, I replaced the ipcPARAMs portion with your Select function, and then set up the encoder in FSUIPC accordingly using LuaValue. The very same problem occurs. Not sure if this narrows things down.

Dan

[Pete Dowson]

Not sure if this narrows things down.

Actually the log you sent explained it. It is my error. I forgot: the events are triggered by a change. The "event.param" will only occur if the value of the parameter is different.

Sorry, it was me being blind! Of course, repeated turns in the same direction won't change the parameter!

The answer is to program the "Press" for a LuaValue with parameter 1 or 2, and the "Release" with a LuaValue with parameter 0. The 0 will be ignored in the Lua but it will make the next value trigger the event again. It just means a definite "click click" to do a selection.

An alternative would be to trigger on a flag being toggled instead, if you'd like to try that. Use, say, flag 1 in place of parameter = 1 and flag 2 instead of parameter = 2. Assign to "LuaToggle <name>" with parameters 1 or 2. Then instead of the Select function and the event.param line you'd have:

function Select1()
	if switch > 0 then -- limits encoder switch from going below 0
		switch = switch - 1
		ipc.writeLvar("L:DME_Switch", switch) -- DME Selector Rotate Left
   end
end

function Select2()
	if switch < 3 then -- limits encoder switch from going above 3
	   switch = switch + 1
	   ipc.writeLvar("L:DME_Switch", switch) -- DME Selector Rotate Right
   end
end

event.flag(1, "Select1")
event.flag(2, "Select2")
[/CODE]

Regards

Pete

[Delta14Sierra]

Pete,

WOW! Awesome! It works great!

I really do appreciate the time you have taken above and beyond my initial concern to help me with this! You have given me new insight into LUA and how to make it work with my GF modules. I look forward to implementing what you have taught me here in my other LUA plugins.

Again, thank you so very much!

Dan