PMDG NGX SDK

[roarkr]

Ok, I wrapped it up as a zipped vs2010 solution in https://docs.google....UM1lMNldpRkxSZw

It's the wrapper dll and a very basic C# example that simply dumps all the variables in a grid and toggles the taxi light switch once in a while.

Have fun!

Hi

I have downloaded your PMDGWrapper to see if I can use some of your coding in a IOCP Client C++ I am coding to interface my Opencockpits hardware modules.

As I am not a professional C++ programmer I don't know what the wrapper really is and what it actually does. Could you explain a little for us "hobby" programmers?

What I really need is a call from your wrapper dll ( if I understand it right) to a function in my C++ whenever there is a change between old and new values of the PMDG data. This call should have both the varname and the value.

I have a hard time to find out what is the ins and what is the outs in this dll of if it can be used. Maybe I am totally misunderstanding it.

Do you have any idea of how this could be done?

rgs

[johanknol]

Hi roarkr! I was already looking for some sioc support for named variables like in:

Var 0737, name flapsin, Link PMDGIN, Input MAIN_TEFlapsNeedle

VAR 738, name flapsout, Link PMDGOUT, Output EVT_CONTROL_STAND_FLAPS_LEVER

But I read somewhere that opencockpits self is working on it, so I decided to wait what that brings first.

If you intend to implement the whole set like above I would be more then glad to help you though. I need that for my next to buy overhead anyway.

But I don't think you need my wrapper for this at all. Since you are already programming in c++ you need only a few line of my wrapper code. Which is nothing more really than also a small part of the sdk example code. But I can imagen that the simconnect stuff frightens you off a little.

What you described about can be done easily, but maybe we should continue to discuss the details offline and come back here when there is news?

regards,

Johan Knol

[dazz]

I finished my module and sent a copy of the installer to PMDG for revision. Robert's been so kind to consider checking it out.

If they say it's ok, I could use some help to beta test it if someone's interested, especially for the offset part (opencockpits panels)

[paulnd]

I finished my module and sent a copy of the installer to PMDG for revision.

Excellent news!

I could use some help to beta test it if someone's interested, especially for the offset part (opencockpits panels)

Happy to help

Paul

[dazz]

Thanks Paul. I'll keep you posted

[dazz]

One question please. I'm trying to spawn a thread to run the communication with the NGX

void startThread() {
	initCommunication();
}
extern "C" __declspec(dllexport) int luaopen_ngxSDK2Lua(lua_State *L){
	// register Lua functions
	static const luaL_Reg functs [] = {
		{"registerOffsetMap", cpp_registerOffsetMap},
		{"registerLuaFile", cpp_registerLuaFile},
	...
		{NULL,NULL}
	};
	luaL_register(L,"ngxSDK2Lua", functs);
	LuaGlobal = L;
	if (active) {
		return 0;
	}
	// run installed modules
	...
	boost::thread thrd(startThread);
	thrd.detach();
	return 0;
}
[/CODE]

this runs the first time I do a require "ngxSDK2Lua" in Lua. The idea is that control returns to the Lua script while the dll does it's stuff, but as soon as the the function returns, the child thread that starts the SimConnect communication dies.

Until now I was starting the module using an independent Lua thread with ipc.runlua, but this would be better. Is it even possible please?

[Pete Dowson]

this runs the first time I do a require "ngxSDK2Lua" in Lua. The idea is that control returns to the Lua script while the dll does it's stuff, but as soon as the the function returns, the child thread that starts the SimConnect communication dies.

Until now I was starting the module using an independent Lua thread with ipc.runlua, but this would be better. Is it even possible please?

Sorry, I have no idea. Why is the child thread dying? Certainly FSUIPC's inbuilt Lua interpreter can know nothing about it. I think you need to try to find out what is happening with a debugger -- it must surely be to do with the thread code itself, which you don't show. Is it in a continuous loop, like a message loop so you get SimConnect messages?

If it exits, it dies of course.

The DLL cannot be getting unloaded on exit back to the calling Lua program because it is returning links to the procedures within it. So the DLL code is still in memory and the thread should be running.

Regards

Pete

[dazz]

It doesn't even get to the loop. The child dies because the parent dies (the function above returns). When the function

extern "C" __declspec(dllexport) int luaopen_ngxSDK2Lua(lua_State *L)
[/CODE]

