How to make a table to quickly view all objects associated with a controller?

Ignition
1

For commissioning and testing purposes, I would like to view a table that shows all the relevant objects from each controller.
Row 1 might be Controller1/Valve1/Position.value,
Row 2 would be Controller1/Valve1/EndSw.value, etc for ~20-50 rows.
I basically want a snapshot of all the I/O in a controller all on one page.

The tags in our database have ~100 sub-objects, only 2-3 being relevant, so I would pick those.

The left column would be the object/tag name, with the other column being the current value.
Looking to repeat this on many controllers, having clusters of identical programs.

For a beginner trying to bumble around with Ignition, hoping to find a more efficient testing process, what would be the best way to go about this?

Thanks!

2

I suppose it depends on how you want it to look.

I would probably just create a popup view with multiple status indicators on it. All with indirect tag bindings. Then just display the popup with the correct relative tag path for the device you want to look at.

There are other ways, but I'm not sure that they are what's best fit for the application without knowing more about what exactly you're trying to accomplish.

For instance you could easily write a script that reads a group of tags and then adds the data to a dataset to be displayed in a table. You could also loop through the tag values and add styling per cell to add some visuals to the display.

3

Hi there,

Thanks for the reply.
Aesthetics are not important. Mentally, I just picture a crude table. Colors, font, size don't matter.

As far as what data will be polled, there will be some clusters of identical programs.
Let's say I have 50 controllers. 5 of them have identical pump applications. 5 of them control identical water tanks. There are a few odd balls here and there.
They will all share UDTs though. But it would vary in how many and what type of UDTs.

I think I could figure out how to make a graphic specific to the common applications. A table graphic for pumps, another graphic with table for water tanks, etc.
Populate the table with tag paths, the suffix being filled in, with the prefixes being * wildcard or such parameter passed in.

My question is if there is some way to auto-fill or auto-create such a table. Or do the actions en masse.

I don't know enough to know how to ask this question properly, so I'm just asking what the best way to achieve the overall goal might be.

4

You can not dynamically create components on a perspective view (as far as I know).

You can dynamically fill a table on the view.

I would suggest that you have a go and come back with specific questions about specific problems. There are a bunch of ways to achieve something like this. The details are going to need to be tailored to your particular set up though.

I would suggest you look into creating a graphic with Indirect bindings. Start simple with just one value and see if you can get that working. Once you've got that expanding it to the other values will be fairly trivial.

5

Probably the simplest solution for this in a Perspective table is to use a nested column view (column render mode=view). Have your two columns in the table, but have the column that will display the live value actually contain the complete tag path. Then the nested view can indirect bind to obtain the live value. (Perhaps also obtain the data type, units, and number format pattern, to make it pretty.)

1 Like
6

Is there a way to refer to folders in the tag browser as indices in an array?

For example, rather than specifying a full path such as:
[TAG_PROVIDER]Building1/Floor1/Panel1/Valve1/Position.value
Could I do something like:
[TAG_PROVIDER]Building1[0][0][12][20].value
?
Maybe with less extended array dimensions, but still that's the idea.

EDIT: or ability to use wildcards in indirect tag path

To give context, this is all because the OPC tags are imported using a less than ideal [for this purpose] organization scheme. The tags are organized by room and equipment type rather than by controller.
So, tags from Controller1 can appear under Room 1 (Pumps), Room 2 (Fans), and Room 12 (Valves), non-redundantly.

R1/2/12 can, consequently, have tags in them from Controllers 1, 2 and 3. All tags being identical instances, respective to their parent controllers.