Over the past few years, your voices have made it clear that the Tag Editor in 8.0 and 8.1 has not met expectations. Changes to the Tag Editor were merged and will be available in the nightly release (available 3/22/22, targeting the 8.1.17 release) that we hope will resolve several problems you have been most vocal about.
The changes we have made come based on forum post comments and feedback sessions with our customers. Our designers spent time analyzing where time was being lost and what elements made things inefficient for our users. While we could not accommodate all requests, we hope these changes are an improvement.
Our goal with these changes:
Fewer clicks: Trying to make changes to certain parameters in 8.1 required 2-3 more clicks than in 7.9. We wanted to lessen this burden on our users.
Keep tag properties in focus: When modifying expressions, bindings, alarms and event scripts the user had relevant tag information unavailable to them because they were moved to a new window within the editor. All those items are now dialog windows allowing the other tag properties to remain visible.
Maintaining context:
Tag browse trees in property editors would always collapse requiring the user to expand them repeatedly. Behavior now is more in-line with 7.9 where initial opening of the browser selects the tag you are currently editing, if you make a change then future tag selection windows will maintain the context you last selected
We brought back category panes within the Tag Editor to group properties together that should help users focus on specific things they are editing
When editing tags, users would frequently have to re-focus windows to the properties they were modifying. When the categories noted above are selected, the category selection will persist on the next tag they open in the editor if the category exists for that tag.
Only expression bindings now require opening the dialog to change. Tag and Parameter bindings can be edited in-line within the tag editor and are not shortened.
General usability items:
Sorting in UDT Editor now sorts like the tag browser (Folders first, then tags)
You can add tags in the UDT Editor without having to click the root of the UDT/folder
UDT Parameters now show when they are overridden
UDT properties are added in-line to bindings now rather than clearing out the content
Fix the alignment of property values (values are all left aligned now)
When Show/Hide Description Area is enabled, clicking on the properties show descriptions from the manual
We hope that the changes made are welcome ones. We would like feedback on the changes (positive and negative) and hope that you will continue to make your needs known regarding our Tag Editor.
You mean you didn't want to paste the tag JSON into the expression??
Looks really good though, can't wait to try it out! Definitely that drag drop would be nice, great suggestion! Dragging and dropping rom the tag property panel would be nice as well so that you could create bindings to tag properties as well
We are working to try and make this happen. No guarantees, but just wanted to make sure you know that the comment didn't go unnoticed. Thanks for the feedback!
I know 8.1.16 was just released, but we are coming up quickly to the end of the development cycle on 8.1.17. If there is any additional feedback on things you would want to see changed on this feature before release, I would encourage comments to this thread by 4/14/2022.
I just previewed 8.1.17 nightly build and like how the UDT editor shows the OPC path/expression in the main viewer. It would be super helpful if we could see a similar thing in the main tag browser window. In 7.9 there was a column select option for OPC Item Path. I always had that on. It would be very helpful for trouble shooting and design purposes to bring that back. Thanks
While not something that is likely to be addressed with this round of changes, this is something I will bring up with our Product Owners to understand why the change was made in the first place. I have a few theories but want to confirm them.
If we could bring something like this back, would making the column read-only in the Tag Browser be a deal breaker?
I, too, greatly miss seeing the OPC item path in a column. Tag group, also.
While those two are the only ones that bother me regularly, please consider making all known properties displayable as columns in the main list. For tags where a specific property isn’t applicable, show nothing.
Actually I would encourage it being read only. I figure if you are going to edit a tag property you should double click to bring up the editor. I also have a good case example. I am at a jobsite at the moment and have come across 3 different tags all with the same OPC Item Path. I think it is a training issue with the in house guys, but also they couldn’t see the value when glancing at the tags and they keep changing their naming conventions.
I’d actually forgotten this was a thing in 7.9 and just figured I always had to expand the tag and find the opcItemPath prop to see it. I do remember now that being able to see that was super useful without having to expand the tag though
Just looking at it now, don’t have a lot of time, but…
Being able to see and edit the opc item path now from the table without clicking lots of times is very nice
Not to mention now (again) being able to click through tags and compare their alarms and scripts without having to click many times to flick between panels and trying to remember what the last tag had
The count of alarms and tag script events is a nice touch in the categories. What I might suggest is adding that to history as well, or rather change slightly and make bold any categories that have non-defaults in them. E.g.
Feature Request:
Mass editing of UDT parameters on Instances.
It would be really nice in the new tag-browser to generate multiple instances of an UDT where you have an Excel / cell-based editing of all the custom UDT parameters at once. I was not able to do this in a very efficient way with the creation wizard unless I had simple words or numbers.
The way we do PLC programming with UDT is usually that we have a couple of Datablocks on the PLC where we have UDT Objects that are named the same as the physical device in the Field (eg. TT.01) so we have an User Defined Parameter on the UDT level where the Engineer types in the Device name and this becomes very repetitive as the setup is at the moment as the Engineers need to enter every single instance and change the parameter by clicking through.
The Wizard also only lets us create “lists” of tagnames if we have very specific syntaxes so that does not work too well in our case either and once the tags are created there isnt really a fast way to change the parameters. Our workaround to this issue at the moment is to export the tags to JSON and just create them in VS Code if we need to mass add tags, but it would be very nice to have a window of some sorts to mass edit the properties of multiple instances.
I don’t know if this is planned already or if others have faced this issue in general, but I feel like it would be a nice addition to the Tag Editor component.
Please make sure it doesn't overwrite default values if you don't provide params for all the UDT params, especially for nested udts. You should still be able to write blank strings to them though
@bmusson, we did implement Drag and Drop from the Tag Browser to the Expression Editor in the Tag Editor. We tried to make D&D from the UDT Editor work, but the only way to do it was to change existing workflows. The main issue was clicking on a new member within the UDT would immediately change the context of the member being edited behind the open expression editor. We felt this would lead to problems and the different solutions we discussed seemed to end up in more clicks or fragile code implementations.
@Michael1 and @pturmel, the primary reason the additional columns in the Tag Browser were removed was due to overhead of the required subscriptions that this feature needed. It was a cause for performance problems with large tag sets. That being said, we do see value in adding something like this back to the Designer and are discussing ways to bring this back.
@nminchin, the highlighting suggestion is something that we are still discussing with our design team to ensure that it would fit in with the rest of Ignition. It isn’t something that will be part of 8.1.17, but may make it into a later release.
Hey Garth, new editor has been great for me so far, cheers to you and the team for that! I’ve noticed one small issue in the alarm editor, specifically when working in a UDT. I’m still on 8.1.17 so apologies if it has already been resolved.
When creating an expression binding on an alarm property, there used to be a dropdown for UDT params - That’s no longer present. I’m guessing this is only an issue in the editor and will still function, but I haven’t tested it.
The changes are well appreciated. I have one item of note involving UDT parameters showing when they are overridden. I have a project which uses a particular UDT frequently. When I made changes to some parameters in the UDT, saved and refreshed the UDT and all the tags using the UDT, I found that the tags using the UDT did not change the parameters. What I saw was that the changed parameters had the original data, but were shown as overridden:
After removing the overrides, the parameters are showing the UDT updates:
I would have expected the changes to the UDT to propagate out to the tags, so that the incredibly tedious process of going in behind the change to remove overrides wasn’t needed.
