Sorry if this has already been answered somewhere above.
I have a table that I am wanting to track various motor data in (Temp, Vib, etc.) Would it be possible to dynamically change the data binding to corresponding dataset memory tags based on the value of a drop-down list, or will I have to caveman it and just make tables visible based on the value of the drop-down list? I have 200+ motors to track...
I have tried figuring something out in excel, but I don't know enough about the system to wrap my head around something that would work, so I want to try with ignition if possible.
Sure. That's called indirect binding. Have your dropdown carry the appropriate memory tags' paths as extra data. Feed that to an indirect binding for the table data.
I apologize for my ignorance. How do I perform this task. I tried indirect but I am not able to create the full list. I am trying to achieve this in perspective.
Sure. I presume your memory tags contain all of the tag paths and descriptions you need for your table. (You've done one of these groups?)
I would do this:
-
Make a view custom property tableDataTag that will hold your current tag path string that the table will use in its indirect binding. Add an expression binding to this property that will supply a constant string tag path for the view's startup value.
-
Make a dropdown component that will display the choices for your dataset tags. Use a bidirectional property binding from the dropdown's props.value to view.custom.tableDataTag. Construct its props.options with content like this:
[
{
"value": "[default]path/to/dataset/tag/1",
"label": "Visible Name for Dataset #1"
},
{
"value": "[default]path/to/dataset/tag/2",
"label": "Visible Name for Dataset #2"
},
{
"value": "[default]path/to/dataset/tag/3",
"label": "Visible Name for Dataset #3"
},
{
"value": "[default]path/to/dataset/tag/4",
"label": "Visible Name for Dataset #4"
}
]
(You can copy that JSON and paste it directly on your dropdown's props.options to get started.)
-
On your table, make an indirect tag binding on props.data where the path string is just {1} and the reference for 1 is {view.custom.tableDataTag}.
-
Presumably, your memory datasets contain columns where the values are the tag paths for which you wish to display live data, and the table's props.columns specifies render mode == view for those columns. The actual nested column view would itself have indirect bindings to subscribe to the live tag values (and format and units, perhaps).
1 Like
I was planning to create a dataset memory tag for each motor in question. I have done something similar to this in a vision project to live update another computer running the same project, where the table writes to the dataset tag on a cellEdited, and the table data is bound to its corresponding dataset tag. I presume this is what you are referring to, but I want to make sure it will work in this situation. I have set up all the bindings in which you spoke of, I just need to update the dataset tags to actually contain data, and I would expect my errors to disappear. (They currently read NULL)
Is there any reason why you are not storing this data in a database? Simple select / insert queries are probably simpler than making 200+ datasets for motors.
1 Like
I'm open to the idea because making all the tags does sound daunting. I just don't have a lot of experience with queries. I'm still learning a lot about Ignitions abilities.
How often would you have a table open for a specific motor? How long would you be holding onto the data for a motor? Would the data entry be automated or are you relying on operators to enter the values every time?
Do you have a mockup of how you want this to look and behave? I'm not sure I interpreted your intentions correctly.
Technicians would be entering the data themselves. We would update the data once a month as part of a PM. As far as holding onto the data, I would assume we would wipe on a yearly basis or on a bad motor swap. I would have to iron that detail out with our PM planner.
I would re-create something similar to this in perspective, and have the table show the relevant data based on the circled drop down.
I would store this data in a database. For how little data you are storing per motor you could easily store several years worth (or back fill existing data).
I personally would have 1 db table to track motor serial number, location id, and install/activation date and have another db table that stores the inspection information.
This would allow you do long term trending on the information you collect, if you decide to do so.
4 Likes
I concur with Ryan. This is not a job for tags, but for a custom database. You may want some scripting to capture the data if you have these vibration sensors connected for data collection.
I would make an extra table in the DB that contains the names of your groups of motors, with a unique ID, and use that ID as a foreign key in the table that lists all of your motors. The dropdown in perspective would simply list those names from an NQ, and the table would be driven by an NQ that uses the dropdown's selected group ID.
4 Likes
