Using multiple IF statements with OR in Tag Properties

[mhicks1]

Hello, I am trying to populate a Numeric Label Value using If Or, If Or…7 times.
IF the Material in a specific Bin is being used by any feeder (1-7) then display the Rate value of that feeder. I am able to get the value I want if I only use 1 If condition.

When I add the second If condition (after an OR at the end of the first If), All i get back as a result is 1 Has anyone needed to create code for a similar application?

Below is the Template for the Value and the code I am using. Thanks in advance for any help.

The numeric values at the end of each line prior to the OR are only used for troubleshooting. They will end up being " " or “0”

[witman]

Each of your if statements returns either the actual feed rate or the value after the second comma. The or instructions are then applied and return true or 1 as long as one of the if statements gives a non-zero result. Nesting your if statements would give you what you’re looking for:

if(condition,
	trueResult,
	// Each false result is a nested if.
	if(condition,
		trueResult,
		if(condition,
			trueResult,
			// Final false result for if all ifs are false.
			falseResult
		)
	)
)

Also consider replacing your tag() instructions with properties that use indirect tag bindings.

EDIT: An easier solution: replace the OR instructions with + to concatenate all the if results (seeing as you’ll have them return "" when they’re false). If you do this, you may need to convert the if results to strings and wrap the whole thing in a numberFormat.

[mhicks1]

Thank you for replying witman, I have tried using bindings instead of tags but I kept getting “Nesting not Allowed” errors. Would your suggestion work with nesting or would it have any nesting at all do you think?

[witman]

The second solution–the edit-- should work with just replacing your || with +. If you get a type error, surround your if true results with toStr(). The first solution will also work, but gets a bit ugly the deeper the nesting goes. The nesting referred to here is unrelated to the error you got.

The nesting error you had before was due to trying to include dynamic properties in a tag path in an expression without using the tag() instruction. You can’t do that. You can, however, avoid using tag() by using indirect tag bindings on custom properties.

To switch this to indirect tag bindings on custom properties:

1. Create custom properties for each tag you’re referencing via tag(). Something like feeder1Material, feeder1PercentSet, feeder1RateActual, feeder2Material…
2. Apply an indirect tag binding to each of those tag properties to connect the property to the correct tag.
3. Use the feeder1Material, feeder1PercentSet, feeder1RateActual, etc. properties in place of your tag() instances in the expression.

[mhicks1]

Hi witman, Thanks for the awesome suggestions. I used the EDIT you suggested and all it took was changing the OR’s to ADDITION and it worked immediately. I then modified a bit more to use some custom properties. See Below…

Thanks again.

[Dmart]

@witman
So I’ve seen you mention using the indirect tag bindings on custom properties vs. not using the tag() function. For the most part I’ve been using the indirect way for a long time.
But I’m kinda curious why you recommend doing it that way.

[witman]

@Dmart, a few reasons I avoid using tag():

1. Performance:

Nesting Not Allowed while using Properties in a Template to turn on a Light

Yes, there is. If the items that comprise your tagpath are updated, even if yielding the same result path, the entire expression containing the tag() function will have to execute. With indirect binding, this doesn’t happen. The strings themselves have to be reconstructed every time, even if not changing, slowing down the final expression execution. There are a few cases with computed gateway tags where the tag() expression is the only good way to do indirection, and the dynamic stuff above…

2. Readability: the OP's expression would be much shorter and easier to read if made of short custom property names rather than the tag() expressions.

3. Read/write Binding: This only matters when you need to write, but the tag() instruction doesn't support writing.

4. Flexibility/maintainability: I find it's generally easier to test/troubleshoot/add to something broken into simple component parts, rather than one big expression. Although I'll admit to creating a few multi-screen expressions early on, I probably wouldn't do that if recreating them now.