SSU Development thread (4.0 to 5.0) [DEVELOPMENT HALTED DUE TIME REQUIREMENTS!]

[GLS]

Leave this to me, I already have a volume license for semaphores. :lol:

Essentially, the non-multithreaded solution would be like you say. Get the data before the process is executed and don't switch processes when a SVC is called. Maybe split bigger processes into smaller "execution blocks" that begin with a finished SVC operation.

I think you want to take a step, and I just want/need to take half a step. :lol: The "data input" would be the same STS()->GetABC() as we have now, and the processes would access the memory this way pCOMPOOL->varA; so I fail to see the point of a more complex system (for now).

Similar happens for the application software that drives the displays. The I/O with the IDP happens by HAL/S macros at the definition of the application process.

Data to the IDP and the HUD, one thing I'll have to play with in the near future... but first I'd like to solve this runway altitude problem.

I have a prototype that works already with multithreaded DPS processing, but it is still just a prototype with many design bugs in it. It even crashes sometimes, so hardly useful now. I can offer it to SSU when I have it stable and you can understand it as well.

If it crashes sometimes, that means it works... sometimes.

About the line of thought: How much do you know about Direct Memory Access I/O?

In our case we would give the MDMs a memory address, and then they write their data directly in that address without GPC "assistance", right?

 

[Urwumpe]

Let's say: It works as expected. I am not yet happy with it. For example, I have not yet solved the problem of variable timesteps. Without additional specifications, its impossible to "synchronize" with Orbiter in a meaningful way, so that one execution of a process can finish before the next execution is started.

One dirty fix idea that now circles in my head is using an alternative process for higher levels of time warp. But that is still a problem that requires me to climb back on top of my mountain and meditate over it.

In our case we would give the MDMs a memory address, and then they write their data directly in that address without GPC "assistance", right?

The direction is correct. Now replace MDM by IOP. The MDM doesn't know and doesn't care who is using it. It only replies to commands.

The IOP is essentially one specialist ALU with many sets of registers, that are used in a round-robin fashion. Each set does contain data like "where to get the next IO instruction" and "where to read the output data" or "where to store the input data". It is a bit mystical, but essentially you have two sets of register sets. The MSC controls the IOP and has some registers more, the BCEs handle the IO with a serial shuttle bus. Each BCE is controlled by the same ALU, thus only one BCE can be active at a time, but switching BCEs happens so fast that you practically doesn't notice the difference. The most common BCE programs reside in BCE PROM and can't be changed in flight.

A BCE can essentially do the following actions (accuracy limited by research):

