This does not work.
Note that the Description worked.
Actual OPC path for the alarm: ns=1;s=[PL_STACKER]PL_Stacker.Alarm[0].2
Parameters.
The alarm configuration with the parameter math.
Testing…
Both failed…
The non math reference obviously works fine.
Am I doing this wrong? The documentation seems pretty clear. Any suggestions?
Hi @tyrel.parker, I might be missing something but wouldn't your expression return a path of:
ns=1;s=[PL_STACKER]PL_Stacker.Alarm[0.125].2
I think the error may be resulting from the array index not being an integer.
If you're referring to the Bad_ReferenceNotFound, I think this is because the expressions are not valid tag paths.
2/16 as an int should be 0, so I should end up with ns=1;s=[PL_STACKER]PL_Stacker.Alarm[0].2
which is the intention.
But what you’re saying is that the parameter division is not doing integer division?
But if that is the case then why doesn’t the expression testing tags that I created evaluate either?
Apologies, I was incorrect, I got confused with Bad_NotFound. In this case it is because expression language is used for expression tags so it should be {POS}/16.
The OPC tag uses 'formatted string' to form the path, so {POS/16} is valid.
Just setting up a quick test to support the theory, edit incoming shortly.
The expression language is completely different to the basic parameter expression language. In the expression language, {stuff} tries to read stuff as a tag. It doesnt see stuff as a udt parameter you're trying to use. Have you tried your parameter expression inside the opcitempath?
What do you mean by 'alarm configuration'? Where is this expression used?
If this is in an alarm attached to the 'Alarm' tag as part of the set point's expression, you need to use the expression language to manipulate the value of the tag, you can't read the value of another OPC item
I believe you are correct. I did some additional testing and that is the problem.It evaluates correctly if I take out that division.
I assumed it would do int math since they were both ints and it does not. I even attempted to use a different parameter using the math and put it into an int parameter to use, but it still returns floating point.
Yes I have tried. That is the image that you have referenced.
That is the expression of the OPC path for the Alarm tag.
Seems like a good feature request to add basic type casting into the language
I just thought there is formatting! One sec, I’ll get an example.
I thought about that also, but I couldn’t figure out how to format it without the .0 after the number.
To format a value, use the form {ParameterName|format}. The format pattern is the same as that used for the numberFormat expression function. In short, "0" can be used to require a digit, and "#" can be used for optional digits. ie: ##0
I forgot about this @matthew.ayre. Shows how often I use parameter expressions haha
{PATH}.Alarm[{POS/16|#}].{POS%16}
Should work
I know the feeling 
, you mentioning type casting stirred the correct neurons into place 
are you sure I try and this does not work for me…
what I see:
{PATH}.Alarm[{POS/16|#}].{POS%16}
if pos is <=8 the result is 0
if POS > 8 the result is 1 …
I already make another discussion but I think is better to reopen this
https://forum.inductiveautomation.com/t/udt-parameters-division/59989
Hi @stra, this was working from what I remember 
. Looking at the date, I think it would have been tested in 8.0.x, what version are you using? Something could have changed in 8.1.x…