Space Shuttle Ultra 4.0 PRESS TO MECO

[Urwumpe]

For finishing the final release of SSU for Orbiter 2010P1, the following development tasks have to be finished.

# | Task | Description | Status
90|Speedbrake/throttle PBIs not toggable|| DONE
102|Real RCS|Final fixes for Real RCS implementation|TODO
120|ODS Attachment|Update the ODS attachment behavior| DONE
146|CISS G animations|Implement the animations for the Centaur G CISS|TODO
147|CISS piping bellows|Implement the animations for the piping bellows|TODO

Once these four missing tickets are implemented, 4.0 can go into testing for release.

Please reply in this thread only if you are developing SSU and working to finish the features. Use the general development discussion for questions.

 

[GLS]

Quick question about the (real)RCS: we're only doing this to get the thruster particle streams in the correct directions, right?

I could try to do the ODS ticket, but currently I am doing some "maintenance work" on my HD, so is it OK to wait maybe a day or two, or it needs to be done ASAP?

Also, I see ticket 147 was sent to the graphics department... wasn't that supposed to be done by moving vertices in the sw or something?

 

[Urwumpe]

Quick question about the (real)RCS: we're only doing this to get the thruster particle streams in the correct directions, right?

I could try to do the ODS ticket, but currently I am doing some "maintenance work" on my HD, so is it OK to wait maybe a day or two, or it needs to be done ASAP?

Also, I see ticket 147 was sent to the graphics department... wasn't that supposed to be done by moving vertices in the sw or something?

Yes, approximately. I think we also wanted to have it done in preparation to have properly working vernier thrusters.

No problem with the timing, I am also pretty sure, I won't be doing much coding before the weekend.

 

[GLS]

Yes, approximately. I think we also wanted to have it done in preparation to have properly working vernier thrusters.

Yes, each thruster should exist individually so the DAP logic can choose which ones to fire.
A propper "real RCS" is still +/- far away IMO, as it will need changes to the DAPs, sw in the GPCs to centralize fire commands, adding the RJDs and panel switches, and getting rid of the "enable RCS" and "disable RCS" functions in Atlantis (the thrusters should always be there, if they are used or not, is up to the GPCs).

 

[Urwumpe]

Yes, each thruster should exist individually so the DAP logic can choose which ones to fire.
A propper "real RCS" is still +/- far away IMO, as it will need changes to the DAPs, sw in the GPCs to centralize fire commands, adding the RJDs and panel switches, and getting rid of the "enable RCS" and "disable RCS" functions in Atlantis (the thrusters should always be there, if they are used or not, is up to the GPCs).

Of course. We would also need proper propellant handling there. It was a first step towards it. We also need individual thruster classes to handle the non-orbiter aspects of them.

 

[DaveS]

What about ticket# 90? That one is listed as belonging to 3.0 so it's overdue for a fix.

---------- Post added at 12:34 AM ---------- Previous post was at 12:29 AM ----------

Also, I see ticket 147 was sent to the graphics department... wasn't that supposed to be done by moving vertices in the sw or something?

Graphics department completed its task and checked the work in. It has been waiting for the coding department to bring it over the finish line. And this was the discussion: http://www.orbiter-forum.com/showthread.php?p=532680&postcount=510

 

[Urwumpe]

What about ticket# 90? That one is listed as belonging to 3.0 so it's overdue for a fix.

Moved it to 4.0 for analysis.

 

[GLS]

The PBIs are wrong IMO. The light depends on the push button or vice-versa, at the PB level, and it should be fully independent so it can be controlled from the GPCs. I say keep as is until the new GPCs arrive, then change/add the sw needed so that vc component can be corrected.
For this particular case, looking at the SCOM I see that the SPD BK/THROT PBI is only used to set AUTO mode, and MAN is set by moving the SBTC, so it seems like it's not really a bug.

---------- Post added at 11:40 PM ---------- Previous post was at 12:14 AM ----------

Started looking at the ODS and its panel, and I have this "burning" question: where did the "A3" in the panel name "A7A3/A8A3" come from????

 

