Meadville Space Center
Welcome, Guest. Please login or register.
December 12, 2019, 05:44:30 PM

Login with username, password and session length
Search:     Advanced search
Project Apollo Beta 7.0 released!
http://nassp.sf.net/wiki/Installation
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 News & Discussion
| | |-+  Support & Bugs (Moderators: movieman, Tschachim, Swatch, lassombra)
| | | |-+  Apollo 7 Beta Testing Bugs
« previous next »
Pages: 1 [2] 3 4 ... 7 Print
Author Topic: Apollo 7 Beta Testing Bugs  (Read 11042 times)
indy91
Hero Member
*****
Posts: 1316


View Profile
« Reply #15 on: November 11, 2016, 08:12:50 AM »

I can cause a CTD on this line by generating lots of MCC calculations, which are then displaying too many messages. I haven't ever really looked at this part of the MCC, but it seems to me there is a limited number of messages that can be displayed and if more messages are written than that to the character array, a CTD happens. This doesn't involve the PAD, just the messages displayed to the top and right of the PADs.
Logged
rcflyinghokie
Hero Member
*****
Posts: 580


View Profile Email
« Reply #16 on: November 12, 2016, 09:27:08 AM »

So its weird, I can get a CTD on a thread update, but I can reload my quicksave prior and no CTD.  I cannot seem to get anything consistent.

But some other notes on 7 (which probably trickle over to any checklist MFD)

-EDS breakers not opened after SIVB sep
-SIVB LM SEP breakers are closed, I know these arent even used but should these be opened before launch for A7 or at the very least opened after SIVB SEP?
-SPS P&Y BAT breakers only two (BAT A) are opened after the burn instead of all four.
- Was the SCS TVC kept on RATE versus AUTO for A7 SPS burns?  The checklist keeps them on rate before the TVC tests but never moves them to auto.


I am only at 27 hours but I will keep an eye out for more Happy
Logged
indy91
Hero Member
*****
Posts: 1316


View Profile
« Reply #17 on: November 12, 2016, 12:11:48 PM »

So its weird, I can get a CTD on a thread update, but I can reload my quicksave prior and no CTD.  I cannot seem to get anything consistent.

Maybe it is the too many messages thing I mentioned above. Dseagrav has to take a look at that, I don't really know how it works...

Quote
-EDS breakers not opened after SIVB sep

Yes, those should probably be opened.

Quote
-SIVB LM SEP breakers are closed, I know these arent even used but should these be opened before launch for A7 or at the very least opened after SIVB SEP?

Yes, they should be open after S-IVB sep. If it isn't implemented, I will look into doing that. The breakers were closed for launch.

Quote
-SPS P&Y BAT breakers only two (BAT A) are opened after the burn instead of all four.

Nominal P40 checklist has only two opened after the burn. You will open all four only after the last SPS maneuver (deorbit).

Quote
- Was the SCS TVC kept on RATE versus AUTO for A7 SPS burns?  The checklist keeps them on rate before the TVC tests but never moves them to auto.

For Apollo 7 it depends. Usually it would be in RATE during a AGC controlled burn. If you really need to take over control with the SCS you might have a high attitude rate and attitude excursion, you probably want to first bring the spacecraft under control before giving the SCS auto control. If you notice something is wrong with the CMC BEFORE the burn has begun, then the P40 checklist sets it to auto.

There are two nominally SCS controlled burns during Apollo 7 and they have a separate checklist in the MFD with the switch to Auto. There is also a MTVC takeover planned, where it is set to RATE CMD and you will have to control the TVC manually.
Logged
indy91
Hero Member
*****
Posts: 1316


View Profile
« Reply #18 on: November 14, 2016, 07:43:00 AM »

RCS Logic, SIVB/LM Sep and EDS circuit breakers are now opened in the Checklist MFD after separation. The SIVB/LM circuit breakers were already properly implemented before. I have also commited a few RTCC fixes, although these issues can't have caused the CTDs rcflyinghokie experienced.
Logged
rcflyinghokie
Hero Member
*****
Posts: 580


View Profile Email
« Reply #19 on: November 15, 2016, 09:27:50 PM »

