Call a Project Library fuction from Script Tranform inside a Binding

Hi,

I’ve create a simple function, Alarms.count(), inside my Project Library. The function works fine when called from the Script Console.

def transform(self, value, quality, timestamp):
	return Alarms.count()

I’ve also tryed with “return project.Alarms.count()”, but I always get:

NameError: global name 'Alarms' is not defined

This setup works fine in a licensed Ignition, but does not seems to work in the Maker Edition. Is this some kind of limitation for the Maker edition, or am I doing something really stupid without realizing it?

It should work, even in Maker Edition. Can we see your script setup?

Sure!

def count():
	return len(
		system.alarm.queryStatus(
			state=['ActiveUnacked'],
			source=['prov:default:/tag:FrancescoP/*']
		)
	)


I would start with checking the Gateway Scripting Project in the webpage,
https://docs.inductiveautomation.com/display/DOC80/Project+Library
image

1 Like

But I don’t want to use the global script container in this case, I’ve defined that script in the project library. As I’ve done on the licensed installation and where it works fine that way.

Moreover, the self-completing feature of the new script editor, does find the function definition, and correctly suggest it.

This seems like it should work… what version of Ignition do you have installed?

8.1.19 (b2022072711), Maker Edition - docker image.

Maybe this is relevant: this project was hosted on a licensed Ignition, same release. I’ve exported from there and reimported here. But in the meanwhile I’ve also removed and recreated both the scripts and the binding rules.

I can’t see how, but maybe some difference in the alarms configuration on the gateway can cause this kind of problems?

Hmm. We’ll the error message doesn’t support this theory, but you are querying a provider named “default” in your script but your screenshot shows the tags being from the MQTT provider.

Yes, tags are coming via MQTT, but I created a parametrized UDT in the default provider (where I also defined the alarms conditions), then I have tre instances of that UDT in the same default provider.

And they seems to works fine, in the Alarms Status Table I can see the correct alarms list and the Alarms->Active* properties in the istantiated UDTs are correct.

Does it work if you name it something other than Alarms? Does a plain return 1 work (as in, is all Perspective scripting blocked, or is it specifically this library call?)

If you run something like this (maybe swap for system.perspective.print) does it have Alarms listed? If you add other script libraries, do they show up?

for var in dict(vars()).items():
	print var

Can you have a look at which package the script console sees the script is a member of? The package name should match your project name. Also check to make sure the script name matches the letter case. I’m thinking to create a new script with a different name just to make sure there isn’t something strange going on with letter case as I have seen before with importing (not that I could reproduce with the scripts).

In the script console, press Ctrl+Spacebar and it should show you to the right of your script .

@PGriffith - I’ve already tried with a different module name (and a brand new one), and with a static return, with no success. The module is listed in the output of your script.

@user77 - Yes, I checked the case and the module appears as a member of the corrent package / project.

I recommend you call support and create a ticket so they can take a look.

When invoked in Perspective? Or in the script console?

Well, it is working now! I swear I did nothing on the project and the script code, beside all the tests you suggested.

I’ve only created a global alarm journal in the gateway, I don’t know how and if that triggered something that made some “realignment” on the project properties…

@PGriffith - it was in the script console.

1 Like

Well, for posterity, that wasn’t testing much. The issue in this case seemed to be that the gateway’s mechanism for creating a project-specific ‘script manager’ that runs your code was faulty or out of date or something. Running in the script console only tests the local designer; you’d have to run in a tag or in a Perspective action to see what the gateway thought the state of things was.

Ah ok, take note (I’ll try to remind myself) in case the problem occurs again, thanks!

1 Like