Project Westcott RPE (Upgrade)

[Notebook]

Morning all, and a Happy New Year

As my Amberley(Upgrade) is nearly complete, Westcott project is next.

I'd like to start by making the P2 engine test cell:
http://i89.photobucket.com/albums/k207/Notebook_04/WestcottP2.jpg

It should really mimic the engine start-up and running procedure, with real-time data. this involves a .dll....

Having had an unpleasant experience with C++(I gave up, and went back to making bases), time for a bit more planning.

Looked at state-machines:
http://www.drdobbs.com/cpp/184401236;jsessionid=R1CS2QVQYGH1HQE1GHPCKH4ATMY32JVN

and pleasantly surprised that VisSim has a State Transition Block:
http://i89.photobucket.com/albums/k207/Notebook_04/StateMachine.jpg
(it also has a Case block, so I threw that in for good measure)

My plan is to get a state-machine working in VisSim, then with help, convert it to C++, then a dll in Orbiter.

This is part of the "states" I hope to model:
http://i89.photobucket.com/albums/k207/Notebook_04/img015-1.jpg

Is this a good/bad/too complex plan?

All input appreciated.

N.

 

[Urwumpe]

Not really too complex, but the question if always, will people notice it... like, will you produce maybe something that visualizes the rapid state changes?

 

[Notebook]

Thanks for the reply Urwumpe.

I suppose it will appeal to only a few Orbiters, but thats not a problem I think.
Its really a learning curve for Blue Streak(F3), my halted C++ project. I want to model as many systems for that as I can.

Starting with this ground based site, I can ignore all the flight systems, and keep it simple.

The mesh will have a control-room, and mimic panel for the valve positions, tank pressures, levels and flow-rates. Engine parameters, sensor readings, thrust, temperatures, etc. Don't know if MFD would be suitable for that, maybe a VC would be better.

The scenarios would run at .1x or slower, its the interaction betwen events I would really like to look at.
Though there could be some "emergency/failure" types to liven it up a bit

Could be a niche market...?

N.

 

[Wishbone]

Will download and study with eagerness. Re: display - suggest using screen Annotations for all the params, the font could be quite small for most items. The high-speed processes can be recorded in the PreStep/postStep callbacks, and displayed in a time-zoomed graph MFD.

EDIT: x0.1 acceleration is not among my favourites, since a lot of stuff (MFDs, for one) doesn't work as it should. 1x should be fine, just keep the telemetry log

 

[Notebook]

Thanks for the input Wishbone, it could be some time before its out in the wild. My previous .dll attempt came to a grinding halt:
http://www.orbiter-forum.com/showthread.php?t=8698&highlight=Blue+streak+F3(DLL)
Didn't think it was 18 months ago...good greif.

Anyway, at least I can make a start on the meshes, while I'm reading about state-machines.

N.

 

[Urwumpe]

Should be no problem, as long as you remember that orbiter calculates stuff in time steps, and one time step could be longer than a state lasts in your model (so you can have multiple states in one time step, just like one state could last multiple time steps)

 

[Notebook]

Made a start on isolating the main components for the engine:

http://i89.photobucket.com/albums/k207/Notebook_04/FiringSequence_11_.jpg

The pale Yellow blocks are components that may need more detail, though I'd like to keep it simple to start with. The Blue boxes are digital values, the others are analogue.

Any thing that I've missed, or shouldn't be modelling at this stage?

Simplified the model to use one heat-exchanger to pressurise both tanks.

All input appreciated

N.

 

[Wishbone]

If you use the same code for all parts of the engine, which is IMHO a preferred approach, you could quickly scale up right to the full model. An important caveat: ...only after you thoroughly de-bug the single component, and then, a (say a pump with inflow and outflow) simplified test-suite. Otherwise you would not know whether the weirdness comes from buggy code or wrong parameters or omission of something crucial.

 

[Notebook]

Thanks Wishbone, I'll take that aboard.

I'm looking at this VisSim as an example for state models:
http://s89.photobucket.com/albums/k207/Notebook_04/?action=view&current=newfile-1.mp4

These are the models:
http://i89.photobucket.com/albums/k207/Notebook_04/StateTransitions_1-1.jpg

This is the state block with its properties sheet:
http://i89.photobucket.com/albums/k207/Notebook_04/StateTransitions_2.jpg

Time to sit down and work through it, though the cryptic(to me) yellow text on the left is a worry...

EDIT: Here are the Help file entries for the State Transition block in VisSim.

http://i89.photobucket.com/albums/k207/Notebook_04/img046.jpg
http://i89.photobucket.com/albums/k207/Notebook_04/img047.jpg


N.

 

[Notebook]

While making the meshes for P2 had most of the video effects switched off. Just noticed this:

http://i89.photobucket.com/albums/k207/Notebook_04/Westcott Upgrade/11020509-45-47ShuttlePB.jpg
With Cloud Layers switchd off.

With Cloud Layers Switched on.
http://i89.photobucket.com/albums/k207/Notebook_04/Westcott Upgrade/11020509-46-26ShuttlePB.jpg

More noticeable here:
http://i89.photobucket.com/albums/k207/Notebook_04/Westcott Upgrade/11020510-14-14ShuttlePB.jpg

Looks like the P2 ground mesh isn't taking the Cloud Layers?
Its a DDS 3 type with an Alpha mask on the rectangular mesh.

Anything I can do about this?

Many thanks, N.

 

[Loru]

Post material entry from .msh file

 

[Notebook]

Good question, here she blows!