exits, the thread that created the child that runs the SimConnect part (startThread above) dies, and with it dies the "startThread" child.

So the timeline would be like...

Lua: require "ngxSDK2Lua"

dll: extern "C" __declspec(dllexport) int luaopen_ngxSDK2Lua(lua_State *L)

dll: spawns the "initCommunication" thread that should start the SimConnect part

dll: the function luaopen_ngxSDK2Lua exits, execution back to Lua. Parent thread dies

dll: child thread dies at some point while configuring SimConnect because the parent just died, FSX crashes to desktop.

I would need some sort of Linux "fork" like function maybe? not sure, but I've reverted back to the old version with an init Lua script that I'll start with ipc.runlua so that the SimConnect stuff runs on it's own thread.

[Pete Dowson]

It doesn't even get to the loop. The child dies because the parent dies (the function above returns).

But the "parent" is FSX, the same parent as for FSUIPC and all of its threads and all of the Lua threads. A function which starts a thread does not have to keep running. That would make threads useless. And, as i said, the collection of library functions which IS the DLL must still be ready and functional because it is passing back links to other functions within it to the Lua part.

DLLs are simply run-time linked libraries, no more. The "CreateThread" function itself, which you call to create a thread, is in a Windows DLL and the thread it creates doesn't "die" just because the CreateThread function exits!

Static libraries are the same as DLLs but linked at compile time and loaded with the program rather than later. If what you say happens really happens then no one could ever use threads!

So, I think you are misinterpreting what is happening. Or maybe it's to do with these parts here:

 boost::thread thrd(startThread);
 thrd.detach();
[/CODE]

which I don't understand as I don't know what they do. Maybe you shouldn't "detach"? What does that do? I only use the standard CreateThread function for threads. I don't use C++ so i don't understand this "boost:: ... " business I'm afraid.

Regards

Pete

[dazz]

Damn, it's true!, it's not what I said. I'm trying with a release version of the dll with some traces in the log and the loop is running in the new thread. It's doing some weird things but it's running for sure and the creator thread is back to running the Lua script that launched the dll.

The module runs but every now and then, randomly, a call to Lua fails (this is the FSUIPC log, where I print what comes from the dll. Every log line is a switch/knob I clicked):

IRS_DisplaySelector: 1
IRS_SysDisplay_R: 0
IRS_DisplaySelector: 2
IRS_DisplaySelector: 3
IRS_DisplaySelector: 4
IRS_DisplaySelector: 3
IRS_DisplaySelector: 2
IRS_DisplaySelector: 1
[E] *** LUA Error: ...ht Simulator X\modules\linda/system/handlers-mcp.lua:168: attempt to perform arithmetic on a nil value
IRS_DisplaySelector: 0
IRS_DisplaySelector: 1
IRS_DisplaySelector: 2
IRS_DisplaySelector: 1
IRS_DisplaySelector: 2
[E] *** LUA Error: (null)
IRS_DisplaySelector: 1
IRS_DisplaySelector: 2
[E] *** LUA Error: attempt to call a number value
[/CODE]

...and finally crashes:

Unhandled exception at 0x773015ee in fsx.exe: 0xC0000005: Access violation reading location 0x56085da3.

I'll see what I can do.

By the way, I'm doing this thing modular, so one will only need to drop a script in a folder and the dll will do the rest, and if you add a supported panel in the future, you just add the script (or run the installer again) and off you go.

I plan on including some module(s) with the installer ready to use, maybe some GoFlight & Opencockpits panels

[Pete Dowson]

I'll see what I can do.

Okay. Let me know if you need help on the Lua/FSUIPC side.

Also note that I am still hopeful that FSUIPC4 can provide direct offset mapping for all the PMDG 737NGX data. The facility is already programmed. I am only waiting for PMDG's okay, because of the worrying EULA.

Regards

Pete

[dazz]

Also note that I am still hopeful that FSUIPC4 can provide direct offset mapping for all the PMDG 737NGX data. The facility is already programmed. I am only waiting for PMDG's okay, because of the worrying EULA.

There's a note in my Readme warning about that, and advising to check your forums here for possible news before doing anything with my dll.

I still think this could end up being a useful Lua script installer, even if it doesn't use my dll at all.

[Pete Dowson]

There's a note in my Readme warning about that, and advising to check your forums here for possible news before doing anything with my dll.

I still think this could end up being a useful Lua script installer, even if it doesn't use my dll at all.

