Orbiter-Forum  

Go Back   Orbiter-Forum > Orbiter Addons > Addon Support & Bugs > Addon Developer Forums > Space Shuttle Ultra
Register Blogs Orbinauts List Social Groups FAQ Projects Mark Forums Read

Space Shuttle Ultra Support & development threads for Space Shuttle Ultra addon.

Reply
 
Thread Tools
Old 07-18-2018, 11:08 PM   #1906
DaveS
Addon Developer
 
DaveS's Avatar


Default

Quote:
Originally Posted by GLS View Post
 Bug found! Surprise surprise, it was my fault... When I added the _DEBUG preprocessor stuff a few weeks ago, I had one line too many inside it, so when not in debug mode, the @ENDSUBSYSTEM line was never written, and when loading = kaput every single subsystem parameter.
Thanks for tracking the down the bug and fixing it. I was starting to think that something was seriously wrong with my system since it was so strange.
DaveS is offline   Reply With Quote
Old 07-19-2018, 12:41 PM   #1907
GLS
Addon Developer
 
GLS's Avatar
Default

Quote:
Originally Posted by DaveS View Post
 Thanks for tracking the down the bug and fixing it. I was starting to think that something was seriously wrong with my system since it was so strange.
It's my job (and it was my fault...).
GLS is offline   Reply With Quote
Old 07-19-2018, 01:08 PM   #1908
Urwumpe
Certain Super User
 
Urwumpe's Avatar

Default

Quote:
Originally Posted by GLS View Post
 It's my job (and it was my fault...).
"We don't make mistakes, just happy little accidents."

And if you don't want to believe in the words of Bob Ross, always remember: SSU is a team effort, in the good times and in the bad times.
Urwumpe is offline   Reply With Quote
Old 07-19-2018, 02:17 PM   #1909
Wolf
Donator
 
Wolf's Avatar
Default

Quote:
Originally Posted by Urwumpe View Post
 "We don't make mistakes, just happy little accidents."

And if you don't want to believe in the words of Bob Ross, always remember: SSU is a team effort, in the good times and in the bad times.

Guys YOU ROCK
Wolf is offline   Reply With Quote
Thanked by:
Old 07-20-2018, 10:10 PM   #1910
GLS
Addon Developer
 
GLS's Avatar
Default

Quote:
Originally Posted by Urwumpe View Post
 "We don't make mistakes, just happy little accidents."
Well, here's another...
Although I'm not totally happy with the current SimpleCOMPOOL, I think the current short comings can be overcome with more code, most of it outside Orbiter. Given that we don't have a list of the COMPOOLs and what variables are in them, I currently can't really justify a move to the structure-type construct. So we are left with the current unsigned short array. A way to have both a way to load/save the variables, and to garantee that the addresses don't everlap (not easy by hand) is to have some sort of script/program/whatever that would take a list of variables (i.e. names) and their types and would generate the addresses and a string of names, so new code in the SimpleGPCSystem can take to name variables for the scenarios files.
BTW: An interesting detail about COMPOOLs is what lifetime do they have? *my head hurts*

What I haven't figured out yet is how to plug the I-LOADs into this... some of them must be placed in COMPOOL variables, to be accessable by multiple modules, and maybe there should be a way to define them per mission file. And maybe they don't need to be loaded/saved from the scenario file.

---------- Post added at 11:10 PM ---------- Previous post was at 10:38 PM ----------

Maybe a .csv file for COMPOOL definition like this:
[name], [type], [I-LOADs as needed/desired]
XDOT,DW,(I-LOAD),,,
AEROJET_FCS_ROLL,W,(I-LOAD),,,
XA,M22,(I-LOAD),(I-LOAD),(I-LOAD),(I-LOAD)
AB_CD,W4,(I-LOAD),(I-LOAD),(I-LOAD),(I-LOAD)
WX_YZ,DW3,,,,

(^^still have to research the types)

...and have the I-LOADs in a separate list that would be used to generate a .h file with all the consts so they can be used by who needs them.

This is already a good detour from the guidance stuff, but I really need to have some I-LOADs in the COMPOOL, and also have them in an matrix so I can access them via index, so something needs to be done.
GLS is offline   Reply With Quote
Old 07-20-2018, 10:10 PM   #1911
Urwumpe
Certain Super User
 
Urwumpe's Avatar

Default

Quote:
Originally Posted by GLS View Post
 BTW: An interesting detail about COMPOOLs is what lifetime do they have? *my head hurts*

What I haven't figured out yet is how to plug the I-LOADs into this... some of them must be placed in COMPOOL variables, to be accessable by multiple modules, and maybe there should be a way to define them per mission file. And maybe they don't need to be loaded/saved from the scenario file.

Well, should I really make things overly complicated?



