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

[PKlein]

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!

[PKlein]

To add something. This problem is not just a problem of the function block at the plc. This problem should not be allowed by the schema of the DDL service in the MES. I think we need to address this on both sides (PLC and MES).

[nexidator]

We totally agree that using the value from the first instance for all other instances is bad behavior. As Düscha said, we have to look into the code a little bit deeper. (Unfortunately the colleague who developed this has retired in the meantime.) So, I am sure this will be fixed in the next version.

As I understood, you never had the requirement that elements of the structure should be allowed to be missing in the telegram, but only the number of array elements (i.e. complete struct instances) should be variable. Is that correct? I also feel this makes more sense than allowing just any random struct element to be missing, because in this case it is impossible to find out what elements were actually received from MES and which ones just have default (or because of the current bug even wrong) values.

Is anyone else using the AcceptIncompStructArray feature? Everyone is welcome to share their opinion about this here!

[PKlein]

Yes exactly, only that was the requirement!

[Andre_M]

Hello, we have exactly the same use case as PKlein with MatControl, e.g. because the ARRAY size is dynamically changed by the MES for split material.
Here, too, a change of the ARRAY size should be accepted but not incomplete structures.

It would be nice if there was a solution.

[nexidator · Accepted solution]

OK, so we have decided that we will change the behavior. In the next version, AcceptIncompStructArray will only allow a dynamic array length. Missing struct elements will lead to errors just as if AcceptIncompStructArray was FALSE. The new version should be available by end of this year at the latest.