Yes, I wasn't trying to stop you, only saying that it perhaps isn't something to get overtly worried about ... yet! ;-)

And, yes, I see it could be useful for other expansions of the Lua capabilities, so I hope you get it working satisfactorily.

Regards

Pete

[FSMP]

Also note that I am still hopeful that FSUIPC4 can provide direct offset mapping for all the PMDG 737NGX data. The facility is already programmed. I am only waiting for PMDG's okay, because of the worrying EULA.

Regards

Pete

We are ALL hopeful of that Pete. Thanks for looking to provide that. :razz:

Will certainly make it a LOT easier for those who are not C++ Programmers.

Geoff

(Thanks also for the timely FSUIPC update for P3D 1.3 -- You are amazing )

[roarkr]

Hi Pete,

I'm almost ready with my new OpenCockpits IOCP Client for NGX based on the new NGX SDK, but need to make it a little more efficient.

You mentioned in this thread some time ago that using a loop for the CallBack MyDispatchProc was not recommended, but instead:

"

The method I recommend is to use Simconnect_Open with your message-only (HWND_MESSAGE class) Window handle as the 3rd parameter and a user message number defined by you as the 4th parameter. Then you call "CallDispatch" when you receive that message. This is bay far the most efficient method."

Could you specify this in more detail as I can't figure out the coding for that.

rgs

Roar

[Pete Dowson]

Could you specify this in more detail as I can't figure out the coding for that.

How can there be more detail than providing the window handle in the 3rd parameter with a user message defined for you to receive and then process the dispatch? It's as per Simconnect documentation. and as I stated.

If you don't understand it then it may be best not to use it? What part is not to understand?

Regards

Pete

[dazz]

Pete maybe you can give me some guidelines on how to proceed to debug this:

When I restart the dll in the middle of a flight, I can do it in two ways:

1.- Call the Lua script that starts the dll. It calls a function in the dll that starts the SimConnect communication. When I do that the previous instance seems to vanish on it's own, and the new one starts just fine. Problem is that after a number of restarts I get a CTD in FSUIPC4.dll (different fault offsets, here's two examples):

Exception code: 0xc0000005

Fault offset: 0x0004afc2

Faulting process id: 0x1944

Faulting application start time: 0x01cd118cc82d9b4b

Faulting application path: C:\Program Files (x86)\Microsoft Games\Microsoft Flight Simulator X\fsx.exe

Faulting module path: C:\Program Files (x86)\Microsoft Games\Microsoft Flight Simulator X\Modules\FSUIPC4.dll

Exception code: 0xc0000005

Fault offset: 0x0004dbaa

Faulting process id: 0x1ab4

Faulting application start time: 0x01cd118f381ebe6b

Faulting application path: C:\Program Files (x86)\Microsoft Games\Microsoft Flight Simulator X\fsx.exe

Faulting module path: C:\Program Files (x86)\Microsoft Games\Microsoft Flight Simulator X\Modules\FSUIPC4.dll

2.- If I do a Lua KillAll I get an instant CTD in ntdll.dll:

Exception code: 0xc0000029

Fault offset: 0x000907b6

Faulting process id: 0xc84

Faulting application start time: 0x01cd118ba3ba321e

Faulting application path: C:\Program Files (x86)\Microsoft Games\Microsoft Flight Simulator X\fsx.exe

Faulting module path: C:\Windows\SysWOW64\ntdll.dll

what tools can I use to figure out where the problem is please?

[Pete Dowson]

Pete maybe you can give me some guidelines on how to proceed to debug this:

It isn't easy. In fact it is almost impossible unless I can trap the error in FSUIPC or get a full stack trace.

The information you posted would be very useful IF you were using the exact same version of FSUIPC as me, because I could then find exactly where in the code the FSUIPC crash was. To that end please reproduce it using FSUIPC4812f

On this one:

2.- If I do a Lua KillAll I get an instant CTD in ntdll.dll:

If your DLL is creating another thread then you need to have it terminating itself when the main Lua thread terminates. To do this try using

event.terminate

which should allow you to call some function in your DLL to close down.

Regards

Pete

[dazz]

It isn't easy. In fact it is almost impossible unless I can trap the error in FSUIPC or get a full stack trace.

The information you posted would be very useful IF you were using the exact same version of FSUIPC as me, because I could then find exactly where in the code the FSUIPC crash was. To that end please reproduce it using FSUIPC4812f

