Derived Tag - Text to Integer shows Uncertain Value

Ignition
1

This should be simple,

image

I have a state in text datatype, and want to convert it to integer for read/write using multistate button.

Derived Tag shows uncertain value, why?

Read Expression:

if({source}="Off",0
if({source}="Ready",1
if({source}="Running",2
if({source}="Fault",3
99
))))

Write Expression:

if({value}=0,"Off",
if({value}=1,"Ready",
if({value}=2,"Running",
if({value}=3,"Fault",
""
))))

image
image567×521 32.2 KB

2

Have you set a value yet?

Comments:

  • "I have a state in text datatype ...". There is no text datatype. There is string, string array and document. Did you mean "string"?
  • Storing status as text would generally be considered as bad practice. You wouldn't do it in a PLC and you shouldn't do it in Ignition. Instead use integer datatype and use the tag's Meta Data | Documentation to explain "0 = Off, 1 = ...". Convert it to text at the point of display.
  • Use one case instead of four if comparisons.
case(
    {value},
    0, "Off",
    1, "Ready",
    2, "Running", 
    3, "Fault",
    "Invalid status"
)

But you won't be storing text now anyway, will you?

3

Yes I meant string datatype.
I developed a state machine using SFC.
Only for proof of concept, I decided to use string so its easier, why wouldn't I if you can treat anything to string like any other datatype. Once step easier, as you don not have to decode.

I also want to learn the limitations of using string, i guess this is one of those.

Anyway, instead of MultiState button which outputs only integer, i might as well just use standard button, i find multistate button not so flexible.

4

Except that you almost always do. Which is actually the topic of this thread, you’re just going the other way.

There are many reasons to not store status as a string. The most basic being that many times it takes far more memory. This is because a string must be able to contain up to the max length allowed, which means either the memory is allocated at some fixed max length or when the string is modified the system allocates more. This is often times unimportant in a SCADA system, but in a PLC or other small memory devices it needs to be thought about.

It is also very common to use bits in a single integer to represent your statuses, so instead of using 0,1,2,3 as your statuses you would use 0,1,2,4. This way in the device you can use the bit as a Boolean value on a contact rather than some comparison operation. This also has the effect of being more performant in the device.

2 Likes
5

Got it, I may just use best of both worlds then.
Use integer/bit on the core. and as soon as it enters high performance system (ignition tag), convert to string (learned about derived tags - this should be high performance conversion) - instead of converting on the point where I needed.

This way, if my system needs string, there is already readily available. Both string and integer format.

6

That's a terrible plan. Convert to string on demand, in the UI. Converting to string on everything doesn't scale.

7

I don't have to recall, every time what integer means...
hmmmmm... ahhh, a function call to convert on demand.. and a lookup table...! yeah..?

But again, if I am certain my UI will always be Up like on overview screen.. and Use by multiple machine tiles. Might as well convert it on the core (on the tag as it comes in).

usage dependent that is.

8

Except that perhaps you may need to change the string, like for supporting multiple languages. Just leave the tag as an integer and convert when and where it’s needed on demand.

Really. There is a reason we’re all saying the same thing to you.

2 Likes