Meadville Space Center
Welcome, Guest. Please login or register.
August 08, 2020, 04:13:26 AM

Login with username, password and session length
Search:     Advanced search
25068 Posts in 2094 Topics by 2266 Members
Latest Member: twa517
* Home Help Search Login Register
+  Meadville Space Center
|-+  Project Apollo - NASSP
| |-+  Project Apollo - NASSP Development
| | |-+  Programming (Moderators: movieman, dseagrav, Swatch, lassombra)
| | | |-+  Minimising or even removing the debug line.
« previous next »
Pages: [1] Print
Author Topic: Minimising or even removing the debug line.  (Read 1224 times)
lassombra
Moderator
Sr. Member
****
Posts: 410


View Profile Email
« on: December 18, 2007, 03:21:07 AM »

I know it's a useful line and that it can easily be used to give important messages to users.  The catch?  It is often used to slightly... less appealing uses.  One example is in the current telecom code, at high bitrate, it starts spewing out a ton of "measure this" messages, which ultimately are completely useless.  If they are useful, it is only to whoever is currently using them to follow their code.

What I propose is this:  We already have a module that is used to provide output and interface to the user not available through the panel.  We have the facilities, and even some example code now, already in place to easily create a debug string output ON the MFD.

It would be simple:

PAMFD would have a static member which would be a static char array of reasonable length.  It would then have a method that passed the reference to the array, much the same as the current oapiGetDebugString() method does.

The Saturn class would then have a reference to just such a method.  In the constructor function, that reference would be pointed to the MFD if possible.  If that fails, it would be a reference to the oapiGetDebugString() as before.  What it would do is allow debug data to be sent to the MFD instead of the command line, assuming the MFD is available.  If the data being output is important to the user, then output it to the user as we always have.  If it's important to be able to see it when the MFD is unavailable, then go ahead and use oapiGetDebugString();  If it isn't important, use the new pointer so that we can keep the bottom of the screen friendlier.

I will go ahead and code this up, but I'll wait to commit till I get a response as to whether this is something we want/would use.  If we don't, it won't be a waste of my time honestly, as the exercise is going to be used as practice for something else I'm going to do anyways, on another project.  I'm just offering to keep it available.
Logged

My current Project Apollo work:

Quickstart to the Moon initiative (Quickstart_to_the_Moon): Done through earth orbit.  Working on new method of calculating TLI.

Checklist Controller: 
  • MFD Interface 99%(Minor cleanup and future features remain)
  • Panel Interface 99%
  • Excel interface and logic 99%
  • LEM Event code.0%
  • DSKY Interface code. Framework complete, creating "buttons"
  Approximately 80% done. (Checklist Controller
Tschachim
Project Apollo - NASSP
Administrator
Hero Member
*****
Posts: 3700


nassp.sf.net


View Profile WWW
« Reply #1 on: December 18, 2007, 12:41:57 PM »

I second that, in my opinion oapiGetDebugString() should only be used to display severe technical problems (like "Telecom bind failed") or configuration problems (like disabled non-spherical gravity sources in VAGC scenarios), but not as normal user interface. In fact I removed a lot oapiGetDebugString() calls in the past and replaced them with a "proper" user interface, I didn't know that the telecom stuff uses that, perhaps it's just forgotten debug stuff and should be removed.

Using PAMFD to display stuff, which cannot (or wasn't) be displayed on the panel, is my preferred solution, too, in fact I did the PAMFD for that in the first place, namely to display the GET during prelaunch.

Cheers
Tschachim
Logged

lassombra
Moderator
Sr. Member
****
Posts: 410


View Profile Email
« Reply #2 on: December 18, 2007, 03:05:36 PM »

well, as a test, I've made a member method in the Saturn that externally behaves just the same as oapiDebugString().  The method is called debugString, returns a char pointer to the beginning of an array, and allows reasonable length output.

Internally it is a dual function method (actually, it's not a method at all but a pointer).  If the MFD is activated, it points to a function in the MFD to write a debug line.  The MFD then provides additional functions such as "Freezing" the debug line so you can catch what it's saying if there's a lot of details.  It also allows you to clear the debug line.

When the MFD is not activated, it is set to point to the oapiDebugString() as normal, and prints to the debug string that the MFD wasn't activated.

I will go ahead and commit this, and then debug data should go to the MFD.  I moved all the debug data (not the error messages) from the Telecom to the MFD.  I don't think we have anymore debug strings right now, but if we get anymore, send them to the MFD instead of the bottom of the screen if you can reasonably do so.
Logged

My current Project Apollo work:

Quickstart to the Moon initiative (Quickstart_to_the_Moon): Done through earth orbit.  Working on new method of calculating TLI.

Checklist Controller: 
  • MFD Interface 99%(Minor cleanup and future features remain)
  • Panel Interface 99%
  • Excel interface and logic 99%
  • LEM Event code.0%
  • DSKY Interface code. Framework complete, creating "buttons"
  Approximately 80% done. (Checklist Controller
Pages: [1] 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!