[Proposal] Expand pneumatic valves to have a GUI and inversible

[Sinbiosis]

Expand pneumatic valves to have a GUI and inversible

Designers	Implemented	GitHub Links
Sinbiosis	❌ No	TBD

Overview

Pneumatic valves currently have no GUI to configure things like threshold or gain. Pneumatic valves also can't be inversed (explained below). This PR seeks to implement both features and to make inversibility a toggle within the GUI.

Background

Pneumatic valves are like transistors, but for pressure-based systems. The current implementation of these valves is limited and only acts like an NMOS transistor. The "inverse" of this is the PMOS transistor, which for the pneumatic valve, hence forth called the "inverse pneumatic valve", means it allows flow between input and output, but only when the control is 1 atm BELOW whichever port is the higher of the two. I.e. If output > input AND control - 1 atm < output then allow flow. If output < input AND control - 1 atm < input then allow flow.

Motivation

Having a GUI for the pneumatic valve can improve the intuitive usability of the valve. Additionally, being able to toggle the inversbility of the pneumatic valve can lead to a lot of FUN™.

[Sinbiosis]

Small correction in the inverse logic. It should be: "If output > input AND control + 1 atm < output then allow flow. If output < input AND control + 1 atm < input then allow flow."

[Partmedia]

Thanks for writing and submitting this proposal. Could you comment a bit on the use case for adjustable gain and inversions? Perhaps with a sketch with new interesting things that can be built using this.

[ArtisticRoomba]

Adjustable gain was actually something that someone thought about doing, was a comment on one of my PRs.

I will say that being able to adjust the threshold of activation (right now it's a static of 101.325) as well as the amount of gas moved between the outputs (it's just multiplied by 10) can lead to interesting and more advanced setups. I can see Oasis's air storage logic becoming much more robust, and self-venting designs becoming much "smarter".

[Partmedia]

I can see that too -- but since we're in the proposal stage, could you think about a specific setup that you could implement with the new feature? This would help us determine what is actually need in implementation -- think threshold min/max values, gain min/max values, etc.

[Aeshus]

Hey @Sinbiosis,

Thanks for jumping on the doc so quickly from your pitch earlier!

It looks like you might have accidentally edited the template instead of copying it. You'll need to move your changes to src/en/space-station-14/departments/engineering/proposals/¹ and revert the template before this can be merged.

Footnotes

1. To be honest, I'm just guessing it belongs there... ↩

[Sinbiosis]

Hey @Sinbiosis,

Thanks for jumping on the doc so quickly from your pitch earlier!

It looks like you might have accidentally edited the template instead of copying it. You'll need to move your changes to src/en/space-station-14/departments/engineering/proposals/1 and revert the template before this can be merged.

Footnotes

1. To be honest, I'm just guessing it belongs there... [↩](#user-content-fnref-1-e7538811e789fdf8ad6139d1818b993a)

I was wondering about that as well. The help doc didn't really help me figure out where to put it and I was a little too anxious to get this typed up. I'll move it and revert the template.

[Aeshus]

I was wondering about that as well. The help doc didn't really help me figure out where to put it and I was a little too anxious to get this typed up. I'll move it and revert the template.

Maybe this is something that would make sense to bring up during the next maintainer meeting? (tomorrow?)

Some of the development documents definitely need work, so it's great to have people looking at them and pointing out issues! Also, I remember hearing of some talks about redoing the current proposal system so there's also that...

[Sinbiosis]

I can see that too -- but since we're in the proposal stage, could you think about a specific setup that you could implement with the new feature? This would help us determine what is actually need in implementation -- think threshold min/max values, gain min/max values, etc.

So the specific case I was immediately imagining was a feedback amplifier that can be used for pressure regulation, such as in the burn chamber for the TEG. More generally, this inverse pneumatic valve will enable feedback systems that can be used for control systems. For a concrete example, observe the following:

This would be an example of a differential amplifier, implemented for a pressure system. Contrast it with the electrical equivalent circuit:

This can be used for sensing pressure within a system, compare it to a desired quantity, and then the amplifier adapts when the measured pressure deviates from the desired quantity. For example of that control, observe the following:

Here the amplifier is sensing the pressure in the example burn chamber. If the pressure is too high, then the amplifier activates another valve that releases the pressure until the desired quantity is reached.

Now, as to why this proposal is needed for this to work: the two pneumatic valves in the amplifier at the "top" need to be "p-type" or what I'm calling the "inverse pneumatic valves".

For the threshold min and max values: a reasonable range might be 1 atm to 10 atm, but no hard reasons for those numbers, at least for the specific example of control I've given. In electrical design, those values heavily impact what is called "head room" and "input common mode range" for the amplifier, but given the large numbers involved with the pressure system and the ideal nature of many pressure components, we'd need a threshold on the orders of 1000 kPa for the threshold to begin to matter.

For the gain min and max values: like the threshold values, the high pressure system numbers and the ideal components, this gain value, as implemented, doesn't have much impact on the specific example except only to influence the response time of the amplifier (what in the electrical world is called the amplifier's slew rate).

There would be many additional aspects of the pneumatic valves that would need to be characterized for the values of these parameters to matter. OR another example needs to be found.

I can tell you that one aspect that'll need to be modeled in order to avoid pathological processing is that the input and output ports need to have some impact on the flow rate through the valves, otherwise I risk having an infinite amount of gain for the amplifier, which could be bad.

[Partmedia]

Thanks for the write up. I'm not opposed to having settable gains and inversions, but perhaps you might like to reconsider whether this feature is the best way forward for having feedback control.

It would be cool to be able to make an "atmos op-amp", but I think it would be pretty clunky and impractical because you'd need to tune a lot of finicky "DC bias" values to get the output to "bias up" at the right "voltage".

I also doubt that such an "atmos op-amp" would actually work in-game, because of the way the atmos system works. The devices are not solved simultaneously like SPICE, instead, devices are iterated in an essentially-random order and so even a perfectly balanced two branches won't actually be balanced in game. And atmos makes no requirement that KCL and KVL are satisfied at all solution points. At best you might have an amplifier that oscillates around a bias point.

Further, I'd like to point out that complimentary devices are not strictly necessary for differential amplification -- before CMOS resistively-loaded, current-source loaded, and diode-loaded amplifiers were common.

So, an adjustable threshold/gain and inverse button could be useful, but I don't think for this particular application of feedback control. For feedback control, consider a 4 port device (in+, in-, inlet, outlet) that controls the flow between inlet and outlet based on (in+ – in-) or something.

[Partmedia]

P.S. Doesn't having a settable threshold eliminate the need for a feedback amplifier to regulate pressure? You could regulate pressure just by diode connecting a pneumatic valve and setting the desired pressure. That would be a pretty simple way to get pressure control -- and a reason to go ahead with this.

[Sinbiosis]

You are certainly correct that we can achieve the same effects through either four port devices and/or setting the threshold of the valve. I wasn't sure if just having a device that "does it all" would go with the core pillars of ss14 design philosophy. So I proposed this alternative. But if we're happy to just have settable gain, threshold, and inversion, I'm down for that. An advantage of the simpler solution would be greatly reduced cpu cycles needed and (hopefully) easily maintained code.

[Sinbiosis]

@Partmedia is this approved or am I waiting on something?

[Partmedia]

Sorry for the delay, thanks for the bump, good luck!