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

[GLS]

Did you use the suggestion of splitting contact rings from the switch?

Yep, here's the whole thing:

StandardRotarySwitch::StandardRotarySwitch( Atlantis *_sts, const std::string &_ident, unsigned short _usNumPositions, unsigned short _usNumMuxes ):BasicRotarySwitch( _sts, _usNumPositions, _ident ),
		inputSignals( _usNumMuxes, vector<DiscInPort>( _usNumPositions ) ),
		outputSignal( _usNumMuxes )
	{
	}

	StandardRotarySwitch::~StandardRotarySwitch()
	{
	}

	void StandardRotarySwitch::ConnectInputSignal( unsigned short usMux, unsigned short usIndex, DiscreteBundle *pBundle, unsigned short usLine )
	{
		inputSignals.at( usMux ).at( usIndex ).Connect( pBundle, usLine );
		return;
	}

	void StandardRotarySwitch::ConnectOutputSignal( unsigned short usMux, DiscreteBundle *pBundle, unsigned short usLine)
	{
		outputSignal.at( usMux ).Connect( pBundle, usLine );
		return;
	}

	void StandardRotarySwitch::OnPreStep( double SimT, double DeltaT, double MJD )
	{
		for (int i = outputSignal.size() - 1; i >= 0; i--) outputSignal.at( i ).SetLine( inputSignals.at( i ).at( usCurrentPosition ).GetVoltage() );
		return;
	}

Currently this is being used in 2 places, one has 1 mux and the other 3, and both work.

 

[Urwumpe]

Ah OK... I meant it done differently there, I'll refactor it later. Its just two switches right now, no showstopper.

I mean making a generic interface for the contact rings and then having two versions (or more if needed) to be added to the switch.

 

[mstram]

Yep, here's the whole thing:

StandardRotarySwitch::StandardRotarySwitch( Atlantis *_sts, const std::string &_ident, unsigned short _usNumPositions, unsigned short _usNumMuxes ):BasicRotarySwitch( _sts, _usNumPositions, _ident ),
        inputSignals( _usNumMuxes, vector<DiscInPort>( _usNumPositions ) ),
        outputSignal( _usNumMuxes )
    {
    }

    StandardRotarySwitch::~StandardRotarySwitch()
    {
    }

    void StandardRotarySwitch::ConnectInputSignal( unsigned short usMux, unsigned short usIndex, DiscreteBundle *pBundle, unsigned short usLine )
    {
        inputSignals.at( usMux ).at( usIndex ).Connect( pBundle, usLine );
        return;
    }

    void StandardRotarySwitch::ConnectOutputSignal( unsigned short usMux, DiscreteBundle *pBundle, unsigned short usLine)
    {
        outputSignal.at( usMux ).Connect( pBundle, usLine );
        return;
    }

    void StandardRotarySwitch::OnPreStep( double SimT, double DeltaT, double MJD )
    {
        for (int i = outputSignal.size() - 1; i >= 0; i--) outputSignal.at( i ).SetLine( inputSignals.at( i ).at( usCurrentPosition ).GetVoltage() );
        return;
    }

Currently this is being used in 2 places, one has 1 mux and the other 3, and both work.

Well, I've been trying to understand how the switches work, and the "Connect" function seems to possibly be one of the "keys" ?

I've been looking for "OnMouse" type functions, and how the clbkPreStep / PostStep functions fit into the mix, but it's all still a big mystery to me, how / where a mouse click on a switch gets "read" by the code.

For example I've been looking at PanelA8 /

pRMSMode->ConnectOutputSignal(i, pBundle, i);

Am I close ?

Mike

 

[GLS]

Well, I've been trying to understand how the switches work, and the "Connect" function seems to possibly be one of the "keys" ?

I've been looking for "OnMouse" type functions, and how the clbkPreStep / PostStep functions fit into the mix, but it's all still a big mystery to me, how / where a mouse click on a switch gets "read" by the code.

For example I've been looking at PanelA8 /

pRMSMode->ConnectOutputSignal(i, pBundle, i);

Am I close ?

Mike

