Modbus Slave/Server to Generate Read Only Tags

[pturmel]

@pturmel

However, if I were to do this ....

I've create a generic "Modbus Publish" script that eliminates the need for a second set of tags. I've publicly posted it here:

https://www.automation-pros.com/ignition/modbusPublish.py

It requires the "Queue Utility" script posted here:

https://www.automation-pros.com/ignition/queueUtil.py

and described over here:

Java concurrent queue for tag change scripts

Continuing the discussion from [SOLVED] Are tag Value Changed scripts running asynchronously?: We've got code in our standard library that I need to log a value change on a tag and then associate various data points with that value change. The value is located in a UDT, and because this is part of our "standard" library we use for our customers, the number of tags is variable and quite possibly numerous so having a gateway tag event script isn't feasible for this solution. I was reading up on …

Both scripts rely on my Integration Toolkit's globalVarMap() script function, but you can rework that (not quite 1:1) to use system.util.getGlobals() if you must. (Not recommended nor supported by me.)

Do read all of the comments in that topic and in both scripts. They need to be in the hierarchy for your global scripting project, as they are called from tag events.

A leaf project needs a gateway timer event that contains this one-liner:

modbusPublish.drainSlavePublish()

That timer event should use a fixed rate and a dedicated thread, in most cases. Select an interval that makes sense for your workload. Increase the size of the blocking queue (modbusPublish.py line 45) if you run this with very many tags. (It must be large enough for a flood of startup events.)

Once all of that is in place, for any tag or UDT member you wish to publish via my module, set the tag's valueChange event to this script:

def valueChanged(tag, tagPath, previousValue, currentValue, initialChange, missedEvents):
	modbusPublish.enqSlavePublish(tag, tagPath, previousValue, currentValue, initialChange, missedEvents)

Then create one of these string custom properties on the tag or UDT member:

• publishOpcItem : Containing the complete OPC Item Path to receive value changes. As written, must be in IA's local OPC Server, but doesn't necessarily have to use any of my drivers. The source tag can be anything.

• publishOpcPrefix : Containing an OPC Item Path prefix, of at least a bracketed device name, with optional unit address and memory area overrides. The source tag must have an OPC Item Path property containing a complete modbus address. The parts of the given prefix will be substituted to produce the complete target address.

Some examples for source OPC Item Path plus publish prefix:

[device1]HRUI2345 & [slave]2. => [slave]2.HRUI2345

[device1]HRUI2345 & [slave]2.IR => [slave]2.IRUI2345

[device1]HRUI2345 & [slave]IR => [slave]IRUI2345

(Remember that IA Modbus driver defaults to unit #0 when omitted, while mine defaults to unit #1.)

The scripts above have been lightly tested in my lab.