On this one:

If your DLL is creating another thread then you need to have it terminating itself when the main Lua thread terminates. To do this try using

event.terminate

which should allow you to call some function in your DLL to close down.

Regards

Pete

Ok, I'll try that version of FSUIPC.

It's a very rare occurrence really so it doesn't worry me much. I need to keep restarting the dll over and over again to trigger the error, so it's not that big of a deal I think.

As for the event.terminate part, I'll try that, but I'm not creating a new thread in the dll in the end. It was crashing like mad when I tried it and couldn't figure out why, but will see if event.terminate helps

Thanks for the suggestions

[dazz]

Here's the log in the event viewer with version 4.812f

Exception code: 0xc0000005

Fault offset: 0x0004f590

Faulting process id: 0x1bbc

Faulting application start time: 0x01cd119264c5fc9a

Faulting application path: C:\Program Files (x86)\Microsoft Games\Microsoft Flight Simulator X\fsx.exe

Faulting module path: C:\Program Files (x86)\Microsoft Games\Microsoft Flight Simulator X\Modules\FSUIPC4.dll

And I tried the event.terminate thing (this is the script I use to start & restart the dll, calling it from ipcReady with ipc.runlua, so that it runs in it's own thread):

require "ngxSDK2Lua"
function restartNGXSDK2Lua()
acName = ipc.readSTR(0x3D00, 100)
if (string.find(acName, "NGX") == null) then
  return
end

resp = ngxSDK2Lua.start();

if (resp ~= nil) then
  ipc.log(resp)
end
end
function kill()
ipc.log("Killing ngxSDK2Lua ...............")
resp = ngxSDK2Lua.kill();

if (resp ~= nil) then
  ipc.log(resp)
end
end
event.offset(0x3D00, "STR" , "restartNGXSDK2Lua")
event.terminate("kill")

[/CODE]

...but I don't see the "Killing ngxSDK2Lua ..............." trace printed in the log, not sure it's working

[Pete Dowson]

Here's the log in the event viewer with version 4.812f

Exception code: 0xc0000005

Fault offset: 0x0004f590

Okay, thanks. I'll look to see where that is.

And I tried the event.terminate thing (this is the script I use to start & restart the dll, calling it from ipcReady with ipc.runlua, so that it runs in it's own thread):

...but I don't see the "Killing ngxSDK2Lua ..............." trace printed in the log, not sure it's working

I think it might be optimistic to expect a log message to get out in the few milliseconds event.terminate gives you. Best to just make sure things are closed before the thread is killed. In fact let it kil itself, thus:

function kill()
   ngxSDK2Lua.kill();
   ipc.exit()
end[/CODE]

The proof of whether this helps is if it prevents CTDs.

Regards

Pete

[dazz]

Roger that.

And please Pete, don't let the FSUIPC4.dll crash steal too much of your time. It really takes a bunch of restarts to crash the sim.

[dazz]

Project released, in case someone wants to check it out

http://forum.avsim.net/topic/368674-a-little-project-of-mine-for-simpit-builders-ngxsdk2lua/

[Pete Dowson]

For information:

Version 4.82 of FSUIPC4 is now released, and contains the PMDG 737NGX SDK data (read-only) mapped to offsets. A full list is provided in the release package. This has been added with permission of PMDG subject to stated usage conditions.

Regards

Pete

[johanknol]

Thanks Pete, this will make live a lot easier!

Your implementation however shows the same anomalies as my C# wrapper (no. 99 in this topic): the ngx seems dead. I tracked it down so far that

every other time the plane gets loaded it does not send SIMCONNECT_RECV_ID_CLIENT_DATA messages to the dispatch proc.

E.g., using that nice fsuicp feature on the logging tab I have offset 6570 on screen, toggle the gear lever, the value changes with it. Reload the plane, nope. Reload the plane, yes! And that goes in the same pace as the lights on my mip with just the C# wrapper and a IOWarrior usb board. (Yes, I also tried without my C# wrapper running :).

So I don't think it's fsuicp, I still hoped to find something on my side, but now I think pmdg needs a call about this. I "fixed" it by the way, by detecting a ngx load, disconnect and reconnect to simconnect.

I know it's not only my machine since I had a couple of mails about this issue from other people.

Hth and thanks again for the update,

Johan Knol