MPS development

[GLS]

Must not be divided, they could also be read by each channel.

The thing is that the phrase says "within the controller", and the controller has 2 independent & equal IEs, one for each channel... so half of those bridges should be in chA and the other half in chB. I'm lost...

 

[Urwumpe]

The thing is that the phrase says "within the controller", and the controller has 2 independent & equal IEs, one for each channel... so half of those bridges should be in chA and the other half in chB. I'm lost...

You could also have all 17 temperature sensors be read by both channels. You only need a clear separation between the channels for things that you command.

 

[GLS]

You could also have all 17 temperature sensors be read by both channels. You only need a clear separation between the channels for things that you command.

I don't think that's the way it works... chA IE gets chA sensors, and chB sensors go to chB IE.... but then it doesn't "connect" with that phrase....

 

[Urwumpe]

I don't think that's the way it works... chA IE gets chA sensors, and chB sensors go to chB IE.... but then it doesn't "connect" with that phrase....

Aren't the temperature strips located through out the engine? And isn't usually only one channel commanding and the other in hot standby?

 

[GLS]

Aren't the temperature strips located through out the engine? And isn't usually only one channel commanding and the other in hot standby?

The "temperature bridge" is where the sensor connects in the IE, so a measurement can be made. It's a resistor bridge and the sensor is a leg of it, but that's not really the point here. Most (or maybe all - still not sure) sensor measurements are duplicate (chA & chB), and the IE on chA gets the "chA sensors", and then "chB sensors" go to chB IE... yada yada yada
Both IEs shoot the data into the memory of the controlling channel, so the controlling channel has both chA and chB sensor data. I think they also send the data into the standby channel, because the thing is also working, it just doesn't output.
And then I have this number, "17 within the controller", and actually I found 16 temps (8 per ch), so I'm just missing one, which I'm guessing is controller temp. That must exist because there are switches on the flight deck to control heaters. If this is the last temp sensor, where does it connect??? Both IEs are equal....

I feel like I'm making omelets without eggs

 

[DaveS]

Honestly - I think we should drop this for now. It makes no sense to me, to add a visual feature, that has to be "tolerated" for most of the time it is visible.

maybe a new version of Orbiter, or a different renderer, will make such things possible.

Sorry to bump such an old subject back to life. Something I have noticed is that the SSME exhaust isn't really static except for the Mach diamond. The rest is a really condensation cloud which could be simulated with a regular PSTREAM with appropriately calibrated ATM parameters so it cuts out at the correct altitude. This should make things look better.

 

[GLS]

Hi there!
So, after a long time of on-and-off development I think I have something that is going (more or less) in the right direction regarding the SSMEs.
It's not perfect, it's not particularly efficient and certainly not final, but right now I just want to create the skeleton of the thing and make it do something. Then I'll change and improve things as I get more data and I understand how things work. This is too complex and I don't know nearly enough to try and make a final version strait from the start.
But before I upload the code I have some problems that need to be addressed:
(1) The scenario and mission files. Somewhere there needs to be a definition of the version of the engine, the version of the controller and the version of the software that is going to run. And that needs to come before the subsystems start reading the scenario file, so that the classes also get to load their states. I tested putting those defs in the mission file and only creating the SSMEs after the mission file is read, and it worked (also had to move the RealizeSubsystemConnections call). But that is dependant on the mission file existing...
(2) There is also the problem of talking/listening to the engines. First I need some pointers about the BusController and associated classes that are going to be talking to the EIUs. Also what exactly are the EIUs going to be receiving? I have created some command tables to be read by the controller but is 100% made up... Then come the GPCs. I found some diagrams explaining (more or less) what is done in the SSME SOP, so I think I could write it, but I know nothing about the GPCs as they stand right now.

 

[SiameseCat]

Hi there!
So, after a long time of on-and-off development I think I have something that is going (more or less) in the right direction regarding the SSMEs.
It's not perfect, it's not particularly efficient and certainly not final, but right now I just want to create the skeleton of the thing and make it do something. Then I'll change and improve things as I get more data and I understand how things work. This is too complex and I don't know nearly enough to try and make a final version strait from the start.
But before I upload the code I have some problems that need to be addressed:
(1) The scenario and mission files. Somewhere there needs to be a definition of the version of the engine, the version of the controller and the version of the software that is going to run. And that needs to come before the subsystems start reading the scenario file, so that the classes also get to load their states. I tested putting those defs in the mission file and only creating the SSMEs after the mission file is read, and it worked (also had to move the RealizeSubsystemConnections call). But that is dependant on the mission file existing...
(2) There is also the problem of talking/listening to the engines. First I need some pointers about the BusController and associated classes that are going to be talking to the EIUs. Also what exactly are the EIUs going to be receiving? I have created some command tables to be read by the controller but is 100% made up... Then come the GPCs. I found some diagrams explaining (more or less) what is done in the SSME SOP, so I think I could write it, but I know nothing about the GPCs as they stand right now.