MATERIALS 9
Westcott 
Concrete
Tanks
FiringTrench
FiringTrench
Fencing
Rough
Posts
TankBase
MATERIAL Westcott 
1.0 1.0 1.0 1.0
1.0 1.0 1.0 1.0
0.9 0.9 0.9 1.0 0.0
0.0 0.0 0.0 1.0
MATERIAL Concrete
0.588235 0.588235 0.588235 1.0
0.588235 0.588235 0.588235 1.0
0.9 0.9 0.9 1.0 0.0
0.0 0.0 0.0 1.0
MATERIAL Tanks
0.588 0.588 0.588 1.0
0.588 0.588 0.588 1.0
0.9 0.9 0.9 1.0 0.0
0.0 0.0 0.0 1.0
MATERIAL FiringTrench
0.905882 0.905882 0.905882 1.0
0.905882 0.905882 0.905882 1.0
0.666667 0.666667 0.666667 1.0 20.0
0.0 0.0 0.0 1.0
MATERIAL FiringTrench
0.588 0.588 0.588 1.0
0.588 0.588 0.588 1.0
0.9 0.9 0.9 1.0 0.0
0.0 0.0 0.0 1.0
MATERIAL Fencing
0.709804 0.0 0.0 1.0
0.709804 0.0 0.0 1.0
0.9 0.9 0.9 1.0 0.0
0.0 0.0 0.0 1.0
MATERIAL Rough
0.588235 0.588235 0.588235 1.0
0.588235 0.588235 0.588235 1.0
0.9 0.9 0.9 1.0 0.0
0.0 0.0 0.0 1.0
MATERIAL Posts
0.588235 0.588235 0.588235 1.0
0.588235 0.588235 0.588235 1.0
0.9 0.9 0.9 1.0 0.0
0.0 0.0 0.0 1.0
MATERIAL TankBase
0.588235 0.588235 0.588235 1.0
0.588235 0.588235 0.588235 1.0
0.9 0.9 0.9 1.0 0.0
0.0 0.0 0.0 1.0
TEXTURES 8
Westcott_RPE_3_.dds
Concrete.dds
issrad.dds
Mc2.dds
tile1.dds
Wall01.dds
tred.dds
metalcon.dds

Don't know why FiringTrench is in there twice, have to look at that?

N.

 

[Notebook]

Done some work in VisSim: This is the LOX Run Tank fill and pressurisation model.

http://i89.photobucket.com/albums/k207/Notebook_04/RZ-2_12.jpg

I think this is the most detail I need for this part of the system.
VisSim lets you encapsulate blocks to keep the diagram simple. It also lets you use Mathcad inside the blocks, which is useful as I have some experience with that.

I haven't started on the state diagram yet, I'm using "Button" blocks to open and close valves manually, and switch the tank pressurisation over. In the diagram Green arrows are boolean values(valve open/closed, switch source) and Red arrows are "analogue" values. VisSim can handle scalar and vectors through those.

What I'm after...is some advice about C++ relating to this.
1) The two tanks and valves look like candidates for being classes. There are lots of valves in this model, and quite a few tanks.
2)Should the three variables Pressure,Level and Flow be global variables? They will be needed elsewhere.

3) Probably the most tricky, especially to me! Do I need the variable "LOX Run Tank Out". Its really the physical pipe out of the tank, and I'm not sure if it should be in there as a model element?

Any other comments and suggestions welcome!

Many thanks, N.

 

[Wishbone]

The underlying mathematics are differential equations on graphs (me ain't no physicist, remember). Thus, it doesn't really matter for the end result if you go with sparse matrices or lists of objects or whatever. It is imho of interest only from the ease of coding/maintainability viewpoint. If were in your shoes, would shop around on the Internet (sourceforge, google code etc.) for free open source hydraulic simulators (Newtonian/uncompressible for starters). As for variables please consider adding the time derivatives. Hydraulic hammer can be devastating, BTW...

 

[Notebook]

Thanks Wishbone, for now I intend to keep well away from any calculus! I'm also keeping this very simple, just keeping level and pressure in the Lox run tank at the moment, no engine firing.

Re hydraulic lock, this came up in an earlier thread:

http://www.orbiter-forum.com/showthread.php?t=6278&page=3
Frame #37.

That CIA document is very interesting.

N.

 

[Wishbone]

Thanks, attempt to do the same but calculus keeps running after me and biting at unexpected locations...

 

[Notebook]

Its the usual problem, try and keep it simple. But even a simple model like this, filling and emptying a tank, and keeping the pressure constant with variable volume is giving me headaches! Have to keep on it though, if I can't do it in VisSim, there's little chance in C++.

N.

 

[Notebook]

Before I get too far into system modelling, a simple? question.

This is the mesh I have at the moment:
http://i89.photobucket.com/albums/k207/Notebook_04/3DSMAX_1_47.jpg

This is its .cfg entry

; Start of custom buildings
MESH
FILE Westcott_RPE_1
OWNMATERIAL
POS -522.5 0 31
ROT -1
SCALE 1 1 1
END
; End of custom buildings

One large mesh at the moment.

As the "Firing Bunker" will have the virtual-cockpit control room, should I seperate it off from the rest, and make just this the vessell in the .dll?
The only animation in the project will be the engine gimballing, hydraulic rams, and the heat-exchanger motion. Its not a visually exciting project, but that isn't the point.

Would it be simpler to leave it as a single mesh/vessel, engines, pipework, support frames?

Many thanks, N.

 

[Wishbone]

Single mesh, methinks will do. Re: simulation. I have been reading some stuff on thermohydraulic models lately; found this site - http://www.colsim.de/
Have not tried contacting the author, though. The Ph.D. thesis I linked to in the Space PDF collection thread contains some references to current codes used, inter alia, for liquid-fuel engine modelling.

 

[Notebook]

Thanks Wishbone, as I need the practice I'm doing both. Talk about hedging your bets...

Still going through the express set-up again, and again.

Put the ColSim link in my favourites, looks intersting...

N.