Assigning "Course Adjust" knob on G1000

[vmilner]

Hello,
I have just purchased FSUIPC 4 and am trying to assign buttons on a CH Yoke to fly Cessna G1000 on a FSX-Steam.

There are two knobs on a G1000 panel which are called "Course adjust" and "Heading bug adjust". I see how to assign their rotation (via Increase and Decrease FSUIPC controls), but I cannot figure out how to emulate the "set" functionality, when the heading bug is set to the current heading and/or the CDI is set towards the current VOR. On the FSX panel, those actions are achieved by pressing the mouse exactly underneath the corresponding knob.

Any advice will be much appreciated!

 

[Pete Dowson]

12 hours ago, vmilner said:

There are two knobs on a G1000 panel which are called "Course adjust" and "Heading bug adjust". I see how to assign their rotation (via Increase and Decrease FSUIPC controls), but I cannot figure out how to emulate the "set" functionality, when the heading bug is set to the current heading and/or the CDI is set towards the current VOR. On the FSX panel, those actions are achieved by pressing the mouse exactly underneath the corresponding knob.

Assuming it can actually be used without the mouse, you could try enabling Event logging in the FSUIPC Logging tab, then use that button (with the mouse) in both modes, and check in the FSUIPC4.LOG file (in the sim's Modules folder) to see what control, if any, is logged.

For the autopilot heading it is usually AP hdg hold on. which is not the same as AP panel heading hold, which would make the aircraft turn to the setting shown, not the current heading. Not sure about the CDI though. I've only ever seen manual adjustment (VOR1 OBI dec and inc), but then I've never used a G1000.

If no named control is logged, then the function is probably encoded internally in the G1000 gauge. In that case the only answer might be using Mouse Macros, or maybe local panel variables (L:vars).

Pete

 

[vmilner]

Thank you Pete!

Using logging per your suggestion shows that controls 'HEADING_BUG_SET' and 'VOR1_SET' are called for those mouse clicks. However, instead of a default parameter value of 0, they are called with the current aircraft heading and current heading to VOR1 values, respectively. I suspect that there is no way to extract those values from FSX? Looking at the list of local panel variables, not a single one of them corresponds to those two parameters.

Unfortunately, Mouse Macros do not work for a built-in Cessna172 (I do not get any green screens after turning the macro creator On).

Any other suggestions?

Val

[Pete Dowson]

31 minutes ago, vmilner said:

However, instead of a default parameter value of 0, they are called with the current aircraft heading and current heading to VOR1 values, respectively.

Yes. most if not all controls ending in "_SET" need a parameter to set.

31 minutes ago, vmilner said:

I suspect that there is no way to extract those values from FSX? Looking at the list of local panel variables, not a single one of them corresponds to those two parameters.

Yes, those values can be read from FSUIPC Offsets. You'd need a Lua plug-in to do that.

There are some controls starting "G1000 ..." I don't see anything specific for these in the list, but there's a lot of "SOFTKEY" ones (12 altogether). Could the ones you want be  "soft keys"?

Pete

 

[vmilner]

Ok, I am going to check the Advanced User manual for how to do that (I assume it's there), but if it doesn't take too long to explain, any guidance would be appreciated. I am decently good with computer programming, but a real first-timer with flight sim software. E.g. I have no idea what a Lua plug-in is and how to install it/use it.

Thanks!

Val

[Pete Dowson]

2 minutes ago, vmilner said:

I am going to check the Advanced User manual for how to do that (I assume it's there), but if it doesn't take too long to explain, any guidance would be appreciated.

No. Lua plug-ins arecovered in the separate Lua documentation. And offsets are listed in the List of Offsets. All these documents are in your FSUIPC Documents folder.

There are plenty of examples of plug-ins provided there too, in a ZIP file, and you can find other contributions from users in the User Contributions subforum here.

Have you thought of getting a third party aircraft for your needs, instead of using the default? The default ones are really quite basic in most respects, so if you are as keen as it sounds it would be worth investigating add-on aircraft. Make sure you read the reviews though before spending any money, and perhaps visit their support forum to see if they are well supported.

Pete

 

[vmilner]

Thank you again Pete. I am going to investigate the plug-ins and offsets later today.

As to a third party aircraft, I am a beginner pilot starting my instrument rating training. For me, setting up a flight simulator had a sole purpose of practicing various IFR procedures (holds, SIDs etc.). So my thinking was to be as minimalistic as possible (i.e. scenery or realistic looks are not very important). However, if having a better a/c will help me practice IFR, I certainly agree that it's worth looking into.

Val

[spokes2112]

A lua file will definitely have to be used as there are some L: vars involved.
Below are the mouse click scripts for each of the commands you require.
The heading bug & OBS inc/dec also have additional code on top of the FSUIPC inc/dec commands to highlight the G1000 window area when values have changed. 

Heading bug to current -
 

1 (>L:pfd HDGKnob pressed, bool)
(A:Plane heading degrees gyro, degrees) (>K:HEADING_BUG_SET) 
(P:Absolute time, seconds) (>L:time hdg bug changed, seconds)

OBI to current -
 

(A:GPS drives NAV1, bool) if{ quit }
(L:CDI source selected, enum) 1 == 
if{
	(A:NAV1 radial, degrees) 180 - dnor
	(>K:VOR1_SET) 
} 
(L:CDI source selected, enum) 2 == 
if{
	(A:NAV2 radial, degrees) 180 - dnor
	(>K:VOR2_SET) 
}
(P:Absolute time, seconds) (>L:time crs changed, seconds)

 

 

[Pete Dowson]

3 hours ago, spokes2112 said:

A lua file will definitely have to be used as there are some L: vars involved.
Below are the mouse click scripts for each of the commands you require.

Those aren't in the Lua which FSUIPC's inbuilt version 5.1 uses.  At least I don't recognise it. They look more like scripts for the PANELS.DLL. I think you might need to give Val more clues as to what to do with them. (or me so I can translate).

Pete

 

 

[spokes2112]

Hi Pete...

The G1000 is in xml so all the L:vars should be visible to lua.
All the rest can be done with offsets -

(A:GPS drives NAV1, bool) --> 0x132C
(P:Absolute time, seconds ) --> 0x0230
(A:NAV1 radial, degrees) --> 0x0C50
(>K:VOR1_SET) --> 0x0C4E
(A:NAV2 radial, degrees) --> 0x0C60
(>K:VOR2_SET) --> 0x0C5E

Val, if you need any help with a lua I'd be willing to.
Perfect little project to go with the morning coffee 😉

Roman

[Pete Dowson]

3 hours ago, spokes2112 said:

The G1000 is in xml so all the L:vars should be visible to lua.
All the rest can be done with offsets -

I asumed that what it must be about. I am just not familiar with "mouse click scripts", nor really how you can write software in XML. Lua is basically a script writing language, in which you can write programs, of course. Hence I thought it might be confusing without some further explanation..

I would have explained it, but I'm not familiar with the syntax you displayed I'm afraid.  What are "A:Vars", "P:Vars" and "K:Vars", and what does &gt" mean? Should these be obvious? Would they be covered in the Panels SDK documentation?

Thanks,
Pete

 

[spokes2112]

Hi Pete,

Yes it should all be in the SDK / PDK. A short explanation to start -
A: vars = Aircraft variables: read
P: vars = Program variables (eg Sim Rate) sometimes included as E: type vars: read
E: vars = Environmental variables (eg Time) : read
G: vars = User vars 1-9 local to the gauge only: read / write
L: vars = User vars global to all gauges: read / write
M: vars = Mouse parameters (eg location XY, click type) : read
K: vars = Key code (eg commands to sim): write 
There are a couple more advance ones, R:vars & C:vars, the latter used in the GPS xml to interface with the gps.dll
When writing to vars  -  G:  L:  K:  in xml -
 

> is the same as > just like in html

Have a great day!
  
 

[Pete Dowson]

5 hours ago, spokes2112 said:

A short explanation to start

Thanks. So these:
A: vars = Aircraft variables: read
P: vars = Program variables (eg Sim Rate) sometimes included as E: type vars: read
E: vars = Environmental variables (eg Time) : read
are SimConnect Variables or "SimVars",  

this 
M: vars = Mouse parameters (eg location XY, click type) : read
is only available to me via the PDK (as used in the FSUIPC5 Mouse Macro facility)

and these are KEY EVENTS (or what i've always called "controls" as they were in early versions of FS)
K: vars = Key code (eg commands to sim): write 

5 hours ago, spokes2112 said:

> is the same as > just like in html

Well, i don't know html either, but I guessed it was >, but this syntax is mystifying:

	(A:NAV1 radial, degrees) 180 - dnor
	(>K:VOR1_SET) 

Meaning what? "Read NAV1 radial, do something odd with something called "dnor" but undefined (?), and if it is Greater Than something (?) send it as the parameter for control VOR1_SET"?

The differentiation between reading something and writing it isn't obvious from the syntax. Yes, key events can only be "written" (sent really), but SimVars can mostly be read or written.

You don't need to answer. I will just have to make time to read the SDK, when I actually need to know. But it seems likely that first I'd need to read a book on the type of XML being used -- it looks very different to the XML used in P3D's configutation files.

I was just really seeking clarification for others reading this, mainly Val, the OP, of course.

Thanks,
Pete

 

[spokes2112]

Hi Pete,

Xml gauges use RPN (reverse polish notation) for arithmetic, just to make it more fun.. LOL!
1st subtract 180* from the radial. Radials go outbound from station, we need inbound.  (A:NAV1 radial, degrees) 180 - 
dnor = is a degrees normalize operator.. It automatically does - If greater than 360 then subtract 360, if less than zero then add 360. (A:NAV1 radial, degrees) 180 - dnor
Send it to the VOR1 OBS control. (A:NAV1 radial, degrees) 180 - dnor (>K:VOR1_SET) 

Just FYI.. Have fun with XML :) but what you do / use is much more powerful!  

[Pete Dowson]

1 hour ago, spokes2112 said:

Just FYI

Thank you!

Pete

 

[vmilner]

Hi Pete and Roman,

Thank you both for posting all this info, and sorry for not replying right away. I actually went with Pete's advice and learned how to program in lua with offsets. Found it not too hard and super useful. Here is my two-liner for setting the Obs:

-----

obs2=ipc.readSW(0x0C60) * 360 / (65536) +180
ipc.writeSW(0x0C5E,obs2)

----

And here is how I set the heading bug:

----

lat, lon, alt, pitch, bank, hdgT = ipc.readStruct(0x0560,"3DD", "2SD", "1UD")

hdgM = hdgT - (ipc.readSW(0x02A0) * 65536)

hdgM = hdgM * 360 / (65536 * 65536)

ipc.writeSW(0x07CC,hdgM*65536/360)

------

 

Programmed a few other things too, like displaying current Dme distance in the Lua window. 

Thanks Pete for such a useful tool!! I wouldn't be able to do my IFR training at home without it.

Val