Propagating edits in a table using cell update

I am new to Ignition, please be kind to this rookie.

I have a properly populated tag structure built with nested UDTs. The data from the PLC I am connecting to is properly read. I can also type in values in the tags, which are properly written to the PLC.

I have created a window with a custom property, the type of which is one of the UDTs. I have bound this custom property “bidirectional” to a tag in the tree. In the window, I have created a table (and a Power Table) and used a “cell update” binding to create bindings to parts of the custom property. The values are properly displayed and updated (the bindings work). I have marked some columns as available for edit, and I am able to type in values in these columns.

The problem is that the value I type is in not propagated back to the original tag, and the displayed value immediately reverts to whatever is in the “parent” tag. Essentially, the data is read-only even if values can be typed in the cells.

In the Power Table, I have enabled the “onCellEdited” function and uncommented the last two lines as suggested in another forum post, which does not have the result I am after. I have also added a few “print” statements to make sure the event fires (it does).

Any help would be greatly appreciated.


I don’t believe cell update bindings can be bidirectional.

BTW, that’s a really ambiguous username…

Sorry about the username, this was probably inferred from the special purpose email I used to register and I did not notice. I changed it.

1 Like

About the cell update bindings not being bidirectional, this is a bit surprising (to me as a newbie) after being exposed to other Ignition mechanisms. It seems it “should” work in a plug-and-play manner (as an optional behavior).

Is there a way to have the cell editing event identify the source of the data, and write to it?

Please note that I ended up creating a template, adding controls bound with indirect tags on that template, and adding custom properties to the template (essentially strings needed to recreate the appropriate indirect tag paths). Then on my window, I created as many instances of the template as needed.

This ends up being a better solution, as it gives me full flexibility in terms of formatting and the types of controls used, while also being much cleaner (the cell update binding required each individual cell to have its own specification, so there were a lot of very similar paths only differing by index numbers).

I still see the interest in making cell update bindings writable, but my immediate problem is solved.

1 Like