Table of Live Values

Ignition
,
1

We have a requirement to create a live table of all of the inputs to our system that is filterable. For example, the client would like to be able to see the live value of all of the inputs, all of the temperature inputs, all of the inputs in an area, or some combination of this. We currently have 100-150 inputs.

We have a script that is working but is pretty brute force (lots of single tag readBlockings, we’re recalculating the entire table from scratch every five seconds, no caching of results) that takes around 2.0 - 2.5 seconds to execute. Obviously this burdens the system down substantially. I think that we can optimize this approach some but I’m hesitant to spend a couple days working through this for an unknown performance improvement.

Is there a better way to do this? I would think that in an ideal world we could pass in a list of indirect tags into a column and do it that way. Is that possible?

We’re using v8.0.15.

2

you should try to bring in all tags in a single readBlocking. If done correctly you can prob get your result down to 1 sec or so. maybe put your tagpaths in a database table so you can filter thru a query. just a thought. Im not aware of a way would be more flexible and/or faster.

3

Use the script to build a list of the tags to read and use system.tag.readBlocking(paths)
Or if they are OPC Tags do the same but use system.opc.readValues(paths)
Then loop through the returned dataset and assign it to the table.
It is much more efficient to read an array of tags at once then it is to loop and do single reads.

4

Also consider writing your results to a dataset tag to keep the raw data. You can then do a single loop on the client to get your filtered data.

From a UI standpoint, perhaps something like a tree view could help set your filters.

5

Meh. I'd only do the tag reads after filtering.

6

Thanks for the comments. It sounds like the rough plan of attack would be to:

  • Create a sub-list of tags to read every time the screen is loaded or the filters are updated and store it in a memory tag
  • At the same time (screen load or filter update) read and store the non-changing values for each row (tag name, engineering units, etc.)
  • Use the sub-list in a single readBlocking on my update timer to populate the live values
  • Merge the non-changing values and live values into a single dataset to populate the table with

For OPC tags, does readBlocking use read the values in the Tag Browser or does it force the Tag Browser to get fresh values from the PLC as well? From an execution time standpoint, will the readBlocking most likely be my driving (slowest) factor?

@diat150, I like your database idea as a backup idea. I’m a little hesitant to try it first because I will then have another table to maintain (or create an automated maintenance script).

7

No. Current values are returned without impacting OPC subscriptions in any way.

8

you can try tag change event for quick response.

9

@BryanB
we’ve create a module adding some scripts functions for managing tags subscription and update a tag client dataset (Ignition 8.0 vision) only when the data change. If lots of value quickly change a max update rate (@250ms for example) for the tag client dataset can be configured in the module

The tag client dataset is binded to a powertable.

image
image1778×801 265 KB

3 Likes
10

@mazeyrat That is really nice looking! I’m very impressed.

Are you using tag events (on change) to update the dataset?

11

no all the job is done inside a module we’ve created with Ignition SDK. You can subscribe for tags values changed.
A memory table inside the module is updated when the tags values changed and the tag client dataset is then updated with a max rate.

A bit complex but much more efficient rather than polling tags with readBlocking…

1 Like
12

Hi BryanB, I also want to do something similar. already have the solution?