Using external connections from a SCL script

There is something interesting that I have not mentioned before. It was introduced along with the Time critical scripts but can be used by any SCL script - the ability to exchange data over a user defined external connection directly in the SCL code. You don't need to be in "External connection" mode. No signal mapping is needed. Instead you exchange the state of the variables in the script with any 3rd party software. The only requirement is to have a user defined connection that knows how to talk to the 3rd party.

Why did we do it? We wanted to communicate with a PLC at a higher update rate. Higher than the one used by the simulation in Process Simulate. Currently this is only possible with a time critical script. The update rate of the time critical script will be used for the communication as well. In addition you get the benefit of exchanging variables of all the supported data types. Yes. You can exchange strings, arrays etc. as long as the external connection supports them. In other words we are bypassing the signals and the simulation engines and work directly with the PLC. This has the potential of being something huge, isn't it?

Q:How does it work?

A:You enable the TIME_CRITICAL_SCL_SCRIPTS feature toggle, open SCL editor on a resource and declare a static variable of type TX_EXTCONN like this:

	conn: TX_EXTCONN := '<external connection name>'; 

It is a function block that you can call like any other. The difference is that its I/O interface is not strictly defined. This means that you can pass any name-value pair to it and it will be treated like an input/output value that has to be exchanged with the 3rd party. The direction is specified by the IOCTL argument (1=Read, 2=Write, 3=Step). The exchange can be done by name or by address as long as the external connection supports both.

For example:

#conn(IOCTL:=2, FOO:=#str); 				// write by name
#conn(IOCTL:=2, "I20":=#str); 				// write by address
#conn(IOCTL:=2, FOO:=#str1, BAR:=#str2);		// write by name

#conn(IOCTL:=1, FOO:=#str); 				// read by name
#conn(IOCTL:=1, "Q20":=#str); 				// read by address
#conn(IOCTL:=1, "Q20":=#str1, "Q31":=#str2);	// read by address

IOCTL=3 is used for connections that support stepping. Every time you call it the PLC will advance its time with a single time step. In other words the script dictates the time on the PLC.

It is a pretty neat interface, isn't it?

Now imagine that you have a loopback external connection that uses some memory storage and gives you back everything that you send to it. In this case you can communicate between the SCL blocks without using signals and this opens the door for a fast, bi-directional communication. What is the price for it? Flexibility. Names and addresses will be hard coded in the script. This limits reusability. The same is true for any other connection used like this. The script will be tightly coupled with the remote side. The name of the connection is also hardcoded. Overall this does not fit in the concept of component prototypes.

You can refer to User defined external connections for details about implementing an external connection. The snapshots there illustrate exactly the use case of a loopback connection.

Each script has a unique instance of the external connection. The script may exist in its own thread. This means that you might have multiple concurrent connections to the 3rd party software. Depending on the connectivity API used this might be a problem.

Simply put, this integration is powerful but not reusable. What a pity!

Now you know why it sits behind a feature toggle.