[DaveS]

The PBIs are wrong IMO. The light depends on the push button or vice-versa, at the PB level, and it should be fully independent so it can be controlled from the GPCs. I say keep as is until the new GPCs arrive, then change/add the sw needed so that vc component can be corrected.
For this particular case, looking at the SCOM I see that the SPD BK/THROT PBI is only used to set AUTO mode, and MAN is set by moving the SBTC, so it seems like it's not really a bug.

---------- Post added at 11:40 PM ---------- Previous post was at 12:14 AM ----------

Started looking at the ODS and its panel, and I have this "burning" question: where did the "A3" in the panel name "A7A3/A8A3" come from????

I have no idea. Donamy, maybe you could answer this?

 

[Urwumpe]

I have no idea. Donamy, maybe you could answer this?

I think I am responsible for it.

A7A3 is the "Loc Code 21002" location coding for:

A7 panel, Installation code 3.

Also used is A7L for the same panel.

I think it was my suggestion back then to use the names.

 

[GLS]

I think I am responsible for it.

A7A3 is the "Loc Code 21002" location coding for:

A7 panel, Installation code 3.

Also used is A7L for the same panel.

I think it was my suggestion back then to use the names.

Yes you are :lol:, I just went to the log and when the panel code first appeared back in 2008 it already had the "A8A3" name.

---------- Post added at 02:02 PM ---------- Previous post was at 12:00 AM ----------

I was trying to get some "easy" ODS panel lights to work, and noticed that their initial state wasn't correct until I turned the switch off and back on. After debugging I found that the value at the exit of the discrete bundle where the switch is connected to didn't match the switch position. More debugging and the problem is not at the switch level, as other similar switches work at the start of the sim. Finally I tried moving the AtlantisPanel::Realize() call from the begining to the end of PanelA7A8ODS::Realize(), and that did it.
So the problem seems to be that when a discrete port is being connected to the bundle, it doesn't set its current value to the bundle. With the AtlantisPanel::Realize() being made before the switches are connected to the bundles, the ports at the switches never got their state into the bundle, not until they changed. I see 2 possible fixes for this: (1) check that every panel has the AtlantisPanel::Realize() call at the end, or (2) change the DiscOutPort so that when it is connected to a bundle it sets the current value in the bundle (this one would prevent similar issues in other places).

 

[Urwumpe]

I see 2 possible fixes for this: (1) check that every panel has the AtlantisPanel::Realize() call at the end, or (2) change the DiscOutPort so that when it is connected to a bundle it sets the current value in the bundle (this one would prevent similar issues in other places).

What about fixing both.

(1) is annoying. Maybe a skeleton method design pattern would be a better solution there than a mandatory call to the super class. Like AtlantisPanel provides some empty methods to override, for example "realizeInternalBundles()", which are then always executed before calling Realize().

(2) makes absolutely sense and should be implemented

 

[GLS]

What about fixing both.

(1) is annoying. Maybe a skeleton method design pattern would be a better solution there than a mandatory call to the super class. Like AtlantisPanel provides some empty methods to override, for example "realizeInternalBundles()", which are then always executed before calling Realize().

(2) makes absolutely sense and should be implemented

(1) for now I'll just enforce the "AtlantisPanel::Realize() call must be at the end" rule
(2) will do

---------- Post added at 09:30 PM ---------- Previous post was at 02:21 PM ----------

This really makes me want to delay this ODS update until after the vc update. As some might now, the early ODS missions to Mir had the "(Russian) APDS control" panel installed on panel A8 slot instead of the A7 slot and the "Docking System Power" panel was on panel A7 slot instead of the A6 slot. Our current config has the Russian panel on panel A7 slot (but the code uses constants named "A8A3" :uhh, and both panels are in the same mesh file, so this is not really optimum ATM. I'd like to have both panels in separate mesh files (easy, I could do it), and having the capability to choose which of the 2 configs are used (I also could do it, but it's not so easy or fast).

