MPS development

[SiameseCat]

At the moment I'm trying to turn the lights on after SSME shutdown, but that's all I'm doing. I can check in the code for the lights alone and let you add the logic, if it's already done.

 

[SiameseCat]

Checked in MPS lights code.
The lights are connected to the discrete bundle "MPS_STATUS_LIGHTS" (see the Realize function in vc/PanelF7.cpp).

The EIU switches and Limits switches should be coming in a day or two.

 

[Urwumpe]

In "teh real thing" the MPS status lights would be connected to the GPC via one of the forward MDMs, but I can't yet say which. Only very few lights or switches in the Shuttle are directly connected to a subsystem or the GPCs, most are handled by the MDMs or the primary C&W subsystem.

 

[GLS]

Uploaded a new class to run the engine status lights and fixed a couple of bugs as well (please someone add the new files to the VS2010 project <- thanks!)

 

[SiameseCat]

Updated the VS2010 project.

 

[SiameseCat]

Checked in the C3 SSME Limit switch and the O17 panel with the EIU power switches.

I've connected the Limits switch to the "LIMITS" bundle (this is just a placeholder; feel free to change this). If the Limits switch is in either the INHIBIT or the ENABLE position, a discrete signal will be set. If the Limits switch is in AUTO, there won't be any discrete ports set.

I haven't connected the EIU switches to anything. As I understand it, these switches act like circuit breakers and directly control the power supplied to the EIUs, so I don't think it's appropriate to use the normal discsignals classes.

 

[DaveS]

Checked in the C3 SSME Limit switch and the O17 panel with the EIU power switches.

I've connected the Limits switch to the "LIMITS" bundle (this is just a placeholder; feel free to change this). If the Limits switch is in either the INHIBIT or the ENABLE position, a discrete signal will be set. If the Limits switch is in AUTO, there won't be any discrete ports set.

I haven't connected the EIU switches to anything. As I understand it, these switches act like circuit breakers and directly control the power supplied to the EIUs, so I don't think it's appropriate to use the normal discsignals classes.

How close are we to have the related terminal count events implemented along with post-MECO SSME stowing?

 

[GLS]

Checked in the C3 SSME Limit switch and the O17 panel with the EIU power switches.

Thanks!

I've connected the Limits switch to the "LIMITS" bundle (this is just a placeholder; feel free to change this). If the Limits switch is in either the INHIBIT or the ENABLE position, a discrete signal will be set. If the Limits switch is in AUTO, there won't be any discrete ports set.

No problem. It's going to take sometime to use this one because what this switch does is inhibit action upon a redline being violated, and I still haven't done the redlines so....

I haven't connected the EIU switches to anything. As I understand it, these switches act like circuit breakers and directly control the power supplied to the EIUs, so I don't think it's appropriate to use the normal discsignals classes.

I think you are right, but until there's an EPS the discsignals will have to do the job.
So I connect the thing and it doesn't work :idk:. It looks like initially the switches have the output 0 (with or without a O17 panel block in the scenario file), and it isn't until I cycle the switch position that it starts working.

 

[SiameseCat]

Can you post PanelO17.cpp after the switches are connected? Also, make sure you call AtlantisPanel::Realize() at the end of PanelO17::Realize() (after all the discsignals have been connected).

 

[GLS]

make sure you call AtlantisPanel::Realize() at the end of PanelO17::Realize()

Like they would say in Mythbusters "Well, there's your problem" :lol:
That fix it, thanks very much! I'm doing some more things now so I'll upload it all later.

 

[GLS]

Just uploaded some new code. You can now "simulate" a data/cmd path failure by killing an EIU using the new switches on panel O17 (2 switches off -> 1 EIU dead). That means you can now simulate an engine with a stuck throttle if you stop the EIU in the throttle bucket. It also means you have to shutdown that engine manually prior to MECO using the R2 switches, because the GPCs can't talk to it. I think that it's done at around 23Kfps, some 30s prior to MECO.
If you power off one EIU after SSME ignition but before T0, the RSLS will only be able shutdown the 2 "good" engines, the other one is your responsability .
Now, I'm sure the 2 AC channels that power each EIU power different things inside it, but I don't know what, so for now just flipping one switch on O17 won't do nothing - you need 2. Another thing is that the logic behind the cmd/path path failure is still a little fuzzy, so I don't know what should happen if you cycle a switch... :shrug:

 

[DaveS]

If you power off one EIU after SSME ignition but before T0, the RSLS will only be able shutdown the 2 "good" engines, the other one is your responsability .

Nice! So the SSU RSLS code now actually looks at the SSME status and performs an abort if everything is not right? In that case, I think the SSU GLS needs to enhanced to auto-extend the OAA afterwards. This happens every time a GLS cut-off is issued after T-5 minutes.

 

[GLS]

So the SSU RSLS code now actually looks at the SSME status and performs an abort if everything is not right?

Errmmm, no . The abort guidance is still missing, and also it needs to recognize that there's an engine out...
EDIT: If you are refering to pre-launch, then yes it aborts. But the failure has to be caused by the user as it doesn't do random/planned failures (yet).

I think the SSU GLS needs to enhanced to auto-extend the OAA afterwards. This happens every time a GLS cut-off is issued after T-5 minutes.

There is a need for a LCC with some of the goodies like GLS and some consoles. That would allow to simulate the countdown from an earlier point (don't know how many people would like simulate the countdown for hours, only to abort the thing minutes before T0 :lol. On the SSMEs I have already some logic to process commands that are exclusive to the LCC consoles, that bring the controllers from a power on state to a pre-launch state. But I think the LCC/shuttle interface needs to be debated very well as to how much should be manual vs automatic. And then there's also the problem of knowing how things work...

 

[STS]

(don't know how many people would like simulate the countdown for hours, only to abort the thing minutes before T0 :lol.

Me :thumbup:

 

[DaveS]

(don't know how many people would like simulate the countdown for hours, only to abort the thing minutes before T0 :lol.

There's a name for that: S0014 Flight Readiness Firing
It's used to verify and certify the MPS for flight. Everything is done just like a real S0007 Launch Countdown except for Flight Crew ingress/strap-in and the T0 events like SRB ignition/HDP release and TSM/GH2 vent line retract.

Everything else is done just like a real S0007.