Deciding whether to write Jython Scripts or Modules

I have been working under the belief that our applications are best implemented as Ignition modules. In response to comments in other topics, I’m revisiting the question of whether to write Jython scripts or modules.

Conceptually, our typical application will act as a kind of middleware between Ignition devices and a database. A device will expose tags. In response to changes in tag values, rows in the database will be updated, new rows added, and existing rows deleted. A single event may result in modifications to multiple tables.

In the typical programming environment, the data, and the manipulations of the data, would be modeled as a set of classes. There would be, say, ten or twenty classes, with inheritance. Because many devices will need access to these classes, there would be a class library that can be imported.

As I read the Ignition Programmer’s Guide, and the online Ignition manual, I infer that the only way to expose a library to a Python script is via ScriptManager, in a module. Is this true?

If so, then we would need to write a module in order to make our class library available to the devices.

The alternative would be to expose only the data to the devices, through the system.db collection of scripting functions. To standardize the manipulation of the data, we could create a psuedo-library of Python scripts that can be copied and pasted into the script editor, where the programmer can edit parameters to suit the circumstances. This would be an error-prone and tedious process.

So it seems to me that we do need to write modules. Have I missed something?

[quote=“xasga”]… In the typical programming environment, the data, and the manipulations of the data, would be modeled as a set of classes. There would be, say, ten or twenty classes, with inheritance. Because many devices will need access to these classes, there would be a class library that can be imported.

So it seems to me that we do need to write modules. Have I missed something?[/quote]Write your classes in Jython. Put them in shared or project scripts (also called modules, but not involving Java add-ons). Include event functions in these scripts that can be called from tag change events or timer events that invoke your classes as appropriate. I suspect you will find Jython far more compact and maintainable than a Java add-on module.
And you needn’t worry about performance. Jython is runtime compiled into java bytecode, which is then further optimized just like Java classes by the JVM’s native code JIT compiler.

I will look into this.

When would a module be a better solution than a script library?

For example, what might be the motive for SepaSoft to write modules for its MES package, instead of a script library?

One thing that comes to mind is the ability to modify/create database tables at module startup. I suppose this could be included in the script library as a set of SQL commands, but…

The general question is how to identify and list the capabilities of a module that are not available to a script.

[quote=“xasga”]When would a module be a better solution than a script library?
For example, what might be the motive for SepaSoft to write modules for its MES package, instead of a script library?
One thing that comes to mind is the ability to modify/create database tables at module startup. I suppose this could be included in the script library as a set of SQL commands, but…
The general question is how to identify and list the capabilities of a module that are not available to a script.[/quote]There are a few reasons:
[ul]
[li]Use jars from an external Java project for which you can’t find a Jython alternative[/li]
[li]Obfuscate proprietary logic[/li]
[li]Distribute un-editable logic[/li]
[li]Use Ignition’s licensing system to enforce a license fee[/li]
[li]Provide an OPC driver or otherwise use the platform’s extension points[/li]
[li]Extend Ignition’s web interface with custom configuration or status pages[/li]
[li]Use Java methods or constructors whose signatures are ambiguous in Jython[/li][/ul]

Would non-deterministic and asynchronous sequence of execution of Jython scripts be a consideration? e.g. SFC cannot be implemented using Jython!

Probably not. The database will (or can be made to) serialize access to its tables. The various machine controllers will synchronize with each other as needed.

  1. Does Python scripting allow socket programming? Looks like it supports serial ports calls and GET / POST (.net library) calls, but does it support socket creation and read/write on sockets? From the documentation, it doesn’t seem to support it?
  2. Can we extend jython to use java for implementing socket calls? Any exmples of implementing classes in jython?
  3. Can we load an HTML page within a system.nav.OpenWindow generated window?
    regards
    PRAFULL

This post shows a script that opens a socket and sends a command.

inductiveautomation.com/forum/v … 70&t=16128

I am unable to open this post due to perhaps privacy reasons. Will be grateful if you could copy past it to me privately.
regards
prafull

The post is in the Ignition Design Help forum.
Title: Read Data Script for TCP.
Date: September 14, 2016.

It is this code that I thought might interest you:

def sendcmd(sock, cmd):
sock.send(’-’ + cmd + ‘\r’)
ack = sock.recv(3)
if ack != ‘*!\r’:
print((repr(cmd) + ‘Bad ack: ’ + repr(ack)))
while True:
resp = sock.recv(100)
print((repr(cmd) + ‘response: ’ + repr(resp)))
if resp.find(’*OK\r’) != -1:
break
elif resp.find(’*FAIL’) != -1:
error = int(resp[6:])
error_str = resp.strip() + ', ’ + error_msgs[error]
raise Exception('command ’ + repr(cmd) + ': ’ + error_str)
break

a simple uniwest ethernet protocol command line sender

ip_addr = ‘169.254.253.54’
command = ‘GAIN 80.0’
sock = socket()
sock.connect((ip_addr, 55556))
sendcmd(sock, command)

1 Like