I'm assisting in a proof of concept project to get some machine data from Ignition through the Cirrus Azure Injector into Azure, etc. I haven't done this before. We have the luxury of starting off from scratch and not having to use any predefined tags, etc. I have been unable to find good answers to the following questions:
Folder structure
The overall scheme will follow the usual Country/Plant/Section/Line/Station/Actuator/Sensor structure. If a plant's Ignition gateway is the edge device (not to be confused with the Ignition! Edge product) do we start the tag folder structure at Section/Line/...
Spaces or underlines?
Which? Spaces would make the tags more human readable by the non-engineering user creating a Power BI report or similar and while Ignition handles them OK in most cases there are many posts on this forum recommending their avoidance.
Doesn't Azure try and force it's own device architecture onto your data? I didn't think you got much autonomy on your structure as it all appears as groups under Edge Nodes?
I hear licensing on this is very expensive every year...
I might start here, then play with the hierarchy to see what limits they impose on you. Ideally you would define the entire tree in your UNS, with the view that when you combine hierarchies, they sit alongside each other in the same tree. Inside Ignition, I believe that you only share the "Edge Nodes" folder of tags up to the cloud, so you need to work out if you put the whole tree structure in the Edge Nodes folder, or whether you can configure the injector to push your tags at the required level in the cloud UNS.
I said a few weeks ago to Phil, but I've been using spaces in my tag names for 8+ years without any issues... so that's my preference. I would like to know exactly what scenarios are incompatible with spaced names though, apart from the dodginess of binding directly to a UDT instance (which is an abomination anyway, if you ask me) (in this case, you end up with spaces in the resulting object key names, which is very illegal)
I'm interested in the answer to your first question as well, as i've never yet had to do such a project. I suspect that it's going to be to copy the same structure as global as this will significantly simplify your bindings and references to tags in general, and mean you can use graphics interchangeably. It might just look a bit dumb from the site's perspective, and to an operator selecting trend tags etc.
When working with dynamic user interfaces, where some memory tag or a browse result drives the UI (hopefully cached if the latter). you generally want Perspective custom properties that reflect multiple tags with a selection nested tag properties. If you put spaces in your tag names, you cannot do this (invalid keys--not json-compatible). In extreme cases, you might want part of the folder hierarchy too, so spaces in folder names can produce the same broken objects.
Make tag and folder names that are valid JSON/Jython identifiers.
I’m a fan of no spaces, purely because html encoding butchers things with spaces, so any parameters that end up as a REST endpoint get butchered. Also you can use camel case and ditch underlines completely as well. Then your habits work in python nicely too.
To add to that, you’ll probably get rsi if you use underlines frequently, it’s not ergonomic to use the double key combination
Maybe it's a misunderstanding, but my first thought is that there are many ways to accomplish this example though that don't use tag paths as keys.
Random thought aloud, if there was ever a time that IA moved to storing tags with their names as the keys within a dict instead of as lists of dicts with the tag name in a "name" key, this would certainly require no spaces.