If-Then-Else structure in Distech GFX?

Is there an If-Then-Else structure in Distech GFX I just haven’t found? I get around it by using And/Or/Not etc. logic, but it always makes me scratch my head. I am a total newbie, so forgive me if this is too basic.

1 Like

@ControlFreak, this one might seem a bit puzzling at first, but it will make more sense over time. The short answer to your question is No.

If-else statements are already integrated into the control logic blocks. Let’s dive into some basic examples to clarify this.

Example 1: Understanding the greater than block in code.

greater than block

In code, this would look like:

/*
Our if-else statement:
If input1 is greater than input2, then output = true; otherwise, output = false
*/

if (input1 > input2) {
    output = true;
} else {
    output = false;
}

Example 2: Understanding the AND block in code.

AND block

In code, this would look like:

/*
Our if-else statement:
If input1 AND input2 are true, then output = true; otherwise, output = false
*/

if (input1 && input2) {
    output = true;
} else {
    output = false;
}

These examples illustrate how control logic blocks are translated into if-else statements in code. The control blocks simplify these logical conditions, making them easier to implement without writing explicit code.

Example 3: Lets combine the two.

image

In code, would look like:

/*
Combined if-else statement:
I am prefixing the inputs with their block name for easy understanding.
If greaterThanInput1 is greater than greaterThanInput2 AND and1Input1 AND and1Input2 are true,
then and2Output = true; otherwise, and2Output = false
*/

if ((greaterThanInput1 > greaterThanInput2) && and1Input1 && and1Input2) {
    and2Output = true;
} else {
    and2Output = false;
}


This makes sense, and I think basically what I have been doing. I’ve been doing most of this in Boolean situations (heat enable or flame detect), where I feed the input (true or false) into one AND block and another with a NOT block first leading into a different AND block, if that makes any sense? One runs the true case and the other branch runs the false case. I’ve never run anything in real life, so I don’t really know if this works? Your solution seems to work in a much more universal sense.

Sounds like you’re on the right track. Just remember most prebuilt logical blocks are themselves if-else statements.

Its up to you how you string them together to make if-else-ifelse and so on.

Thank you for all of your help. I really appreciate it. And I hope this site/forum goes far. It’s definitely exciting to be a very small part of it.

Likewise mate! Asking questions here that I can answer is super helpful in making this site not look empty and getting indexed on google search.

I imagine it will take some time to get traction (like anything new) I haven’t advertised it anywhere yet. I think there is a need for a board like this. Fingers crossed that I’m right :crossed_fingers:

Very much like your post today in r/BuildingAutomations about the “nerdier” side of BAS needing a bit of support! I love digging into things to understand “why?” and just not “how?” my mind just doesn’t work well in the “push this button, get this result” way. Also, I’m taking a Udemy Course on JAVA as per your direction. Really loving it! If asking you questions and getting AWESOME answers back is helping you…be careful what you wish for!!! (just really appreciate the help).

1 Like

Haha, please ask away! I’m always happy to help mate. I was once in your position, and still learning might I add!

1 Like

I will say all the majority of logic that you right is IF/THEN/ELSE logic.

If you think about it, it’s really that, just in block form. Even modulating control.

If we have fan status, the enable the PID loop and modulate the VFD. Else it goes to 0.

2 Likes

I’m slowly getting use to this! Something in my brain is balking because it doesn’t use the words IF/THEN/ELSE…I kinda got a simple mind most days. As always, thank you for your help! :monkey:

To break it down, always take the sequence of operations into chunks:

Let’s look at this sample sequence of operations:

HOT WATER SYSTEM SEQUENCE OF OPERATION:

OCCUPIED MODE:
If the building is indexed to occupied mode, determined by a BAS schedule, then the hot water pumps shall be energized. Else, if the building is indexed to the unoccupied mode, the hot water pumps shall be de-energized.