RCS Logic, SIVB/LM Sep and EDS circuit breakers are now opened in the Checklist MFD after separation. The SIVB/LM circuit breakers were already properly implemented before. I have also commited a few RTCC fixes, although these issues can't have caused the CTDs rcflyinghokie experienced.

I am still getting them in later MCC updates post rendezvous.  Is there anything I can do to try to pinpoint these?

Tried re-saving rebuilding everything cannot get past the 44h SV update.

* Apollo 7 Virtual AGC LVDC++ MCC - 44h SV Update.scn (107.4 KB - downloaded 73 times.)
« Last Edit: November 15, 2016, 10:04:38 PM by rcflyinghokie » Logged
dseagrav
Project Admin
Hero Member
*****
Posts: 1118


View Profile
« Reply #20 on: November 16, 2016, 04:46:25 AM »

Did the size of something change in a way that makes the malloc (or whatever) come up short, or is it writing past the end of the buffer?
Logged
indy91
Hero Member
*****
Posts: 1316


View Profile
« Reply #21 on: November 16, 2016, 06:53:46 AM »

I am still getting them in later MCC updates post rendezvous.  Is there anything I can do to try to pinpoint these?

Tried re-saving rebuilding everything cannot get past the 44h SV update.

I am getting the CTD at 44 hours, too, with your scenario. That one might be a PAD saving/loading issue.

EDIT: The exception is in the line

Code:
oapiAnnotationSetText(NHpad, buffer);

while writing the the buffer containing the Nav Check PAD in the Orbiter annotation.

EDIT2: Ok, I am pretty convinced now that all the new MCC problems are caused by the recently implemented PAD saving/loading. I'll try to find the problem.

EDIT3: Looks like it might only be the loading of the uplink string that is causing the problems. That would be much easier to solve than the PADs.

EDIT4: That uplink shouldn't be saved anyway, it doesn't belong to the saved Block Data.

EDIT5: It goes a little bit deeper than that. I am working on it but it will take time.
« Last Edit: November 17, 2016, 08:35:22 AM by indy91 » Logged
indy91
Hero Member
*****
Posts: 1316


View Profile
« Reply #22 on: November 17, 2016, 09:45:41 AM »

Ok, this is the problem. When I decided how to save PAD data in a scenario I had two option: save the string containg the PAD or save all the variables separately. The first option would have required the MCC to be reworked quite a bit, so I chose the second option. But I accidentally left some code in the MCC for the first option, namely a PADbuffer:

Code:
//Save PAD string
sprintf(padBuffer, buffer);

This had severe side effects, for some reason I don't fully understand. Probably the nature of the PAD string with several lines of characters. Here an excerpt of the MCC class declaration:

Code:
char padBuffer[512];
 
// UPLINK DATA
int uplink_size; // Size of uplink buffer
unsigned char uplink_data[1024]; // Uplink buffer

// CAPCOM INTERFACE
NOTEHANDLE NHmenu; // Menu notification handle
NOTEHANDLE NHmessages; // Message notification handle
NOTEHANDLE NHpad; // PAD display handle
int menuState; // Menu state

The string written to padBuffer also overwrote a few following variables, mostly the uplink stuff, but it also could break the NOTEHANDLEs I think.

I guess I have some reading about sprintf to do, but the fix is easy, remove the obsolete code. In my quest for finding this issue I also reworked some other parts of the MCC, so as always there is potential for new bugs.
« Last Edit: November 17, 2016, 09:58:00 AM by indy91 » Logged
rcflyinghokie
Hero Member
*****
Posts: 580


View Profile Email
« Reply #23 on: November 17, 2016, 12:29:35 PM »

I guess I have some reading about sprintf to do, but the fix is easy, remove the obsolete code. In my quest for finding this issue I also reworked some other parts of the MCC, so as always there is potential for new bugs.

Should this have fixed the CTD in the scn file I posted?  Because I am still getting it.
Logged
indy91
Hero Member
*****
Posts: 1316


View Profile
« Reply #24 on: November 17, 2016, 12:39:44 PM »

Should this have fixed the CTD in the scn file I posted?  Because I am still getting it.

I forgot to test it with the original scenario you posted. You have to delete the MCC_upString line in the scenario. It shouldn't have been saved and it doesn't belong to the saved Block Data.