The "connects" just connect the switches to one (or more) lines in a bundle, so the position of the switch can be read somewhere else.
The mouse events start in the standard Orbiter callback for mouse events (can't remember the exact name now), and the click position is sent to each panel group, which then sends that data to each panel inside it, and then each panel checks the coordinates of its vc components to see if the click position is inside the defined area, and if so, it calls the mouse event function is the switch, which then responds to the click by moving the switch mesh and updating the output that is sent to the specified line in the "connect" function.

 

[asdad]

GLS , Can i access SSUWorkbench in VS2010 or it's only for VS2013 ?

 

[GLS]

GLS , Can i access SSUWorkbench in VS2010 or it's only for VS2013 ?

It might just be available on VS2013 due to the .net version, but I'm not sure.

 

[asdad]

ok thank's GLS

 

[mstram]

The "connects" just connect the switches to one (or more) lines in a bundle, so the position of the switch can be read somewhere else.

Ya, well it's the "somewhere else" I'm trying to find.

I read the code where the bundle gets connected, but I don't see anything referring to the bundle to read the switch value.

Is the bundle stuff for "future use" ? (not used now ?)

 

[Urwumpe]

Ya, well it's the "somewhere else" I'm trying to find.

I read the code where the bundle gets connected, but I don't see anything referring to the bundle to read the switch value.

Is the bundle stuff for "future use" ? (not used now ?)

It is used already - it is for loose-coupling subsystems and components with each other. Essentially, speaking: Direct connections between the C++ components of SSU should be avoided, so we can more easily swap components during runtime or reuse components in different places.

There is no direct way to see what connects to a bundle yet (except calling debugging functions). I wanted to add a tool one day that allows checking the references during runtime and monitor activity on a bundle. Originally a dedicated dialog window, but right now I think having a special SSUDebugMFD might be a faster way to get things done with various rendering clients supported.

 

[GLS]

Ya, well it's the "somewhere else" I'm trying to find.

I read the code where the bundle gets connected, but I don't see anything referring to the bundle to read the switch value.

Is the bundle stuff for "future use" ? (not used now ?)

To find both ends of the bundle, just search for its name. If the switches in a panel are connected to a bundle called "PanelABC_switches", just hit Ctrl+F or Ctrl+Shift+F and search for "PanelABC_switches" and the that "somewhere else" will show up in the results.

 

[GLS]

I've got some bad news to report on the PRSD: I can't come up with an equation of state that works well (enough) to calculate the pressure inside the tanks... I tested a few, but they all fail in one way or another to provide a number, at least in the expected order of magnitude... :facepalm:
Can we hire some chemists? :shifty:

 

[Urwumpe]

I've got some bad news to report on the PRSD: I can't come up with an equation of state that works well (enough) to calculate the pressure inside the tanks... I tested a few, but they all fail in one way or another to provide a number, at least in the expected order of magnitude... :facepalm:
Can we hire some chemists? :shifty:

What goes wrong? Did you try it with saturated steam pressure?

 

[GLS]

What goes wrong? Did you try it with saturated steam pressure?

I either get negative pressures or huge pressures, or something sane that becomes insane if I decrease the mass (which we'll have to do).
I literally have no idea about "saturated steam pressure". I just used "more complex" versions of PV=nRT (which unsurprisingly also doesn't work).

 

[Urwumpe]

I either get negative pressures or huge pressures, or something sane that becomes insane if I decrease the mass (which we'll have to do).
I literally have no idea about "saturated steam pressure". I just used "more complex" versions of PV=nRT (which unsurprisingly also doesn't work).

Yes, but negative pressures also sound like you are using signed data where actually all variables should be unsigned.

Also, remember that the tanks operate by HEATING liquids, that is why saturated steam might be the better representation.

(In a saturated steam scenario, the temperature can not raise beyond the boiling point because there is still liquid that can boil away and consume vaporization energy)

 

[GLS]

Yes, but negative pressures also sound like you are using signed data where actually all variables should be unsigned.

The only "signed data" I can think of is the temperature, and I've learned years ago that Kelvin is the man. :lol:

Also, remember that the tanks operate by HEATING liquids, that is why saturated steam might be the better representation.

(In a saturated steam scenario, the temperature can not raise beyond the boiling point because there is still liquid that can boil away and consume vaporization energy)

I was going to use the same "system" as I did in the MPS He, but increasing the temperature when the heaters are on.

Let me play again with a parameter on the PRSV1 equation... it is used to adjust the equation to the real data... might manage to adjust it to something useful.

 

[Urwumpe]

Let me play again with a parameter on the PRSV1 equation... it is used to adjust the equation to the real data... might manage to adjust it to something useful.

I think we should agree on using SI units for subsystem simulations. :lol: Its just easier to avoid problems when interacting with Orbiter. Also we rarely have quantities that are really measured in imperial units in the telemetry. most are really 0 - 5V data that is later projected to the desired indication unit and scale.

If you want, I can make a code review there on Sunday or on Monday (AFTER the Shrove Monday Procession here in Cologne :lol: )

 

[GLS]

I changed the parameter to the other side of the parabola, and on the O2 side it's just too sensitive and goes insane even with a small decrease in mass, but on the H2 it works +/- as expected when decreasing the mass... but the temperature is super sensitive: going from 22K to 23K the pressure goes from 220psia to over 1000.... yeah, non-inert gasses aren't my area of expertise, so I'll go do something else. Call me when it's time to do the OMS/RCS pressurants .

 

[Urwumpe]

I changed the parameter to the other side of the parabola, and on the O2 side it's just too sensitive and goes insane even with a small decrease in mass, but on the H2 it works +/- as expected when decreasing the mass... but the temperature is super sensitive: going from 22K to 23K the pressure goes from 220psia to over 1000.... yeah, non-inert gasses aren't my area of expertise, so I'll go do something else. Call me when it's time to do the OMS/RCS pressurants .

Makes no sense to increase that much...

PV=nRT -->
P/T = nR/V = const (Charles's law)

P1 / 22 = P2/23 -->
P2 = 23 /22 * P1

So, it should go from 220 psia to 230 psia. And that is maximum. Now.. when you remove mass, only V is constant. Maybe you should consider using potential equations there....

 

[GLS]

Makes no sense to increase that much...

PV=nRT -->
P/T = nR/V = const (Charles's law)

P1 / 22 = P2/23 -->
P2 = 23 /22 * P1

So, it should go from 220 psia to 230 psia. And that is maximum. Now.. when you remove mass, only V is constant. Maybe you should consider using potential equations there....

That equation is just for ideal gasses, which O2 and H2 aren't....

 

[Urwumpe]

That equation is just for ideal gasses, which O2 and H2 aren't....

Actually, no real gas is ideal. That is what ideal is all about. :lol: And H2 is the real gas that gets closest to the ideal.

If you would calculate internal energy, you would need to calculate it differently for the two gases, compared to Helium, which is monoatomic.

[math]U = \frac{7}{2} N k_B T[/math]

This here is the better formula to approximate real gases, but again, it is an approximation:

https://en.wikipedia.org/wiki/Van_der_Waals_equation