1) If a mission file is not specified in the scenario, a 'default' mission file will be used instead. The Mission class has a SetDefaultValues() function which sets the default values.
2) The current GPC code used is based around the SimpleGPCSystem/SimpleGPCSoftware classes. If you want to look at the ascent autopilot, look at the AscentGuidance class. The SSME SOP would probably be a separate SimpleGPCSoftware-derived class, and the AscentGuidance code would call some function in it to set the gimbal angles and thrust level.

 

[GLS]

1) If a mission file is not specified in the scenario, a 'default' mission file will be used instead. The Mission class has a SetDefaultValues() function which sets the default values.

But when would the engines be created then? Would the engines be created first with the default settings, and then if the mission file exists they would be deleted and created again with the new settings?
Wouldn't it be easier to enforce certaint things (mission file, some state parameters in the scenario file)?
I'm thinking of having some "default" states saved in the documentation (T-6h, T-3h, T-9m, etc) and then who wants to make a new scenario goes there and copies the appropriate part to the scenario. Just my 2 cents...

2) The current GPC code used is based around the SimpleGPCSystem/SimpleGPCSoftware classes. If you want to look at the ascent autopilot, look at the AscentGuidance class. The SSME SOP would probably be a separate SimpleGPCSoftware-derived class, and the AscentGuidance code would call some function in it to set the gimbal angles and thrust level.

I'll take a look at those.

 

[SiameseCat]

But when would the engines be created then? Would the engines be created first with the default settings, and then if the mission file exists they would be deleted and created again with the new settings?
Wouldn't it be easier to enforce certaint things (mission file, some state parameters in the scenario file)?
I'm thinking of having some "default" states saved in the documentation (T-6h, T-3h, T-9m, etc) and then who wants to make a new scenario goes there and copies the appropriate part to the scenario. Just my 2 cents...

The problem with enforcing a mission file is that it will break a lot of existing scenarios. I think an alternate solution would be to load the mission file (either the default values or whichever file was specified) before any of the substems/panel states are read from the scenario file. This isn't done at the moment, but it should be a simple change. The subsystem/panel values are the last things written to the scenario file, so there shouldn't be any problems loading the mission file first.

---------- Post added at 09:42 AM ---------- Previous post was at 09:38 AM ----------

BTW, how different are the different SSME versions? I would have thought an enum indicating the SSME model would be easier than creating a different class for each different model.

 

[GLS]

The problem with enforcing a mission file is that it will break a lot of existing scenarios. I think an alternate solution would be to load the mission file (either the default values or whichever file was specified) before any of the substems/panel states are read from the scenario file. This isn't done at the moment, but it should be a simple change. The subsystem/panel values are the last things written to the scenario file, so there shouldn't be any problems loading the mission file first.

But, in the scenario reading process, when do you know for sure that the mission file exists, or not? The only way I see of making this is creating the default mission first, and then if a mission file is found delete the old stuff and create again.

I took a look at the SimpleGPCSoftware and I was wondering is there a "common place" between all of the software that runs there? I'm asking because I'm thinking of having the AscentGuidance and the SSME SOP talking to each other (as it should be): SSME SOP provides the status of the engines, and AscentGuidance requests certain commands. Also shouldn't the RSLS be a SimpleGPCSoftware class too, running only on MM101?

 

[SiameseCat]

But, in the scenario reading process, when do you know for sure that the mission file exists, or not? The only way I see of making this is creating the default mission first, and then if a mission file is found delete the old stuff and create again.

I took a look at the SimpleGPCSoftware and I was wondering is there a "common place" between all of the software that runs there? I'm asking because I'm thinking of having the AscentGuidance and the SSME SOP talking to each other (as it should be): SSME SOP provides the status of the engines, and AscentGuidance requests certain commands. Also shouldn't the RSLS be a SimpleGPCSoftware class too, running only on MM101?

At the moment, you only know if a mission file is defined after reading the entire scenario file. If you look at the scenario file, it's basically split into 2 sections; lines defining the general state (like the mission file) and blocks for each of the subsystems and panels. It should be possible to read the general state lines, see if a mission file is defined, and then read the subsystem/panel blocks.