That said, I think there still is a bug similar to the one I explained above. Expect more bug fixes soon...

EDIT: Ok, the additional problem is the variable uplink_size. If an uplink string isn't actually uplinked, then this doesn't get reset to 0 again. The next uplink string simply gets added to this variable and at the second or third uplink the size will exceed 1024, which is the maximum. And exceeding the maximum again overwrites the next variables in the MCC class, which are the NOTEHANDLEs for PADs, messages etc. This is what happens when an uplink saved in a scenario doesn't get uplinked and you simply proceed to the next RTCC calculation. That's also what causes CTDs when you use the debug menu to skip several mission states without uplinking anything.

I think it is safe to reset the uplink size to 0 when a new RTCC calculation is triggered. If you proceed to the next mission state as usual, then the old uplink string isn't relevant anymore. And if you repeat a calculation, then a new uplink gets calculated anyway. With this change you can now also use the debug menu to quickly go through mission states with uplinks, without CTDs.
« Last Edit: November 17, 2016, 01:18:01 PM by indy91 » Logged
dseagrav
Project Admin
Hero Member
*****
Posts: 1118


View Profile
« Reply #25 on: November 17, 2016, 02:54:25 PM »

IIRC that was used to keep track of where we were in sending bytes to the computer, which lets you batch uplinks together and transmit them in one go. (This was done in real life).
It should be reset to zero when the last byte is given to the computer. Resetting it with new states just means the uplinks never happen or get cut off in the middle.
Logged
indy91
Hero Member
*****
Posts: 1316


View Profile
« Reply #26 on: November 17, 2016, 03:25:58 PM »

The uplinks are already batched together in our RTCC. Some of the uplinks are very long, so if you collect strings in the MCC that haven't been uplinked yet, it quickly violates the 1024 character limit. I tried to increase this limit, but it crashed again and I think 1024 is also used somewhere in the PCM. Even the longest single uplinks (e.g. 2 state vectors + REFSMMAT) don't violate the 1024 characters, but if you have 2x2 state vectors then it becomes a problem.

I haven't changed that "uplink_size" gets reset to zero after the last byte is given to the computer. It just also gets reset now at the beginning of a new state.

Do you have a better idea where to reset it to zero if not at the beginning of a new state? The variable "upString" is also reset there. And I don't think that RTCC and MCC both need to have the capability to batch uplinks. If the MCC doesn't do it, then you could skip uplinks. Before my commit today, you were forced to do an uplink or else you get the CTD. I'd rather have the ability to use the debug menu to quickly advance through mission states.
Logged
dseagrav
Project Admin
Hero Member
*****
Posts: 1118


View Profile
« Reply #27 on: November 17, 2016, 03:56:35 PM »

It's fine as long as at least one or the other can do it. If RTCC already does it better then there's no need for MCC to do it. After we move to 2016 there will be a lot of chances to clean up and we can drop it as unneeded extra complexity then.
Logged
rcflyinghokie
Hero Member
*****
Posts: 580


View Profile Email
« Reply #28 on: November 20, 2016, 09:33:35 AM »

This is not really a bug but perhaps a lack of information issue (or just my ignorance since this is my first complete run through Apollo 7  Embarassed.  For the P22 sets around 122 hours, the checklist MFD says use previously computed landmark coordinates.  Where does the user get this information for the P22?  And are these landmarks modeled marked in orbiter right now?  

EDIT:  Too add, where does the user get the P23 star information to use right after the P22's?
« Last Edit: November 20, 2016, 09:50:43 AM by rcflyinghokie » Logged
indy91
Hero Member
*****
Posts: 1316


View Profile
« Reply #29 on: November 20, 2016, 10:30:52 AM »

The word flight plan has the P23 stars and the update forms document has the P22 landmarks, already converted to the coordinates required for the AGC Earth ellipsoid calculations. These landmarks are not the ones used during the historical Apollo 7 flight, because we don't have a source with a complete lists of the Apollo landmarks. I might be able to come up with a better list of landmarks for P22, but for now the ones in the update forms document should be good enough. Just like star markings you can display lots of landmarks on the Earth. I think these already come with Orbiter and not NASSP.
Logged
Pages: 1 [2] 3 4 ... 7 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!