Developer Portal Community

    Showing results for 
    Search instead for 
    Did you mean: 

    MES-Communication OpconTcpDDL <structArrays>! It's a bug or a feature?

    MES-Communication OpconTcpDDL <structArrays>! It's a bug or a feature?

    Established Member

    We had a case this week, which I will try to describe as best as I can:

    So I take the dataDownloadRequired telegram as an example, because we noticed the problem here. However, this problem probably exists with every telegram that uses a <structArrays>.

    Here it is the case that the first item, the item "Counter" defined under <structDef> has also been sent as defined (see point 1 and point 2 in Figure 1).

    The MACRO, perhaps also workflow or whatever in the MES, did not work properly and did not send a "counter" item for the other items of the structure (from two to eight) (see point 3 in Figure 1).


    The FB on the PLC for the DDL communication "OpconTcpDDL/DDLV4MessageFB" in version 1.2.2 has now not detected an error here.

    It seems that the FB only checks the first item. If the <counter< item were missing there, the FB would throw an error!

    Furthermore, it is also the case that the FB does not set the data structure on the PLC of the "orderList" array (rDdlData.orderlist) the values ​​of "counter" of items 2 to 8 to the value 0, it was set to the value 14, the value from the first item. (See point 5 and 6 in picture 2)


    This means that not only is the error not recognized, but “incorrect” values ​​are also transmitted.

    This could now be a bug within the FB module, but the scheme on the MES side does not recognize this error either, this could also be a desired feature.

    With this option, you could save on communication information if the data remained the same - just leave it out 😊

    Now you can decide for yourself: It's a bug or a feature?

    Maybe the question goes to the guys from BCI!

    11 REPLIES 11

    Community Moderator
    Community Moderator

    Meanwhile we have found out that the missing error handling for incomplete structs is independent of the AcceptIncompStructArray parameter. This bug crept in at an earlier version when we introduced that the order of the struct elements is arbitrary. It also applies when AcceptIncompStructArray is FALSE. In other words: The behavior was never intentional.

    Established Member

    Thanks! Is is solved by Version