It doesn't seem to substitute the PathToTag into the expression.
I've also tried creating a custom "Path" prop that's bound to {PathToTag} but then I get a script error.
Some UDT meta parameters are automatically substituted in before they're handed off to the rest of Ignition, including expression evaluation, for processing.
I know that UDT params evaluate to their live value in opcItemPath. Tested on my end (8.1.41) and it seems that the expression prop does not evaluate in the same way (at least not in the tag browser - I'll defer to Paul wrt the behavior under the hood).
You have an extra parameter in the runScript. You also might need it to be False instead of "False", if it's needed at all.
A few more things I noticed. Your script console test passes a string to *.path, which I assume you evaluate with system.tag.read*? This returns a path that includes the [tagProvider]. {PathToTag} does not include the [tagProvider].
Further, if you're using doing a system.tag.read* on {PathToTag}, you'll get that tag's value, not its path.
Provider or not, doesn't matter. My script creates relative tag paths and reads them.
The path is being passed to the script so that it can create those relative paths.
def histArrayToDataset(path, rev = False):
'''
Create a dataset of historical records (no dates).
Historical record paths are created based on relative paths.
Call from the "Chart" dataset tag that is contained in the same folder as historical records 0-9.
Args:
path (string) : path to the resulting dataset chart tag
rev (bool) : reverse order. Default 9 -> 0.
Returns:
dataset (dataset) : dataset with historical records
'''
#get parent tag folder path
parentFolder = path.rsplit('/',1)[0]
#append tags to read
if not rev:
tagsToRead = [parentFolder+'/'+str(num) for num in range(9,-1,-1)]
else:
tagsToRead = [parentFolder+'/'+str(num) for num in range(0,10)]
#read the value for historical data points
histData = [tag.value for tag in system.tag.readBlocking(tagsToRead)]
#print histData
#dataset headers and empty data list initialization
headers = ['t_stamp','value']
data = []
I see - thanks for providing the script. Loosely tested in the script console on my end. It makes sense and seems to behave how I'd expect.
I'd try setting up some loggers with system.util.getLogger to verify the {PathToTag} is getting sent correctly. You might also have luck passing {[.].path} instead of {PathToTag}(Edit: Made dumb mistakes. See later post)
that's basically what I was trying to do with the custom path property, bound to {PathToTag} I can even see the entire path in the property in the tag browser.
Sure, I understand that's what you're going for. But you'll want to set up a logger, print to the wrapper logs, return the path early, etc to 100% verify that runScript is passing the correct parameter.
Also, just want to echo my earlier note about False vs "False". Python truthiness will interpret the latter as True, as it's a string with len() > 0. It's not affecting the current issue, but it might cause you headaches in the future.
I did some testing, and using {PathToTag} without quotes works fine.
As @Cory.grube mentioned, you'll want to take your "False" out of quotes.
I suspect the reason it may not be working may be two-fold. You're not returning anything from the script you provided. It's also possible you don't have your Gateway Scripting Project configured to the project your script is located inside.
Edit: One other thing is that in the tag browser, the expression doesn't populate with the path to the tag and stays as {PathToTag} so if you were looking at that as your troubleshooting, that won't work, and you'll have to follow the advice of others and do some logging to see if your values are getting passed properly or not.
There is a return statement, I just omitted the creation and return of the resultant dataset (for no real reason) - but you can see the successful return of a dataset from my first post
@sebastien_ng the rev parameter's default value is False.
I am getting a dataset returned now with runScript("Common.Data.histArrayToDataset",5000,{PathToTag},False) but it has 0 rows.
Path passed with runscript, from my logger: path : Pumps_Motors/2112-WP/Runtime_Starts/History/1/0/Chart
So, it doesn't pass the provider for some reason, but if I create a custom "path" property on the tag and bind it to {PathToTag} it does include the provider...?
but now I get an error when trying to pass the custom property
path is a property that natively exists on tags/folders/etc, but isn't usually visible in the tag browser. I'm kind of surprised it let you create a custom property called path. That may be leading to the inconsistent {PathToTag} behavior.
I suspect your custom property is being silently ignored, but haven't tested. You could try removing your custom path and again passing {[.]this.path} or {[.].path}.(Edit: Made dumb mistakes. See later post)
I thought that might be the case as well.
I have tried {[.].path} with no luck
I can read [Water]Pumps_Motors/2111-WP/Runtime_Starts/History/1/0/Chart.Path with system.tag.readBlocking() so I should have access to it from the expression within the UDT, right?
Yup, you should be able to access it from anywhere.
Big apologies, I made some very dumb mistakes on both of these suggestions. I'll update my previous posts.
First, I had the context for the relative path {[.].path} wrong. This would actually return the path of the parent folder, not the path of your expression tag.
Second, I had the syntax wrong for the this keyword. Correct syntax is {this.path}.
Below are example outputs for {[.].path} and {this.path}:
Thanks for the update. No, {this.path} does not work either.
Just for S&G I overrode the expression on the instance with a string literal with the path with the same call and it should work, if the string can get substituted in there.
The typecast bit is interesting - I'm guessing the path ends up being passed as one of the Java tag path types (BasicTagPath?), rather than a string. Doesn't change much - I'd just typecast it as you did.