A COMPOOL shares the lifetime of its memory overlay. There is no memory management in the FCOS that is more sophisticated. You can say, everything is determined at compile time. A memory configuration (MC) simply consists of the FCOS overlay (OPS 0) and the application software overlay (For example, the majory function GNC memory overlay + OPS 1 overlay + minimal OPS 3 overlay in upper memory). When a memory overlay is changed, the contents of the new memory overlay are loaded from tape.

Thus, the I-LOADS are simple: They are set at compilation. More specific, the compilation of the tape images from compiled object files. You simply load the memory overlay from tape and the I-LOADS are there.

An I-LOAD is roughly the HAL/S equivalent to a "int x = 1;" statement.

Yes, a CSV file would be one option. I would prefer a minimal HAL/S FC parser there, simply because the input would then be exactly the information we have from NASA, and structured data could be kept structured, just like arrayed data, what CSV can't. Another option would be a XML structure. The data types are explained in the HAL/S language manuals. When loading a scenario, we would need something like a "tape linker" creating the data structures for every memory configuration. Also, for modifications/uplinks after creating the tapes, we would need to store the changes in memory or the changes of data on the tape.

Did you already take a look at the examples or parser trees of the COMPOOLs in HAL/S?

Last edited by Urwumpe; 07-20-2018 at 10:29 PM.
Urwumpe is offline   Reply With Quote
Old 07-21-2018, 12:02 AM   #1912
GLS
Addon Developer
 
GLS's Avatar
Default

Quote:
Originally Posted by Urwumpe View Post
 A COMPOOL shares the lifetime of its memory overlay. There is no memory management in the FCOS that is more sophisticated. You can say, everything is determined at compile time. A memory configuration (MC) simply consists of the FCOS overlay (OPS 0) and the application software overlay (For example, the majory function GNC memory overlay + OPS 1 overlay + minimal OPS 3 overlay in upper memory). When a memory overlay is changed, the contents of the new memory overlay are loaded from tape.
I suspected that MCs had something to do with it... and ATM I'm not really interested in going down that road.

Quote:
Originally Posted by Urwumpe View Post
 Thus, the I-LOADS are simple: They are set at compilation. More specific, the compilation of the tape images from compiled object files. You simply load the memory overlay from tape and the I-LOADS are there.

An I-LOAD is roughly the HAL/S equivalent to a "int x = 1;" statement.
That I knew. It's not so much the nature of the I-LOADS but how do we come up with something that works for both modules (our SimpleGPCSoftware classes) and the COMPOOL.
My idea above, of having a I-LOAD list that gets processed into a .h file, and also gets used by the COMPOOL "preprocessor" (that generates the COMPOOL stuff for usage and save/load), doesn't allow for mission specific I-LOADS. Most of the I-LOADs didn't change or they aren't critical enough for "user control" (e.g., the 15s OMS EXEC timer), but user control is needed because SSME max thrust was defined via I-LOAD. Maybe having a I-LOAD list (static) just with the names, and keeping the values in another list (user defined) would work. The values list would be loaded into an array, and then each module, and SimpleGPCSystem for the COMPOOL, would read what they needed for their initializations.

Quote:
Originally Posted by Urwumpe View Post
 Yes, a CSV file would be one option. I would prefer a minimal HAL/S FC parser there, simply because the input would then be exactly the information we have from NASA, and structured data could be kept structured, just like arrayed data, what CSV can't. Another option would be a XML structure. The data types are explained in the HAL/S language manuals. When loading a scenario, we would need something like a "tape linker" creating the data structures for every memory configuration. Also, for modifications/uplinks after creating the tapes, we would need to store the changes in memory or the changes of data on the tape.

Did you already take a look at the examples or parser trees of the COMPOOLs in HAL/S?
Parser trees of COMPOOLs?! I haven't read everything of the docs I have, but I haven't seen that...
Like I said in the post above, we don't know what variables go in which COMPOOL... or do we? And even if we know some, that won't be all, and as accessing then in C/C++ won't be as easy as in HAL/S, why bother with grouping them in the code? We could "group" the variables (and ID the COMPOOL if we have that info) in comments on the "COMPOOL variable list file".
About specifying things in a way that is closer to "the official way": totally agree. Like I said above, I have yet to do a catalog of the types, so that needs to be done so we know the potatos from the onions. Going back to paragraph above, do we have enough info?
GLS is offline   Reply With Quote
Reply

  Orbiter-Forum > Orbiter Addons > Addon Support & Bugs > Addon Developer Forums > Space Shuttle Ultra


Thread Tools

Posting Rules
BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
Forum Jump


All times are GMT. The time now is 05:53 AM.

Quick Links Need Help?


About Us | Rules & Guidelines | TOS Policy | Privacy Policy

Orbiter-Forum is hosted at Orbithangar.com
Powered by vBulletin® Version 3.8.6
Copyright ©2000 - 2018, Jelsoft Enterprises Ltd.
Copyright 2007 - 2017, Orbiter-Forum.com. All rights reserved.