# Amount of Memory Tags Matter? **URL:** \ **Category:** Ignition\ **Tags:** ignition81\ **Created:** [December 4, 2025, 5:34pm UTC](https://forum.inductiveautomation.com/t/amount-of-memory-tags-matter/112622 "2025-12-04T17:34:30Z")\ **Posts on this page:** 17\ **Page:** 1
**Author:** ![Urvish\_Mehta](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/urvish_mehta/32/81912_2.png) [@Urvish\_Mehta](https://forum.inductiveautomation.com/u/Urvish_Mehta)\ **Post date:** [December 4, 2025, 5:34pm UTC](https://forum.inductiveautomation.com/t/amount-of-memory-tags-matter/112622/1 "2025-12-04T17:34:30Z")
Hello All, Very basic question and might have been brought up by someone else too, point me to right direction if thats the case. So question is I have fault codes for VFD and I have 1 memory Dataset tag which has list of INT vs String. this helps as codes stays with the UDT and next project ill have the list ready to go. Now each instance will have this tag on no scan but will be duplicated on instances. Is this a concern? I know example is for small amount of tags but thinking of standard approach and doing this on each device might matter. Let me know your thoughts. ---
**Author:** ![ryan.white](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/ryan.white/32/73193_2.png) [@ryan.white](https://forum.inductiveautomation.com/u/ryan.white)\ **Post date:** [December 4, 2025, 5:39pm UTC](https://forum.inductiveautomation.com/t/amount-of-memory-tags-matter/112622/2 "2025-12-04T17:39:22Z")
Are you able to have the dataset tag stored outside of your UDT in a common top level location in your tag structure? And then reference it via direct tag path instead of relative tag path in the UDT? If its in a common folder, you could export that specific folder and then import it into whichever gateway needs it when building another project. You could do this for all your devices and organize the folder by device type/version. ---
**Author:** ![Urvish\_Mehta](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/urvish_mehta/32/81912_2.png) [@Urvish\_Mehta](https://forum.inductiveautomation.com/u/Urvish_Mehta)\ **Post date:** [December 4, 2025, 5:51pm UTC](https://forum.inductiveautomation.com/t/amount-of-memory-tags-matter/112622/3 "2025-12-04T17:51:28Z")
Yes We used to do that before but then We have some other process tags having very few instances and we store dataset right to UDT but then we would have multiple approach in same project. trying to find out if having memory tag not on scan can affect project on what extent. ---
**Author:** ![paul-griffith](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/paul-griffith/32/37249_2.png) [@paul-griffith](https://forum.inductiveautomation.com/u/paul-griffith)\ **Post date:** [December 4, 2025, 6:28pm UTC](https://forum.inductiveautomation.com/t/amount-of-memory-tags-matter/112622/4 "2025-12-04T18:28:48Z")
This is a question that's hard to answer in absolute terms, because really it just depends. Storing a dataset with a few dozen rows and only two column across a few dozen UDT instances? Totally fine. Storing a dataset with thousands of rows and dozens of columns, across thousands of UDT instances? **Potentially** still fine, but definitely inefficient/wasteful. Storing a dataset with hundreds of thousands of rows across hundreds of thousands of UDTs? Definitely a problem. ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [December 4, 2025, 6:47pm UTC](https://forum.inductiveautomation.com/t/amount-of-memory-tags-matter/112622/5 "2025-12-04T18:47:44Z")
I'd say to not do that. Not disputing Paul's ranges of acceptability, but real systems grow and initial assessments will blow up in your face. (Just say **NO** to query tags in UDTs, too.) ---
**Author:** ![Nol](https://avatars.discourse-cdn.com/v4/letter/n/8e8cbc/32.png) [@Nol](https://forum.inductiveautomation.com/u/Nol)\ **Post date:** [December 4, 2025, 7:28pm UTC](https://forum.inductiveautomation.com/t/amount-of-memory-tags-matter/112622/6 "2025-12-04T19:28:33Z")
This just sounds like you want a lookup table to translate fault code 34 is XYZ happened? I’m assuming you’re trying to do this so you can display the text of the fault on the faceplate or dashboard. If so it’d be better served just storing the fault number in the UDT and then having a separate dataset with the fault code to string lookup that can be referenced at anytime. When you go to display the text you just grab the fault number then go fetch the string to display. You could still make this modular so that next project you just import the one Fault Codes tag in and then you would still be able to reference them. In your UDT just have a path to the location of the fault codes tag so if it has to move next project you just update that one UDT path and the rest would still work. ---
**Author:** ![nminchin](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/nminchin/32/6911_2.png) [@nminchin](https://forum.inductiveautomation.com/u/nminchin)\ **Post date:** [December 4, 2025, 9:05pm UTC](https://forum.inductiveautomation.com/t/amount-of-memory-tags-matter/112622/7 "2025-12-04T21:05:58Z")
In the same vein as what Phil said. Design for efficiency and scalability at the start. Don't wait for the project to scale up (and this includes if you ever reuse the project as a base for _another_ project which will be much larger) to realise the things you did, which you knew you probably shouldn't have, are now causing issues. ---
**Author:** ![michael.flagler](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/michael.flagler/32/26272_2.png) [@michael.flagler](https://forum.inductiveautomation.com/u/michael.flagler)\ **Post date:** [December 5, 2025, 5:20am UTC](https://forum.inductiveautomation.com/t/amount-of-memory-tags-matter/112622/8 "2025-12-05T05:20:02Z")
For this sort of thing, I have a project script in my gateway scripting project that I have the UDT run as a lookup for the code to string. This way it's separate and can be used by multiple UDTs if needed (like if you have a common set of error/fault codes) and since it's not doing any major work, I think a runScript() function in an expression tag should work without slowing things down. (Although I could be wrong, so we'll see if @pturmel, @paul-griffith, or @nminchin disagree because I'm sure they have more experience than I at this). ---
**Author:** ![bschroeder](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/bschroeder/32/13260_2.png) [@bschroeder](https://forum.inductiveautomation.com/u/bschroeder)\ **Post date:** [December 5, 2025, 12:13pm UTC](https://forum.inductiveautomation.com/t/amount-of-memory-tags-matter/112622/9 "2025-12-05T12:13:38Z")
A lookup() expression to a static dataset is how we do it. Typically for vfd/device faults etc... We used to use runScripts but we try to avoid those at all costs since they can get new engineers into trouble. ---
**Author:** ![MMaynard](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/mmaynard/32/3366_2.png) [@MMaynard](https://forum.inductiveautomation.com/u/MMaynard)\ **Post date:** [December 5, 2025, 1:36pm UTC](https://forum.inductiveautomation.com/t/amount-of-memory-tags-matter/112622/10 "2025-12-05T13:36:56Z")
Exactly how we do it, we put dataset tags in a root folder named for the drive type, then use the lookup function to get the fault description based on the fault id. Basically 3 columns, FaultCode,HexCode,Fault Then depending on the drive type and return, we either lookup based off of the Integer, or the Hex Example expression in a tag called FaultDescription in the UDT. ```python lookup( {[~]Global/YaskawaFaultCodes}, {[.]FaultCode} ,'No Fault Code Found' ,0 ,2 ) ``` ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [December 5, 2025, 1:41pm UTC](https://forum.inductiveautomation.com/t/amount-of-memory-tags-matter/112622/11 "2025-12-05T13:41:21Z")
The `lookup()` function is the right answer™, but **don't** put it in an expression tag (at all). It belongs in your UI, and the source dataset should be switched based on the **session** locale to provide multi-lingual support. (Or have multiple result columns, and feed the desired output column to `lookup()`.) ---
**Author:** ![MMaynard](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/mmaynard/32/3366_2.png) [@MMaynard](https://forum.inductiveautomation.com/u/MMaynard)\ **Post date:** [December 5, 2025, 1:44pm UTC](https://forum.inductiveautomation.com/t/amount-of-memory-tags-matter/112622/12 "2025-12-05T13:44:00Z")
How would you be able to use it in the Alarm displayPath then? ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [December 5, 2025, 1:48pm UTC](https://forum.inductiveautomation.com/t/amount-of-memory-tags-matter/112622/13 "2025-12-05T13:48:10Z")
You don't. You cannot make alarm display paths multi-lingual within the tags. You would have to use translatable keys in the display path and rely on Ignition's native translation functionality. ---
**Author:** ![bschroeder](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/bschroeder/32/13260_2.png) [@bschroeder](https://forum.inductiveautomation.com/u/bschroeder)\ **Post date:** [December 5, 2025, 1:49pm UTC](https://forum.inductiveautomation.com/t/amount-of-memory-tags-matter/112622/14 "2025-12-05T13:49:40Z")
Yeah... this is on our list of things to tweak and be prepared for. Thankfully at this point we aren't in an industry that is multi-national or multi-lingual. So that has not had a focus. I'll have to add it to the list of things to get done. 😃 ---
**Author:** ![MMaynard](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/mmaynard/32/3366_2.png) [@MMaynard](https://forum.inductiveautomation.com/u/MMaynard)\ **Post date:** [December 5, 2025, 1:50pm UTC](https://forum.inductiveautomation.com/t/amount-of-memory-tags-matter/112622/15 "2025-12-05T13:50:13Z")
We do, it works for our systems. 🤷 I do see where you are coming from and why you as a consultant have to think about things that far into the weeds. ---
**Author:** ![MMaynard](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/mmaynard/32/3366_2.png) [@MMaynard](https://forum.inductiveautomation.com/u/MMaynard)\ **Post date:** [December 5, 2025, 1:53pm UTC](https://forum.inductiveautomation.com/t/amount-of-memory-tags-matter/112622/16 "2025-12-05T13:53:16Z")
Hrmmmm… Multiple columns in the dataset tag for different languages and then based off of the locale, which column to use in the lookup. Might be overkill as most of the drive types we use the fault descriptions are in english anyway. But it is food for thought. We also do sort of use it the way you are describing in that if you select the Alarm from the alarm history component, we do a database lookup for SOP stuff for the operators. ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [December 5, 2025, 2:10pm UTC](https://forum.inductiveautomation.com/t/amount-of-memory-tags-matter/112622/17 "2025-12-05T14:10:28Z")
> [@MMaynard](#): > > think about things that far into the weeds. I have clients all over the world. And multinational clients. 🤷‍♂️