Writing to Integer OPC Tag Bits

Ignition
1

Hi all. I was converting a SCADA to Ignition under the assumption that all my Boolean tags were configured as Booleans in the PLC. I created dozens and dozens of one shot buttons in the new Ignition SCADA with control values bound to OPC tags with bad paths that I intended to configure later.

When I got access to the tags via Kepware, I realized that all of the push buttons were referencing individual bits of Integer tags.

That said, I am wondering if there is an easy way to reference the individual bits of a PLC integer tag that can support writing. Putting a dot or a forward slash with a bit number at the end of a path to an OPC integer does not work (e.g. opcItemPathToIntegerTag.bitNum or opcItemPathToIntegerTag/bitNum)

My colleagues and I came up with several solutions to this problem:

  1. Creating OPC tags for the integers, and then creating Boolean expression tags using the getBit function to reference the individual bits of the integers. This approach allowed for read access to the bits without reprogramming the tag paths. However, the expression tags cannot be written to directly, so the push buttons cannot be fully implemented this way.
    • Could theoretically make it bidirectional by having a Boolean memory tag for every expression tag: button writes to memory tag, which has a change script to write to OPC integer tag. Expression tag reads integer bit and writes its value to the memory tag. This is convoluted though...
  2. Creating a template that will add/subtract an appropriate value to the desired tag based on tag path and bit numbers indicated by parameters. This would entail reprogramming many of the push buttons in the SCADA, replacing the one shot buttons with template instances
  3. Adding Boolean tags to the PLC for Ignition to write to and mapping the PLC tags to the appropriate actions, redoing the OPC paths for the Ignition tags. This would be a clean solution and will not involve having to reprogram the buttons

We're planning on going for option 2 or 3 presently. However, does anyone know of a more elegant way to tackle this issue, preferably by just manipulating opc item paths?

If not, I strongly believe that a feature should be added: I would like to be able to append a dot or a slash and a bit number to the end of an OPC Item Path to an integer to access the individual bits of the integer.

2

This is not an Ignition issue, per se. Bit-addressable writes into integers requires OPC Server support and protocol support.

What end protocol is this?

(Schneider is notorious for omitting support for function code 22, required to safely write bits into Modbus holding registers. But they are not alone.)

1 Like
3

This can already be done as long as the server supports it. If the server doesn't support it there's nothing you can do. OPC Item Path corresponds to OPC UA NodeId, and what NodeIds are valid and what they mean is entirely up to the interpretation of the server you're connected to, not the client.

I was under the impression that most Kepware drivers do support a syntax like this.

Are you sure you were appending .0 etc... to the OPC Item Path and not the Ignition Tag Path? Did you try creating a new tag with the modified OPC Item Path?

2 Likes
4

By the way, you missed the option to use a Derived tag instead of an expression tag. There's a write path in derived tags that can use the current integer value with shifts and bitwise AND/OR to yield the new integer value required. When combined with "optimistic writes" in a tag group, multiple bit writes can be efficiently combined into a single OPC write.

(Doesn't fix the race condition of the bits can also be modified in the PLC.)

5

I like that. Thank you sir. I think I'll end up using something like this, where the "int" memory tag will be an OPC tag and the "0" will be whatever the bit number I need is:

image
image711×601 42.2 KB

6

You never did answer the brand/protocol question. This sort of racy writing will glitch your process if you cannot prohibit PLC writes to the same integers. Using a derived tag is a work-around, not a solution.

If the PLC is truly unable to write to bits of integers safely, I would use your original option 3. Most end-users do not understand these nuances and will not be happy with excuses for crashing their process.

1 Like