One issue that I come across somewhat frequently, is that a variable might be stored in the database as a numeric code, but we want to display it to the user as a more verbose description.
For example, our machines have a numeric status code, that we store. These codes are fairly meaningless to operators, and it's much more useful to display "running" than "200".
We have a dataset stored on a tag, which has as one column the raw numbers, and the other column a string describing the number.
However, I'm not sure how best to map them. One of my predecessors made a frankly terrifying power table in vision, which simply has two columns -- one which is hidden with the number, and one which is shown with the description. This technically works, but it's very annoying to work with, as any code that changes the table needs to manually update both columns at once.
There also seems like a way to do this using the configureCell script of a power table. However, making a blocking tag read call (to get the string mappings) for each cell in a table seems absurd. Does ignition buffer this info somewhat, or can I duplicate this data by binding a custom prop of the table to this tag, so the call only needs to be made occasionally?
Bing the dataset tag to a custom property in your Vision client. Wherever you have the live number and want to show the text, use an expression binding with the lookup() function to pull it out of the dataset.
In other context where you need to apply this to many rows of data, you would normally use a JOIN in SQL in your database to attach the text to each row.
Would it be more scalable to to do this in an expression tag? Assuming there are more than one client displaying this value. It's also more centralised this way too
The dataset is already in a tag. Doesn't matter what kind it is. The lookup is what needs to be in the client, because you will use the dataset for UI-driven dynamic substitution. So that part cannot be in an expression tag.
As an aside, if you have a status code for (nearly) every integer from 0-n, then an array tag might suffice. No need to keep track of an index when the array can be indexed natively (prevents duplicate entries, etc.). However, you mentioned that "200" = "running", so one might assume that a 'shortened' dataset with a lookup column makes sense here.
Aside from the extra gateway workload that can be avoided, an expression tag can only do a lookup for a code that is in a tag. Which means you cannot use it for tentative or intermediate values in the UI that exist before you write them to tags. And you cannot place the tentative values in tags if you want your client user interfaces to be independent of each other.
It also precludes easy internationalization on a per-client basis, if that becomes necessary. (Extra columns per language in the lookup dataset, for example.)
I stand by my advice: don't convert status codes or similar PLC values into descriptive strings in expression tags. It sets you up for later misery, and costs you gateway workload.
The statuses are fairly sparse. There are 50 statuses we have, and they range in number from 0-1000.
The machines we use have internal status values (with different meanings by machine), which we then map in the gateway to a second tag stored by machine, which all have shared meaning (eg, 100 is always "running")