Meadville Space Center
Welcome, Guest. Please login or register.
May 21, 2013, 05:56:27 AM

Login with username, password and session length
Search:     Advanced search
Gemini 060615 released!
20010 Posts in 1929 Topics by 2250 Members
Latest Member: mikegk
* Home Help Search Login Register
+  Meadville Space Center
|-+  Project Apollo - NASSP
| |-+  Project Apollo - NASSP Development (Moderators: movieman, Tschachim, Swatch, lassombra)
| | |-+  LunarTransferMFD
« previous next »
Pages: 1 2 [3] 4 Print
Author Topic: LunarTransferMFD  (Read 9610 times)
Tschachim
Project Apollo - NASSP
Administrator
Hero Member
****
Posts: 3687


nassp.sf.net


View Profile WWW
« Reply #30 on: March 30, 2009, 08:09:39 AM »

I understand the problem, but I do not like a "keyboard simulation" solution, I think the problem can be solved by changing the current IPC solution as well, it's just not designed to support multiple "communication partners". I need to think about that...

Cheers
Tschachim
Logged

jarmonik
Full Member
***
Posts: 130


View Profile Email
« Reply #31 on: March 30, 2009, 09:40:45 AM »

I think the problem can be solved by changing the current IPC solution as well, it's just not designed to support multiple "communication partners". I need to think about that...

Yes, that's possible. Two most important things are GET syncronization and burn data uplink. GET syncronization can be solved by making the launch MJD globally available for all MFDs. This could be done by the master MFD (the first one called by the Orbiter). Burn data uplink can be solved by adding uplink button in the MFDs. In that case used must press 'REQ' button from the PAMFD and after that 'uplink' button from the MFD that is holding the data. This shouldn't require any modifications in the current IPC interface.

One possibility is to count a number of active source MFDs, and if there is only one active MFD then that's the one that should interface with PAMFD. I suppose that should be the case most of the time.

However, if turning over to active data interface class is better idea than staying in a static data structure, there are severals ways to deal with that too and the callbacks if needed.
Logged
Graham2001
Guest
« Reply #32 on: April 13, 2009, 07:44:58 PM »

I'm still getting the CTD problem on my installation when I select the LTMFD. However with the latest version it is not an immediate CTD. I hear the slection 'click' noise and a couple of seconds later I get the windows error box.

I'm attaching the error log that resulted to this email.

* IFP-SDK_Err.html (2.77 KB - downloaded 112 times.)
Logged
jarmonik
Full Member
***
Posts: 130


View Profile Email
« Reply #33 on: April 14, 2009, 03:05:48 AM »

This could have something to do with the sound interface. It could be some other thread that will CTD. There is nothing in the LTMFD that could do this in this point. Can you run Orbiter under debugger ? And what does the technical information say from the dialog after the CTD ?

I was once able to trace the CTD in "DoTrace" function. This is probably not the same CTD but it happend while opening MFD and it had something to do with a Sound system. Here is a screen shot attached:

EDIT: I suppose that the reason for the CTD was that MsgProc() returned NULL pointer for the Orbiter instead of valid MFD pointer. That's not an issue with the LTMFD now.
 


* CTD.gif (50.06 KB, 1280x1024 - viewed 149 times.)
« Last Edit: April 14, 2009, 03:12:28 AM by jarmonik » Logged
Graham2001
Guest
« Reply #34 on: April 14, 2009, 06:36:48 PM »

This could have something to do with the sound interface. It could be some other thread that will CTD. There is nothing in the LTMFD that could do this in this point. Can you run Orbiter under debugger ? And what does the technical information say from the dialog after the CTD ?

I was once able to trace the CTD in "DoTrace" function. This is probably not the same CTD but it happend while opening MFD and it had something to do with a Sound system. Here is a screen shot attached:

EDIT: I suppose that the reason for the CTD was that MsgProc() returned NULL pointer for the Orbiter instead of valid MFD pointer. That's not an issue with the LTMFD now.
 

I don't think I have the right software to run it under debugger, I was using the latest (Alpha 4) version for the flight I've just reported. I'm going to disable orbiter sound and see what happens.
Logged
jarmonik
Full Member
***
Posts: 130


View Profile Email
« Reply #35 on: April 14, 2009, 11:13:03 PM »

You could try to run it in clean installation of Orbiter without any other addons. With default DeltaGlider for an example.
Logged
jarmonik
Full Member
***
Posts: 130


View Profile Email
« Reply #36 on: April 15, 2009, 10:41:52 AM »

I don't think I have the right software to run it under debugger...
In order to do so you need at least MS Visual C++ 2005 Express or MS Visual C++ 2008 Express, they are both available for free from the internet. But I suppose it's pretty big download.
Logged
jarmonik
Full Member
***
Posts: 130


