Is DataPointWrapper object accessible for a runtime object?

[phildunlap]

Hi Aldo,

There is not a way to work backward from the context point's variable name or the object that describes to its point that I'm aware of. There may be some fancy way using reflection but it's probably not worth it.

The solutions right now would either be to write your script to acquire its list of points from the DataPointQuery.query(RQL) method or to have some object that makes the desired information explicit, like this python script perhaps....

import json

metaPointsToMap = ["DP_12345"]
propertiesToMap = ["xid", "dataSourceXid"]

configFile = open("/path/to/Mango/backup/Mango-Configuration.json")
config = json.load( configFile )
configFile.close()

modifiedPoints = []

def getPoint(xid) :
	for dp in config["dataPoints"] :
		if dp["xid"] == xid :
			return dp
	return None

for dp in config["dataPoints"] :
	if dp["xid"] in metaPointsToMap :
		variableMap = {}
		for context in dp["pointLocator"]["context"] :
			contextPointMap = {}
			contextPoint = getPoint(context["dataPointXid"])
			for prop in propertiesToMap :
				contextPointMap[prop] = contextPoint[prop]
			variableMap[context["varName"]] = contextPointMap;
		dp["pointLocator"]["script"] = "var contextProperties=" + json.dumps(variableMap) + ";\n\n" + dp["pointLocator"]["script"]
		modifiedPoints.append(dp)
			
outputFile = open("/path/to/output.json", "w+")
outputFile.write(json.dumps({"dataPoints":modifiedPoints}, sort_keys=False, indent=4, separators=(",",": ")))
outputFile.close()

Then you'd be able to use the variable name to get that information. Of course, that's somewhat fragile. Perhaps if you described why you're trying to get that information I could make a better suggestion.

[AldoRamos]

The easy example is for logging purposes:

    LOG.debug('validating source: ' + source.xid);

That’s a relatively trivial and seemingly meaningless example, since LOG is only available in manual validation.

More substantial is a script that resets a serial MODBUS DataSource, based on slave point state:

    if (false === slavePoint.value)
        resetDataSource(slavePoint.dataSourceXid);

On the subject of LOG being unavailable at run-time, is there a way to add annotation in such a script?

[AldoRamos]

Speaking of adding annotation, is it possible to create events within a script? e.g.

createEvent(URGENT, "bad input: " + source.value);

[phildunlap]

Great examples, I see the merit. I did a look looking around and I think it would be very easy to add this in, so I'll bring it up to others and see what they think.

That information, source.xid or slavePoint.dataSourceXid are both constant I would think, but I do understand it make writing the code a lot nicer not to have to look up the constant values of those things during script writing.

What do you mean LOG is unavailable at runtime? If your log level for the item is set below the level called (i.e. debug is below info) then your calls to LOG.info() will appear in the file specified. Are you not experiencing that? I do not believe they go into the main ma.log, but I can't recall offhand.

[phildunlap]

@AldoRamos said in Is DataPointWrapper object accessible for a runtime object?:

Speaking of adding annotation, is it possible to create events within a script? e.g.

createEvent(URGENT, "bad input: " + source.value);

Not so directly, but of course it is possible. If this is a scripting data source, you could have an alphanumeric point on the script with a change detector that you set your event text to.

Also you can throw "a javascript exception"; and that will be reported as an event on the point or data source of the appropriate type, but will of course exit the script.

[AldoRamos]

From: About Mango Java Script:

Logging

Logging can be achieved during script testing on the edit page by enabling the logging level desired and then using the appropriate log statement.

The implication was that it's only available on the edit page. It's been a while since I paid attention to that; I just haven't leave in the LOG calls in production.

Again, annotation and events would be preferred in the long run.

Throwing exceptions is a viable solution for some cases, so thanks for pointing that out

[phildunlap]

I guess that document is due for an update. You'll notice beneath the log level select that it says the file path it will be logging to.

Again, annotation and events would be preferred in the long run.

What do you mean exactly by annotation, and what benefit do you conceive over going through a data point to trigger the event? One advantage of a point is that you'll get return to normal behaviors easily. So, if you use a Regex alphanumeric state detector for the state "ERROR:.*" then you will know when it returned to normal. You can call the variable name eventDispatcher or whatever to keep the code looking nice. eventDispatcher.set("ERROR: free lunch"); looks straightforward enough to me.

[AldoRamos]

@phildunlap said in Is DataPointWrapper object accessible for a runtime object?:

What do you mean exactly by annotation

I meant pointValue annotation, i.e. setting a point value and adding an annotation in the process:

target.set(1.23, '2017-07-12T12:34:56', "after much number crunching, this number was the crunchiest");

The alphanumeric eventDispatcher solution is a great idea. Thanks!

[phildunlap]

Ah I understand. I'll keep that in mind when I'm looking into making the VOs available from the context points. Seems like that would be an easy function to add as well. Good suggestions!

[phildunlap]

Both these suggestions were added into Mango 3.2. Context points will have a method getDataPointWrapper() and there is a third set() signature for set(value, time, annotation)

Should be released in a couple weeks!

[phildunlap]

This was released in 3.2