Reading data type UNION and BIT with OPC-UA

[NickOS]

In an Indralogic project we have a union of DWORD and a 32 element structure of type BIT. For example:

TYPE UN_CONTROL :
UNION
   Word : WORD;
   Bits : ST_CTRL_BITS;
END_UNION
END_TYPE

TYPE ST_CTRL_BITS:
STRUCT
   b0 : BIT;
   b1 :  BIT;
   ...
   ...
   b31 : BIT;
END_STRUCT
END_TYPE;

We have this because some legacy HMI used words to communicate, but within the PLC itself it is nice to be able to address variables as control.bits.b<whatever name>.

This works within indralogic, no problem. The trouble is, when trying to access this word via OPC-UA (UA-client, Web-IQ, etc) it neither appears as the bits or the word, it is like it has completely dissappeared.

I know I could re-write the code to switch between WORDs and, say, a BOOL structure, but I was hoping to find a neater solution utilising the UNION. Any suggestions?

p.s. in an integration with a 3rd-party (UniOP device), I shared the XML schema and XML file with the project variables, and the developer could read and manipulate the BIT!

[webiq-sk]

This sounds to me more like an issue with Indralogic than with WebIQ. I understand that you're not even seeing the item in UA Expert, is that correct?

[NickOS]

Hi, yes you are quite right. Now that I explore further it seems any UNION is not visible.

I guess I could move this on to another forum.

[CodeShepherd]

Moved this thread from Smart HMI - WebIQ Designer and Server to Communication forum.

[CodeShepherd]

Could you please give us some more information about your project?

• Which control/PLC are you using?
• Which OPCUA server are you using?

We are at the moment working on a feature for the access to complete structures via OPCUA. And also the access to the data type BIT is in preparation.

[HmiGuide]

I tested it with LTE version ctrlX 1.12.9 and it works like expected. What I wonder, that you have only a WORD variable (16 bit).
There are 2 ways how to use unions:
1. Use identical RAM by storing different data types/value types in the same place. => You must store somewhere the info how to interprete the address in the RAM:
2. Use BIT's instead of BOOL's
3. Combination of 1 + 2

When I read your request you are using option 3.
This means in the

• PLC you use the Bits of the Union for easy programming
• HMI you use the variable Word to access the variables, where you have to change data type to DWORD (32 bit)

TYPE UN_CONTROL :
UNION
   dwValue: DWORD;  // must be DWORD to access all 32 bits of variable Bits
   Bits:    ST_CTRL_BITS;
END_UNION
END_TYPE

The structure ST_CTRL_BITS is not a standard data type, therefore it is visible in OpcUA browse but with unknown (=empty) data type. Therefore you can not access it.

You can access the bits via the union variable Word, but you must adapt the data type to DWORD, to access all 32 bits of the union variable Bits. To access bits in WebIQ you add a prefix to the item: bit[bitNo]:item e.g. bit[0]:SInt

[NickOS]

@HmiGuide , you assume correctly. I apologise for my typo in the OP (I didn't copy from live code), but my actual code is size-matched. I have tried WORD and 16-bit structures; DWORD and 32-bit structures; WORD and INT (just to check it wasnt my bit structures), none of this works.

I should add though, @CodeShepherd , this is an MLC75 running IW14v22 rather than a CtrlX processor. And although I originally brought this up in a WebIQ forum, it seems even the UA-Client cannot read this data. So it suggests the issue lies in MLC/IW platform, perhaps the OPCUA server.

[HmiGuide · Accepted solution]

@NickOS in the MLC version you are using there is an older CoDeSys version than in ctrlX.

 There is an easy workaround to access the variable. Just add a refence which points to your structure. I tested it with IW 14V22 P5.

VAR_GLOBAL
  stTest:  UN_CONTROL;
  // reference MUST be initialized to export it into symbol file
  refDWord: REFERENCE TO DWORD REF= stTest.dwValue;
END_VAR

[NickOS]

Thanks @HmiGuide , I think I can work with that for now.