1. Wait for index (#WIX) is a known instruction and means the BCE waits until the first MDM starts to respond on the bus.
2. It can read n 16-bit words from the bus
3. It can send a command and write n 16-bit words to the bus.
4. Branches in a BCE program are possible, conditional and unconditional.

n can be a large number, because of the ability of the MDM to execute special MDM programs from PROM. Its uncommon for a BCE program to read and write at the same time, but it does happen and is perfectly legal. The maximum n possible in theory should be 512 words. If a single read or write instruction is executed without using the PROM, the maximum number of words is 32.


Thus, a good implementation would execute a number of BCE/MSC instructions per timestep. A good enough implementation would be defining the programs in C++ and simply point them to the beginning of the memory used for data transfer.

I can't find any hint that a BCE program can jump over multiple memory locations in GPC memory. It looks like they are always processed in sequence.

 

[GLS]

The direction is correct. Now replace MDM by IOP. The MDM doesn't know and doesn't care who is using it. It only replies to commands.

The IOP is essentially one specialist ALU with many sets of registers, that are used in a round-robin fashion. Each set does contain data like "where to get the next IO instruction" and "where to read the output data" or "where to store the input data". It is a bit mystical, but essentially you have two sets of register sets. The MSC controls the IOP and has some registers more, the BCEs handle the IO with a serial shuttle bus. Each BCE is controlled by the same ALU, thus only one BCE can be active at a time, but switching BCEs happens so fast that you practically doesn't notice the difference. The most common BCE programs reside in BCE PROM and can't be changed in flight.

A BCE can essentially do the following actions (accuracy limited by research):

1. Wait for index (#WIX) is a known instruction and means the BCE waits until the first MDM starts to respond on the bus.
2. It can read n 16-bit words from the bus
3. It can send a command and write n 16-bit words to the bus.
4. Branches in a BCE program are possible, conditional and unconditional.

n can be a large number, because of the ability of the MDM to execute special MDM programs from PROM. Its uncommon for a BCE program to read and write at the same time, but it does happen and is perfectly legal. The maximum n possible in theory should be 512 words. If a single read or write instruction is executed without using the PROM, the maximum number of words is 32.


Thus, a good implementation would execute a number of BCE/MSC instructions per timestep. A good enough implementation would be defining the programs in C++ and simply point them to the beginning of the memory used for data transfer.

I can't find any hint that a BCE program can jump over multiple memory locations in GPC memory. It looks like they are always processed in sequence.

Can you point me to a document about that (and/or the GPC in general)? I did some work in HW and I'm finding that interesting.
Anyway, how do we stand on the COMPOOL and UPP: do we really need the "advanced system" or a simple structure and making the UPP a SimpleGPCSoftware class is enough? (it is for me, but you are the GPC expert so this is up to you)

 

[Urwumpe]

Can you point me to a document about that (and/or the GPC in general)? I did some work in HW and I'm finding that interesting.

Well, the source that gives you most insight in how the IOP is used is the detailed design specification document for the ALT tests, sadly it is offline by now, but the SM software specification for the OFT era is still around for reference.

http://hdl.handle.net/2060/19800005918

The file 19770075091_1977075091.pdf might be the ALT specification, but I can't verify it, I am responding from a rather limited hotel WiFi here. I have found quite many other interesting abstracts on NTRS, that I need to check next week.

Next I recommend the Space Shuttle System Handbook we have on sourceforge in the references.

Anyway, how do we stand on the COMPOOL and UPP: do we really need the "advanced system" or a simple structure and making the UPP a SimpleGPCSoftware class is enough? (it is for me, but you are the GPC expert so this is up to you)

My position there - we just need a solution that is

1. as simple as possible and
2. behaves like the original

I think it makes sense to keep the MDMs close to the real one because their behavior defines a lot and can be effected noticable by probable faults. Also quite a few SM functions depend on them.


I would prefer a multithreaded solution because it allows to use the flow charts from NASA for our job. But I see it being not trivial.

 

[GLS]

My position there - we just need a solution that is

1. as simple as possible and
2. behaves like the original

I think it makes sense to keep the MDMs close to the real one because their behavior defines a lot and can be effected noticable by probable faults. Also quite a few SM functions depend on them.


I would prefer a multithreaded solution because it allows to use the flow charts from NASA for our job. But I see it being not trivial.

I think point 1 is satisfied and point 2, AFAIK is too. I don't want to play with MDMs yet, I just want the sw to get their data from a more centralized place, but the data source is still "phony" as it is now, i.e. call Orbiter from the GPCs. Basically there would still be no IO, the data will just magically appear in the COMPOOL instead of in several variables in each class.... for now.

 

[Urwumpe]

I think point 1 is satisfied and point 2, AFAIK is too. I don't want to play with MDMs yet, I just want the sw to get their data from a more centralized place, but the data source is still "phony" as it is now, i.e. call Orbiter from the GPCs. Basically there would still be no IO, the data will just magically appear in the COMPOOL instead of in several variables in each class.... for now.

Point 2 not. Simply because we could shutdown all MDMs and it would still work. We could misconfigure all sensors, and it would work. It is pretty obviously not working.

Also, calling Orbiter directly from the GPCs is poor. I would place at least one level of abstraction between the two so we can test stuff directly by putting a test "sensor data provider" in place of the version that talks to Orbiter.

 

[GLS]

Point 2 not. Simply because we could shutdown all MDMs and it would still work. We could misconfigure all sensors, and it would work. It is pretty obviously not working.

Also, calling Orbiter directly from the GPCs is poor. I would place at least one level of abstraction between the two so we can test stuff directly by putting a test "sensor data provider" in place of the version that talks to Orbiter.

Yes, that is the target: proper data flow. I'm not proposing going in a different direction, but it's like I said in a previous post "you want to take a step, and I just want/need half a step". IMO, for now all we need is a "centralized data source" in the GPCs, and how the data gets there doesn't matter.
At a later date we add the MDMs and start getting the data from the subsystems, but for now all I need is to have everyone using the same altitude so the runway is where the vehicle thinks.

 

[Urwumpe]

Yes, that is the target: proper data flow. I'm not proposing going in a different direction, but it's like I said in a previous post "you want to take a step, and I just want/need half a step". IMO, for now all we need is a "centralized data source" in the GPCs, and how the data gets there doesn't matter.
At a later date we add the MDMs and start getting the data from the subsystems, but for now all I need is to have everyone using the same altitude so the runway is where the vehicle thinks.

That is why I suggested having one or two (or maybe three) layers of abstraction between GPC software process and the sensor. That way we can simply switch between "straight from the tap by Orbiter" via "talks with the MDM directly" to "executes BCE programs" without needing to modify the software much. Also we can test it much easier, if we simply can compare Orbiter data to sensor implementation data (within tolerance, proper noise?)

 

[GLS]

That is why I suggested having one or two (or maybe three) layers of abstraction between GPC software process and the sensor. That way we can simply switch between "straight from the tap by Orbiter" via "talks with the MDM directly" to "executes BCE programs" without needing to modify the software much. Also we can test it much easier, if we simply can compare Orbiter data to sensor implementation data (within tolerance, proper noise?)

For what we need now (altitude), we would need the get the IMUs working, and a state vector to propagate, and then TACAN and/or GPS, and MLS... it would only be done in 5 years or so. :facepalm:
AFAIK the altitude and state vector calculations are done by the UPP, and what I'm proposing is to "point" the rest of the software to the COMPOOL and have the UPP come up with the data there. But the UPP instead of going to the subsystems, it just calls Orbiter as it is done now. A future upgrade, where we start using MDMs and have SOPs processing subsystem data by the bucket load, won't change the rest of the software (at least the users: DAPs, etc) as they already are going to the COMPOOL to get their data.
This is almost a first layer of abstraction between the (user) software and Orbiter: don't call Orbiter directly, go to the COMPOOL instead.

 

[Urwumpe]

For what we need now (altitude), we would need the get the IMUs working, and a state vector to propagate, and then TACAN and/or GPS, and MLS... it would only be done in 5 years or so. :facepalm:

I find it much more troubling that we still did not get any GNC sensors working in 9 project years because everytime somebody decided to use a "quicker way to simply poll Orbiter everywhere".

Still, we did not have much information about the implementation details of the GNC sensors until about 4 years ago, so we have some weak excuse there for not guessing.

So, what do you want? Another 9 years of not getting anything of the essential stuff working among all the shiny details and alt-history stuff?

I don't think I want to go that path. Especially since I think that putting more components into libUltra could see a better effect by effort ratio. I think it is time to catch up at the low-level stuff with the high-level features we already have. The project is getting unbalanced otherwise. We have many features glued on every next release, each with a special solution for basic tasks, but no maintainable code.

 

[GLS]

I find it much more troubling that we still did not get any GNC sensors working in 9 project years because everytime somebody decided to use a "quicker way to simply poll Orbiter everywhere".

Still, we did not have much information about the implementation details of the GNC sensors until about 4 years ago, so we have some weak excuse there for not guessing.

So, what do you want? Another 9 years of not getting anything of the essential stuff working among all the shiny details and alt-history stuff?

I don't think I want to go that path. Especially since I think that putting more components into libUltra could see a better effect by effort ratio. I think it is time to catch up at the low-level stuff with the high-level features we already have. The project is getting unbalanced otherwise. We have many features glued on every next release, each with a special solution for basic tasks, but no maintainable code.

I don't think what I proposed in the previous posts is going away from what you (and me) want, but is a first step. Granted, it's not a huge improvement, but I don't think it's a "duct-tape" solution... I'm sorry but I don't know what else to say about this... :shrug:
I think I'm going to look at some of the tickets now.

 

[Urwumpe]

I don't think what I proposed in the previous posts is going away from what you (and me) want, but is a first step. Granted, it's not a huge improvement, but I don't think it's a "duct-tape" solution... I'm sorry but I don't know what else to say about this... :shrug:
I think I'm going to look at some of the tickets now.

Well, I would prefer to have a clean datapath even if it does not go the whole way. I am a bit unhappy with the current state there.

I think about maybe using 2017 for just doing lowest level work for SSU for a year and focus on libUltra.

 

[GLS]

DaveS, can you confirm that the aft and forward ET umbilical mechanisms are the same size and that they are aligned such that they rotate within the same axis? (i.e., except for the "tilt" the door has to follow the OML, is it all symmetrical?) If so, that would reduce the number of animations (and math).

---------- Post added at 07:45 PM ---------- Previous post was at 01:44 PM ----------

DaveS, can you confirm that the aft and forward ET umbilical mechanisms are the same size and that they are aligned such that they rotate within the same axis? (i.e., except for the "tilt" the door has to follow the OML, is it all symmetrical?) If so, that would reduce the number of animations (and math).

Never mind, it seems it really is all aligned as it all works fine with the new animation math. I still have to run a few more tests, but I'll probably upload it today.

 

[GLS]

How are we going to proceed on the lakebed runways? At Edwards we have one runway (and the compass) "drawn" with a mesh, and at White Sands we're using runway textures...

 

[Donamy]

DaveS, There is still an issue with the Orbiter nose. You missed two vertices when you scaled the section.

 

[DaveS]

DaveS, There is still an issue with the Orbiter nose. You missed two vertices when you scaled the section.

Is this any better: https://dl.dropboxusercontent.com/u/24122088/Orbiter stuff/SSU_v4.3r0.zip
Just extract it into your SSU 4.2 folder and overwrite the existing Orbiter.msh.

 

[GLS]

Just to confirm this is a real issue and I'm not going mad: in the "EDW 22 TAEM" scenario, panel F4 is not working, right?
I think I've debugged as far as I can, and I can't find out what the problem is: it's not c.g. motion, or panel load order, or something panel specific, or bad coordinates. I even tried making the panel click area huge, and still it was nowhere to be found. The mouse events just aren't detected...
Any ideas to try before calling for Martin's help?

 

[DaveS]

Just to confirm this is a real issue and I'm not going mad: in the "EDW 22 TAEM" scenario, panel F4 is not working, right?
I think I've debugged as far as I can, and I can't find out what the problem is: it's not c.g. motion, or panel load order, or something panel specific, or bad coordinates. I even tried making the panel click area huge, and still it was nowhere to be found. The mouse events just aren't detected...
Any ideas to try before calling for Martin's help?

I can confirm this. No response whatsoever from any the PBIs on F4 in that scenario.

 

[GLS]

I can confirm this. No response whatsoever from any the PBIs on F4 in that scenario.

The problem is not the PBIs, they don't get the mouse events because clbkVCMouseEvent() is not event called, even though oapiVCSetAreaClickmode_Quadrilateral() is called same as other panels...
The same happens (or happenned) on panel A8, and I remember when I was adding one of the panels for the upper stages, it wouldn't work if I put it on the AftLeft panel group or the Aft, instead of the other. :facepalm:

 

[Donamy]

Is this any better: https://dl.dropboxusercontent.com/u/24122088/Orbiter stuff/SSU_v4.3r0.zip
Just extract it into your SSU 4.2 folder and overwrite the existing Orbiter.msh.

Better !!!

---------- Post added at 08:40 PM ---------- Previous post was at 08:39 PM ----------

I seem to be having a problem with the payload latches unlatching. Anyone else ?