This panel work has to (and will) be done, but doing it right now, I think it would not have a positive impact on the release date (weeks/months?). To add the attachment stuff and not improve the logic, which needs the switches that shoud then be in the correct block in the scenario file, is not really a good idea IMO.

About the panel name scheme, I don't really care what standard is followed, but it should be consistent for all panels, and should allow this case of the ODS panels having the choice of placement.

 

[DaveS]

[/COLOR]This really makes me want to delay this ODS update until after the vc update. As some might now, the early ODS missions to Mir had the "(Russian) APDS control" panel installed on panel A8 slot instead of the A7 slot and the "Docking System Power" panel was on panel A7 slot instead of the A6 slot. Our current config has the Russian panel on panel A7 slot (but the code uses constants named "A8A3" :uhh, and both panels are in the same mesh file, so this is not really optimum ATM. I'd like to have both panels in separate mesh files (easy, I could do it), and having the capability to choose which of the 2 configs are used (I also could do it, but it's not so easy or fast).

This panel work has to (and will) be done, but doing it right now, I think it would not have a positive impact on the release date (weeks/months?). To add the attachment stuff and not improve the logic, which needs the switches that shoud then be in the correct block in the scenario file, is not really a good idea IMO.

About the panel name scheme, I don't really care what standard is followed, but it should be consistent for all panels, and should allow this case of the ODS panels having the choice of placement.

I would vote for going ahead with the logic improvements as we really don't have any missions for the 90's. Right now what we do have is good support for the 2000's as that's when the MEDS was introduced (May 2000 for OV-104, March 2002 for OV-102, July 2005 for OV-103 and August 2007 for OV-105). Not only the panel layout changed for the ODS but also the ODS itself. Originally it used an orange thermal cover for the ball screw assemblies which was changed to a white thermal cover for the ISS missions. I'm pretty certain there were other changes as well but that was the most visible one.

 

[GLS]

Any idea how the panels were switched to the DM (STS-74) and PMA-1 (STS-88) ports to control the 2º docking on those missions?

 

[DaveS]

Any idea how the panels were switched to the DM (STS-74) and PMA-1 (STS-88) ports to control the 2º docking on those missions?

In the Procurement Specification for the APDS for the ISS Missions document, I found this. Although it's for the hypothetical ICM mission, I think it's applicable to both the DM and PMA-1. It mentions a APDS Switching System. The APDS Switching System can be found in the same document on document page 522, Appendix XIV.

---------- Post added at 03:21 AM ---------- Previous post was at 02:21 AM ----------

This brings up an important question, which is how we should deal with the DM and PMA-1 APDS units. Technically they don't belong to the shuttle so how are going to handle them?

 

[Urwumpe]

This brings up an important question, which is how we should deal with the DM and PMA-1 APDS units. Technically they don't belong to the shuttle so how are going to handle them?

What do you mean with handle?

Which functional requirements do we get that way?

Anyway, I see this as a problem for a version 5.0 or later, not for the final 2010P1 release.

 

[DaveS]

What do you mean with handle?

Which functional requirements do we get that way?

Anyway, I see this as a problem for a version 5.0 or later, not for the final 2010P1 release.

The whole PMA-1/FGB and DM/Mir docking sequence is controlled from the orbiter, with the extension/retraction of the APAS docking ring and the opening/closing of the hooks. Both PMA-1 and the DM were equipped with active APAS'es. PMA-2 and PMA-3 are only equipped with the passive APAS.

 

[Urwumpe]

The whole PMA-1/FGB and DM/Mir docking sequence is controlled from the orbiter, with the extension/retraction of the APAS docking ring and the opening/closing of the hooks.

Yes, that should be the case anyway, the ODS is no CBM (which makes the space station the active spacecraft). But what is significantly different to the current specification in SSU?

 

[DaveS]

Yes, that should be the case anyway, the ODS is no CBM (which makes the space station the active spacecraft). But what is significantly different to the current specification in SSU?

None really. This was to answer GLS's question how the DM/PMA-1 APAS was controlled:

Any idea how the panels were switched to the DM (STS-74) and PMA-1 (STS-88) ports to control the 2º docking on those missions?