- I'm thinking of a drop configuration which might speed up development.
- It will also update continuously (which may or may not be desirable). Your idea in post 15 won't, as far as I can see. The table will be generated on opening the view and that's it!
??
Don't support what? A column view that can do indirect binding? If that's what you mean, you are wrong. A column view can do exactly that:
direct binding, and expression tag binding, the column has the json/dict not what the json/dict would generate
I this pic shows what I'm talking about.
You keep saying this, in various paraphrases. Let me tell you again, in another way: you cannot assign to a table's data property in a script and expect to get bindings. Ignition doesn't work that way.
You have two choices:
-
Write a script or expression that will dynamically read tags, repeatedly, to supply live data to the table, or
-
Include a tagpath column in your table data that will be configured to use a column view. The column view would take the tagpath and indirect bind a live value into a label or some other display.
It's not an issue. It's how it's designed to work.
1 Like
K, that was my understanding. But seems some on here believe it should work. So I'll just accept the tables don't work that way and put in a button, it's an easy fix. It's not just tag paths, there's scripts on some that grab tags that fill out a full tag path, db queries, all sorts of stuff beyond what the table can handle. I'm good with that, a refresh button works just as well.Thanks all,jake
I think you misunderstood those "others" when they explained how it works.
And I think that's because you keep mixing up configuration and data.
So I'll try again: You're trying to pass the configuration where the table wants data.
If the configuration sets up a binding that generates data, you can instead generate that data, then pass THAT to your rows.
It's cool that you have a working solution, but I believe there's a fundamental misunderstanding about a very basic concept that you'll need to fix at some point, or it's going to bite you in the rear end very soon.
1 Like
So if the bindings are considered configuration and can't be generated than I can't do what I need to do anyway. So it sounds like I'm stuck with static data since the table is just too complicated and dynamic.
What do you call "static" data ?
You can very well pull the data dynamically from wherever it is, be it tags, database, whatever, then use it in your table. Just because you're not binding rows doesn't mean the data has to be static.
Static as in the cell is generated with a "value": "" instead of a binding.
Basically, the pic I uploaded, I need the cells to use those expressions, tags, etc. to display data rather than display the binding dict text.
"Complicated" means different things to different people. Consider sharing the full details of what you are trying to do. Or share with IA support if you don't want to share with the forum.
The sample bindings shown in your OP don't look that complicated to me. Describe how you are generating unit and unitn for your rows.
Compute those values in a transform in the table's props.data binding.
This will generate the data just as well as expression bindings on row.
Depending on what exactly are your data source and how you're pulling data from them, it might be a good idea to use middle-men properties to do some of the computation.
The code will grab all units. 123-4567 is an example. 123-4567 is the name of a udt tag derived from a udt with a ton of tags in it. The '-' is taken out for the unitn and the left number is used. So the direct bindings will be like "[default]unit/suctionpressure." Another binding would be "[default]unit"+tag("[default]unit/interfacefinaldischarge")+"pressure". Some will be sql queries. I won't know how many rows in the table, I will also have to inject "value":"" into columns where those tags don't exist on the udt. That's pretty much it.Thx,jake