Config Error when setting OPCItemPath using script

Ignition
1

I’ve written a script to set all OPCItemPath’s in a given UDT instance, based on a set of rules for the type of plc I’m talking to. It seemed to work perfectly and I was very happy with it, up until the point I changed some of the scan classes for some of the tags in the udt to leased.

In my script, I create an array of tag paths pointing to the OPCItemPath for each tag in the udt, and an array of values the OPCItemPath’s should be set to. I use the system.tag.writeAll function to perform the write.

As I said, this was working perfectly, but later on I started to notice that some tags weren’t good and that their OPCItemPath wasn’t being set anymore. I didn’t get any indication of a problem from the logs. I then changed my writeAll call to writeAllSynchronous, which did generate an error message in the log.

([Logix V1]JCB/ES1/Device/Name, valueChanged) Error executing tag event script: Traceback (most recent call last): File "", line 16, in valueChanged File "", line 58, in setOPCItemPaths ValueError: Error writing to tag "[Logix V1]JCB/ES1/Alarm/PV/SetPoint/Set/Severity.OPCItemPath": CONFIG_ERROR

This was one of the tags I had changed the scan class from direct to leased. I tried changing that tag back to direct, and it didn’t fail on it, but failed on the next leased tag encountered.

Through trial and error I discovered that everything works fine if I set the Slow Rate to any value but zero in the leased scan class, but setting it to zero will not work.

For now, I can workaround by temporarily changing the slow rate when I want the script to run, but is there anyway to fix this permanently or am I doing something too unconventional?

My version is Ignition 7.9.0 (b2016101208) on Ubuntu 16.04 server (amd64).

2

Leased scan classes are only useful to reduce bandwidth consumption for display tags (bound to properties in client windows). Nothing else will “lease” a tag, making its value available when the slow rate is zero. The last time I played with this sort of thing, access to a tag with scripting does NOT trigger the fast rate of a lease.
To gain the best of both worlds, consider using tags in a leased scan class for all your client displays, and use system.opc.* for any access in gateway scope.

3

Thanks for your response. Indeed, the writeAll function won’t trigger fast rate for the leased scan class, so when the slow rate is 0, I can’t perform the write. I did find another way to get it to work though by using system.tag.editTag instead, and I’m now able to set the OPCItemPath’s for an entire udt instance, regardless of the member tags scan class.

Here’s an excerpt from my script library to demonstrate:

myOverrides = {} for tag in browseTags: udtMemberPath = tag.path[len(instancePath)+1:] opcPath = "[" + device + "]" + tagPathToOPC(tag.path, instancePath) myOverrides.update({udtMemberPath:{"OPCItemPath":opcPath}}) system.tag.editTag(tagPath=fullInstancePath, overrides=myOverrides)

4

Do you have any issues with the edit tag functions taking a long time? I am doing a similar function where popup screens overwrite the OPC item path of tags within. The only issue I have is that it takes about 4 seconds for the buttons to be available. Below is an example script

system.tag.editTag(tagPath=“Motor_FVNR_AMPS”, attributes={“OPCItemPath”:“ns=1;s=[LOD_W_CRUSH_TCC]Pomace.East_West_Belt.Amps”})
system.tag.editTag(tagPath=“Motor_FVNR_HOA”, attributes={“OPCItemPath”:“ns=1;s=[LOD_W_CRUSH_TCC]Pomace.East_West_Belt.PV_HOA”})
system.tag.editTag(tagPath=“Motor_FVNR_RESET”, attributes={“OPCItemPath”:“ns=1;s=[LOD_W_CRUSH_TCC]Pomace.East_West_Belt.PV_Reset_PB”})
system.tag.editTag(tagPath=“Motor_FVNR_BYPASS”, attributes={“OPCItemPath”:“ns=1;s=[LOD_W_CRUSH_TCC]Pomace.East_West_Belt.PV_Rot_Bypass”})

window = system.nav.openWindow(‘PU/Motor FVNR’, {“STATUS”:“Pomace/EastWestBeltStatus”})
system.nav.centerWindow(window)

5

I haven’t had noticed any issues with using the editTag function to override OPCItemPath, but I don’t use this in popups or any other graphical components. I use it in a global shared library and it’s only called when creating or updating a tag or data type instance. It might not be the editTag function that’s delayed in your case, rather the time it takes for IO to bind after changing the OPCItemPath.

1 Like