FREEZE PROTECTION:
If the outside air temp drops below the freeze protection setpoint (adjustable), regardless of occupied status, then energize the pumps. Freeze protection mode shall be released when the outside air temp rises above the freeze protection setpoint plus a threshold (2 deg F, adjustable)

Basic sequence and there could be so much more to add but here’s the gist:

We need to turn on the pumps when we are occupied or freeze protection mode. We turn the pumps off when we are not occupied and not in freeze protection mode.

So your if statement would look like this:

IF OCCUPIED OR (OAT < FREEZE_SP) THEN PUMPS = ON
ELSE IF !OCCUPIED AND !(OAT < (FREEZE_SP + DB)) THEN PUMPS = OFF

Don’t think about this from a java or c++ or any other language perspective. Look at the objective at hand.

So the pumps are on:
A) When we occupied
OR
B) When the OAT is below the setpoint

Pumps are off:
A) When we are unoccupied (schedule is off)
B) Not in freeze protection mode (OAT > SP+DB) (provided we were in freeze protection mode in the first place)

Now that we have that in mind, we can start to build our logic:

Occupancy is usually a schedule of some sort.
Freeze protection logic is based on a comparison of temp and setpoint. While we could be that logic with latches and all there, there are blocks that do it for us (TStat, Hysteresis Block, etc)

Let’s start with occupancy:

OccSchedule is turned on and off by time of day. I threw an OccMode Boolean in the middle to override the occpuancy of the system (optional, wasn’t a part of the sequence).

So IF my OccSchedule is on (occupied) THEN I turn on my pumps ELSE my pumps will be off.

Now let’s add the freeze protection in mind. Again, we could go with logic we practiced in one of the labs here on DDC-Talk, but that’s a lot of effort when we have blocks that will do all of this for us.

We’ve got the TStat block in Niagara’s kitControl and if you’re using 4.15 (Currently I’m still in 4.13.3 because of our Edge files (though I have non Edge versions of workbench I develop in), you will have their Hysteresis block that can turn things on and off by separate conditions other than the Tstat. The image below shows the TSTATB from AX Community. Again you can go about it a variety of ways. It’s just a matter of preference.

Regardless of what block (or groups of blocks you use) If then Else is implied. In my example, if the OAT goes below my OnSP (FreezeSetpoint), the TstatB block turns on. If the OAT is above the setpoint plus my deadband here, the TstatB block turns off.

Eventually you’ll learn what blocks do what.

Now that we have that piece, we can put the two logics together in a variety of ways:

The first way is to set the “null on inactive” property of my TStatB to true, which will output a NULL if we aren’t true. This means I can input this directly to our priority array of my pumps:

Therefore I don’t need to use an OR block to combine the logic. I can certainly to that if I wanted to like so:

I’ve accomplished what I wanted with only having one wire going to each pump instead of two.

Regardless if your approach, you get the same desired effect.

1 Like

I will now alway think of blocks in this If/The/Else respect. It does help. I do like the first version, without the OR block as it makes sense that the freeze control comes at a higher priority, but also see how it doesn’t matter much in this case. And through this example I’m starting to see the use of “Null on inactive” which allows the lower priority signal to get through? I do have a question about the TstatB. I keep hearing about hysteresis blocks but I can never find a “hysteresis block” in my limited knowledge. So I’m assuming that the TstatB is the hysteresis block in this problem because it provides a dead band? Always thankful for your first rate help sir.

So the TSTATB is in AX Community and I would consider that a true Hysteresis. It turns on a certain setpoint and off at a certain setpoint. It works like the hysteresis block in GFX.

Hysteresis block is available in N4.15 in kitControl

1 Like

I’ll have to look into the hysteresis blocks when I get N4 access back. I lost it after my TCP class but think I can “procure” access again after this CCT project I’m working on. I’m hoping eventually to take the next level of training in N4, but I don’t think I’m ready yet. Do people in this community have experience in CCT?

1 Like