There're a few functions lacking in 8.1 from 7.8.5, what are ways to get the same thing

system.tag.getAttribute(unit, “Enabled”) see if the tag is enabled, seeing if the device is enabled should work but I only saw a way to enable or disable the device not actually see if it’s enabled, I see there’s an enabled tag property, but wasn’t sure if it’s the same as the tag being enabled, it talks about the group in the docs

system.tag.read - see the quality of the tag, I see nothing about getting the quality here in the new stuff

I’m sure there’s more I find, just going through the process of migrating. Thx, jake

To check tag quality from script, use this at the bottom of Paul’s post:

While the old tag read function still exists, it’s gone from doco an thus you should probably move to the new system.tag.readBlocking or readAsync in 8, which now take lists.

Maybe have a look at some things I found migrating from 7 to 8 as well that aren’t obvious from doco:

If I’m reading this right, it seems we need to use the undocumented read function to get the quality. Are they going to continue support this or are they going to expand the script functions to put this back in? Sounds like the enabled property will show if it’s enabled or not and I don’t have to worry about the groups in the documentation. Please let me know if I have this all right.Thx, jake

The new read functions still return QualifiedValue objects, so that part should remain unchanged.

Ah, I see what you’re talking about now I think. UDT instances have lost their ability to check their quality, which is what I used to do as well. I think you can read the enabled property on UDT instances now though…

You can check if a UDT instance (or tag for that matter) is enabled by reading the “enabled” property:

tagPath = 'path/to/UDTInstance'
t = system.tag.readBlocking([tagPath + '.enabled'])[0].value
print t
>>true or false

No, not at all (in fact, the legacy read function goes through the exact same code path as the new read function).

If you want to read the quality of a tag, you can either directly read the quality: system.tag.readBlocking(["[default]path/to/tag.Quality"])[0].value or read the tag itself, then extract the quality: system.tag.readBlocking(["[default]path/to/tag"])[0].quality - the two are functionally identical.

Awesome, thx, I’ll wait for your reply.

Ah, perfect, I’ll just leave my functions the same then. I was worried if they didn’t document it they were going to stop support it.Thx, jake

One more thing, can I reference styles I have in my project by just doing styles.status_red? I didn’t see anything about referencing this in script.Thx, jake

When you say ‘styles’, are you talking about Perspective Styles?
These you just apply to a component via the props.style.classes property as text

Yes, it was suggested to have my background color styles in the project and use them throughout.Thx, jake

Yeah, definitely. I have all of my colours in a custom css theme which I then reference the variables from my Perspective Styles. Using a CSS theme will then allow you to easily create alternate theme such as light, dark, colourblind, high-contrast, etc. in the future. Have a read of the readme.md inside the theme folder in the ignition data directory:
C:\Program Files\Inductive Automation\Ignition\data\modules\com.inductiveautomation.perspective\themes
You can reference css variables with: var(--<VARIABLE_NAME>) for example: var(--neutral-20) which is part of the light theme. You can use this in any property’s value, but obviously if it’s a colour, it won’t make sense to use in a non-colour property… You can put anything into a variable though, such as widths for certain things like standardised margins between certain components:
--cmp-margin: 5px;

Using these inside Perspective Styles then lets you standardise the look and feel of your various ui elements instead of having to reference a number of css variables and other css styling for each component.

When applying P.styles to components, you just add them as a space-separated list into the relevant styles.classes property

So session events there’s a Styles tree, do I just use the style names in there like status_red, or do i need to use Styles.status_red. Figured it would be similiar to calling script functions.Thx, Jake

You can right click on a style and copy the path to the style. I’d recommend using a folder structure, so you might have paths like: Devices/States/Running as a style path

Also, I updated my post above RE UDT instance enable:

Perfect, also, will the dataset in a table accept objects?Thx, jake

Objects? As in embedded views? Yes… Although it’s not quite that straight forward

like json, so it would have the value and style in it

Ah, yes. See the example in the data property

https://docs.inductiveautomation.com/display/DOC80/Perspective+-+Table

awesome, thank you so much.

1 Like