I'm not entirely sure what you mean by 'common place'. All the PreStep/PostStep functions are run once per timestep. Any communication between software classes is done through function calls (a good example of this is the OrbitTgtSoftware class, which has to communicate with the OMSBurnSoftware and StateVectorSoftware classes).

The RSLS should be a SimpleGPCSoftware class, but it was written before the SimpleGPCSoftware class was created, and there hasn't been any need to update it so far. I can convert it to a SimpleGPCSoftware class if you want (it'll probably have to be to communicate with the SSME SOP).

 

[GLS]

At the moment, you only know if a mission file is defined after reading the entire scenario file. If you look at the scenario file, it's basically split into 2 sections; lines defining the general state (like the mission file) and blocks for each of the subsystems and panels. It should be possible to read the general state lines, see if a mission file is defined, and then read the subsystem/panel blocks.

I'm not entirely sure what you mean by 'common place'. All the PreStep/PostStep functions are run once per timestep. Any communication between software classes is done through function calls (a good example of this is the OrbitTgtSoftware class, which has to communicate with the OMSBurnSoftware and StateVectorSoftware classes).

The RSLS should be a SimpleGPCSoftware class, but it was written before the SimpleGPCSoftware class was created, and there hasn't been any need to update it so far. I can convert it to a SimpleGPCSoftware class if you want (it'll probably have to be to communicate with the SSME SOP).

About the "common place" I was thinking something like RAM, but that will work fine.
I can do the RSLS move, but in exchange I need somebody how knows panels to make the Main Engine status lights (F7) and the Shutdown Limits switch (C3) and the EIU power switches (O17). No rush as I probably won't need that before the end of the year.

 

[SiameseCat]

About the "common place" I was thinking something like RAM, but that will work fine.
I can do the RSLS move, but in exchange I need somebody how knows panels to make the Main Engine status lights (F7) and the Shutdown Limits switch (C3) and the EIU power switches (O17). No rush as I probably won't need that before the end of the year.

If you want, it should be possible to implement something like RAM using a hashtable (although it might get complicated if you want to store multiple variable types). In general, though, I think function calls will be easier to understand.

I can do the panel stuff.

 

[Urwumpe]

In the real GPC the data is stored in the ascent common pool a memory structure that can be accessed by multiple tasks/processes of the GNC OPS 1 software. there is for example the MPS SOP that gathers the data from I/O and validates it, while another task drives the status lights. The separation makes sense for the software since both processes operate at different schedules and priorities.

 

[GLS]

Finally committed the new code, changes:
>> changed ALOT in the SSME corner of the project (warning: this is still a work in progress, and as such most things in there are not completly defined/complete/optimized. But any future changes probably won't be a problem for anybody since the interface between the engines and the rest of the project is the EIU and the SSME SOP;

>> added SSME SOP class to talk and listen to the main engines;

>> moved RSLS_old to SimpleGPCSoftware and changed it to use SSME SOP;

>> changed AscentGuidance to use SSME SOP and improved g limiting;

>> added purge sequence 4 command to the LCC;

>> updated most scenarios (the ones that worked for me at least) with SSME states;

For now that's it, I have to study now but hopefully I'll be able to pick up work again by the end of the year (if the world doesn't end by then ).

 

[DaveS]

>> added purge sequence 4 command to the LCC;.

I'm getting a bunch of unresolved linker errors. What do I need to add to the project to get a successful build?

 

[SiameseCat]

I've checked in an updated version of the VS 2010 project files - this should fix the link errors.

 

[SiameseCat]

Are the SSME_SOP::GetShutdownPhaseFlag and SSME_SOP::GetPostShutdownPhaseFlag functions working? I've been trying to implement the MPS lights on Panel F7, but these 2 flags don't seem to be getting set.

 

[GLS]

Are the SSME_SOP::GetShutdownPhaseFlag and SSME_SOP::GetPostShutdownPhaseFlag functions working? I've been trying to implement the MPS lights on Panel F7, but these 2 flags don't seem to be getting set.

I guess by your post that you are doing the logic behind the lights.... eerrrmmm.... I kinda had that done, and was just waiting for the lights on the panel...

I think the functions work, but amazingly I've been wrong on some occasions :lol: I'll go test then now.

---------- Post added at 01:16 PM ---------- Previous post was at 12:11 PM ----------

This is one of such occasions :facepalm: looks like I'm reading the wrong bits in the status word... I'll upload the fix sometime today or tomorrow.