I thought I would start a thread to list some of the differences when upgrading from the legacy product to Ignition. Some of these things are minor, but when mass editing, it becomes a major problem.
Group expressions do not allow the same characters as FSQL.
com.inductiveautomation.ignition.gateway.web.pages.config.systemconsole.LogViewer$SerializableLoggingEvent$ClonedThrowable: Invalid tag path: '[.]Vac_Reciever_#1_Selected'. Illegal character '#' (Line 1 , Char 17)
There is also a difference in the the tag names in the expressions as opposed to FSQL.
[quote]{[.]Vac_Reciever_#1_Selected} as opposed to {Vac_Reciever_#1_Selected}
[/quote]
Control Logix tag OPCUA addresses are case sensitive. Kepserver did not care. There is also a need for "Global." in the address name which Kep did not require.
The first point is due to small differences between how FSQL parses item paths and Ignition. We can adjust it to accommodate some characters, like “#” in this case. Items names in FactorySQL weren’t really supposed to have too many strange characters, but sometimes they slipped through.
On the second point:
Both {[.]Vac_Reciever_#1_Selected} and {Vac_Reciever_#1_Selected} are equivalent in the group setting, and refer to an item in the group by that name. With Ignition, there’s a new situation that wasn’t available in FSQL - the ability to reference SQLTags in groups. Also, we had to reconcile the different syntaxes used by FSQL and FPMI to reference items. So, here’s what we have:
[tt]{itemname}[/tt] - Classic FSQL syntax, will refer to an item in the group called “itemname”.
[tt]{[.]itemname}[/tt] - FPMI syntax for an “absolute” relative tag reference. In a group, the root is the group- so this will ALSO refer to an item called “itemname” in the group.
[tt]{[]itemname}[/tt] - Fully qualified SQLTag reference, using the default tag provider. In any setting, group or not, this will refer to a SQLTag called “itemname” in the root folder of the default provider.
For the third point, I don’t think item paths should be case sensitive, so we’ll add this as a bug.
Regards,