View Profile Email
« Reply #37 on: April 25, 2009, 05:29:34 AM »

Ok, I have fixed the IPC issue form LTMFD and IMFD. When PAMFD is requesting burn data, MFD that has been last, previously, used will reply to request. When any button is pressed from MFD, focus will change to that one. This doesn't require any modifications to IPC interface.

I also founded a bug that could have caused the CTD that we have been talking about. CTD would happen if PAMFD is allready requesting data while opening LTMFD.

I'll still need to implement few things before uploading final betas and start working a manual for LTMFD. I tried to implement the advanced features of lunar orbit insertion (PeA, LPe) but things didn't worked out as easily as I hoped. Also implementation of plane change during LOI would require more information about the goal of the plane change. (i.e. what should be archived with it). One possibility is that I would simply add dVp (Plane change delta velocity) parameter to LOI program so that it would be user decision of how much of plane change velocity will be applied.
Logged
Tschachim
Project Apollo - NASSP
Administrator
Hero Member
****
Posts: 3687


nassp.sf.net


View Profile WWW
« Reply #38 on: April 25, 2009, 01:44:28 PM »

Great news, I'm very happy that we don't need to change the interface (and AMSO/Alain, too) as I'm still busy with the new pad loads, thanks for your efforts!  Thumbs Up

Cheers
Tschachim
Logged

Graham2001
Guest
« Reply #39 on: April 25, 2009, 07:27:45 PM »

I also founded a bug that could have caused the CTD that we have been talking about. CTD would happen if PAMFD is allready requesting data while opening LTMFD.

I look forward to testing out the latest version when available to see if it does cure the problem.

Graham
Logged
jarmonik
Full Member
***
Posts: 130


View Profile Email
« Reply #40 on: May 03, 2009, 11:59:08 AM »

OK, I have finished and uploaded the release candidate of IMFD 5.2 and LTMFD 1.0. There are still many features unfinished in LTMFD but I don't know how much time I have during the summer, therefore, I'll try to release it with the current features A.S.A.P.

This release doesn't have a manual yet but I am working on it.

LTMFD: http://koti.mbnet.fi/jarmonik/LTMFD10.zip

IMFD: http://koti.mbnet.fi/jarmonik/IMFD52.zip
 

EDIT: BTW, I was thinking of removing P30Comp mode 2 from the IMFD. Is there any versions of NASSP those would actually need it ?
« Last Edit: May 03, 2009, 12:02:52 PM by jarmonik » Logged
Tschachim
Project Apollo - NASSP
Administrator
Hero Member
****
Posts: 3687


nassp.sf.net


View Profile WWW
« Reply #41 on: May 06, 2009, 06:25:05 PM »

EDIT: BTW, I was thinking of removing P30Comp mode 2 from the IMFD. Is there any versions of NASSP those would actually need it ?

As far as I understand it, no, as the latest beta already contains your patch?

Testing the new versions...  Thumbs Up

EDIT:

Mini-Bug LTMFD LOI program: In Pri = ApAlt, if I set ApA to 0, it displays -1.7381M (altitude / distance mismatch?)
Question: Would it be possible that I enter the landing site, too, and the LOI program tries to optimize the landig site alignment, too (as far as possible)?

Cheers
Tschachim
« Last Edit: May 07, 2009, 12:19:35 PM by Tschachim » Logged

bluespace88
Project Team Member
Full Member
****
Posts: 241



View Profile
« Reply #42 on: May 08, 2009, 08:40:32 AM »

For the landing site, just change the mod from heading to surface, and then change the new target function to a landing site.
Logged
Graham2001
Guest
« Reply #43 on: May 08, 2009, 11:23:25 AM »

I've just tried out the DG_TEI scenario and got the same result as before, CTD shortly after the MFD is selected. I'm wondering if my older model machine is not powerful enough to handle the calculations Embarassed.

Attached is the debugging log from the test run.

* IFP-SDK_Err.html (0 KB - downloaded 80 times.)
Logged
Tschachim
Project Apollo - NASSP
Administrator
Hero Member
****
Posts: 3687


nassp.sf.net


View Profile WWW
« Reply #44 on: May 08, 2009, 12:45:12 PM »

For the landing site, just change the mod from heading to surface, and then change the new target function to a landing site.

Yes, in the TLI program, but in the LOI program I only see mod = simple?
Logged

Pages: 1 2 [3] 4 Print 
« previous next »
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.10 | SMF © 2006-2009, Simple Machines LLC Valid XHTML 1.0! Valid CSS!