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].valueor read the tag itself, then extract the quality: system.tag.readBlocking(["[default]path/to/tag"])[0].quality - the two are functionally identical.
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
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
