Meadville Space Center
Welcome, Guest. Please login or register.
December 09, 2019, 05:22:17 PM

Login with username, password and session length
Search:     Advanced search
Welcome to the new Meadville Space Center forums!
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)
| | | |-+  CMC/LGC Restart
« previous next »
Pages: [1] Print
Author Topic: CMC/LGC Restart  (Read 1129 times)
abr35
Project Team Member
Full Member
****
Posts: 99


View Profile
« on: December 24, 2017, 03:15:41 PM »

In nearly every scenario I often get a hardware restart either when ending time acceleration or swapping panels. The restart will rarely reset the CMC clock, but will often change the computer from P00H to another seemingly random program (usually in the Pre-Thrusting groups of 30s or 70s). The hardware restart is accompanied by a program alarm lt, with no program alarm in the 05 09 display. Is this typical at this stage of NASSP 8? Haven't been keeping up to date with the IRC.
Logged
rcflyinghokie
Hero Member
*****
Posts: 580


View Profile Email
« Reply #1 on: December 24, 2017, 10:26:42 PM »

I have been out of the main repo branch for about a month now working on the LM ECS, but I do not recall this being an issue at all before hand nor have I heard anyone in IRC mention it.  Using the current NASSP build with the latest orbiter beta?
Logged
Thymo
Full Member
***
Posts: 113


View Profile WWW Email
« Reply #2 on: December 25, 2017, 07:36:37 AM »

I've never seen such an issue. Can you confirm you are up to date on everything? Latest v8 build from git and Orbiter2016 (either release or beta).

The AGC will not normally display the alarms (I think there are only a few rare occasions where it calls a prio disp). Could you check V05N09E for me as well as the restart monitor on channel 77 with V01N10E 77E? Also what rope does this happen on?
I'm quite surprised by the fact that you're saying that the AGC jumps to a random program. I can't see how that is even possible from a code standpoint, unless your erasable is corrupted in some ridiculous way.

(Also, this is my 100th post here. Time for a party?  Thumbs Up)
Logged
abr35
Project Team Member
Full Member
****
Posts: 99


View Profile
« Reply #3 on: December 25, 2017, 09:41:15 AM »

It is a few builds ago. Started flying Apollo 11 about 2 weeks ago so the most recent build as of 12/18. I updated and will see what happens. And I did check V05N09E, just abbreviated it as 05 09. All 3 registers show 00000. If I still have the issue I will post a scenario here.
Logged
thewonderidiot
Full Member
***
Posts: 48



View Profile
« Reply #4 on: December 25, 2017, 03:52:00 PM »

Yeah, sounds like something is broken -- hardware restarts generally wouldn't be accompanied by program alarm lights, especially without anything in FAILREG,+1,+2. But assuming things aren't fundamentally broken, for a RESTART light, though, the most useful information exists in channel 77, which as Thymo says can be read with V01N10E 77E. The erasable locations RSBBQ,+1 are also useful; those registers hold the BBANK and Q registers as they were at the time of the restart, so you can figure out exactly what code was running when the restart happened. You can display those with V04N01E 1432E in both Luminary 99 and Comanche 55.
Logged
abr35
Project Team Member
Full Member
****
Posts: 99


View Profile
« Reply #5 on: December 25, 2017, 03:59:14 PM »

Here is the scenario after a restart. This time there was an alarm code. The restart also happened when switching to an external view. This one happened by running the time acceleration up to 60x for a few seconds then back to 1x. Opening an external MFD prompt on the descent also lead to a restart.

There seems to be a link to the demand placed on the CPU and a hardware restart. I never had this problem before an early December build, and NASSP was the only thing upgraded in my Orbiter folder.

* LGC Restart.scn (231 KB - downloaded 88 times.)
Logged
rcflyinghokie
Hero Member
*****
Posts: 580


View Profile Email
« Reply #6 on: December 26, 2017, 09:23:13 AM »

This one happened by running the time acceleration up to 60x for a few seconds then back to 1x.

You had the AGC up with time accel at 60x?  That might have been the cause.  I always get instability running over 30x when in orbit and 50x when in trans lunar coast
Logged
Thymo
Full Member
***
Posts: 113


View Profile WWW Email
« Reply #7 on: December 26, 2017, 10:04:03 AM »

I looked around for a bit but couldn't find anything conclusive as to why this might have happened.

A restart was caused by both TC TRAP and RUPTLOCK (maybe also parity fail, not sure if I go that right).
Next to that the program alarms looked like garbage, nothing close to what's listed by the luminary operation information.

I ran the simulation up to 60x but didn't get a restart, nevertheless the sim lagged like crazy, that can cause restarts (it did for me on Apollo 7 a couple of time).
I'd recommend not going above 10x time acceleration (depending on your pc) when the AGC is operating. If you want to go higher you should put it in standby first.

Also tested the IRC logging a bit: https://vanbeersweb.nl/irclogs/%23nassp/2017-12-26-13%3A22_Untitled-meeting.html
Logged
abr35
Project Team Member
Full Member
****
Posts: 99


View Profile
« Reply #8 on: December 26, 2017, 01:41:45 PM »

It has happened on 1x, when switching panels or opening the Ctrl-F4 menus. This one has just happened to be on 60x because it is the most reproducible. The sim was smooth at 60x before the restart. Should I try and force those other errors as well? It can make NASSP almost unflyable - had the computer restart in the middle of P12 when I switched from the CDR side to LMP side of the LM.
Logged
Thymo
Full Member
***
Posts: 113


View Profile WWW Email
« Reply #9 on: December 26, 2017, 04:21:50 PM »

Is this happening in fresh scenarios too? I can imagine something in memory might be corrupted causing more issues, even at 1x.
Logged
abr35
Project Team Member
Full Member
****
Posts: 99


View Profile
« Reply #10 on: December 26, 2017, 05:41:12 PM »

It has happened with nearly every scenario that has been quicksaved or loaded from a current state. So it has not happened on a fresh scenario. But if I save that scenario and continue it later, the problem will eventually occur. Make sense?
Logged
indy91
Hero Member
*****
Posts: 1316


View Profile
« Reply #11 on: December 27, 2017, 05:25:05 AM »

Sounds a lot like a scenario saving/loading issue. Which is totally possible considering we've been adding quite a few new systems. I'll check if I find anything obviously wrong with the saving/loading code.
Logged
Thymo
Full Member
***
Posts: 113


View Profile WWW Email
« Reply #12 on: January 03, 2018, 02:15:54 PM »

I managed to reproduce this today. I accidentally switched to 100x time acceleration and got a computer restart.
The DSKY was completely unresponsive. I only managed to get a key release and activity light. Had to do a fresh start to get it working again.

After checking out the restart monitor I had both a fixed parity fail and a TC TRAP.
I'm starting to think this might be related to the new ropes with parity bits included that were added a while back.
Logged
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!