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.
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.
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.
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.
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.)
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.
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.
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).
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.
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.
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().)
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.
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.
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.
