OpconWorkingCode Enum doesn't match with XML specification

[tommy3000]

Hello together

During a commissiong with MES I found a little inconsistency of data taypes in the OpconDataDefBase.

The OpconWorkingCode in the PLC has more values, than the OpconWorkingCode on MES side.

Here a screenshot of the current specifications for XML.

On PLC side the enumeration is equal until 15, like the spec, but it has more values.

Which one is now the correct one?

[SteffenR-]

Both enumerations are correct 🙂

Nexeed MES knows WorkingCodes 0-15 by default, that means they will be shown with their name in MES. Some WorkingCodes affect the behaviour of the MES communication, e.g. TEST_PART (1) or GOLDEN_DEVICE (15).

These WorkingCodes 0-15 are the same on both sides (MES and OpconWorkingCode enum).

All other WorkingCodes (16ff) of the OpconWorkingCode enumeration do not have a special effect in MES by default and MES just shows the number. The name can be added on MES side to also show the name for the WorkingCodes 16ff (that's at least the current solution/workaround, must be done in every MES project manually: OIS.NET Portal Setup → Internal Text Groups → WorkingCode → Text Group Customization).
But it is also possible to give the WorkingCodes 16ff other meanings in MES than in the PLC enumeration. Actually that is already the case for HDP projects where some WorkingCodes have different numbers:

Meaning	HDP project	Control plus (OpconWorkingCode)
T16	26	18
VA Packaging	27	19
Z	28	20
SPC	29	21
Q	30	22
VA	31	23

For communication with OpconXml (DDL Event add-on) you can use your own enumeration instead of the OpconWorkingCode enumeration (e.g. necessary for HDP projects).
But for Public Interface (OPC UA) you have to use the OpconWorkingCode enumeration. Currently it is not possible to provide a basic WorkingCode enumeration that can be extended/changed manually in the projects.

PS: In general all WorkingCodes can have project specific effects (should be defined in the MES specification).

[tommy3000]

In my opinion, this is a big issue.

Is it not possible, that you communicate internally the extended enumeration to the MES department, so they can extend there specs, especially with the new commincation with OPC UA.

We have to avoid too many applicationable solutions and define a standard of our data.

Little example, I tell my customer which possibilities we have with the WorkingCode and we choose Check_the_checker to use. After integration and testing the MES, we only see the number. Now I ask the collegue from MES why, the answer is not I can integrate this, the answer is, WorkingCode from spec is only until 15, that's what we can use.

Explaining the customer the situation, he cannot understand, why my standard is different to the MES one.

I think, we should have a common data base in OPC UA and use the Input and Output Data for special things, if needed.

[SteffenR-]

1. Thanks for this hint. We will think about documenting the difference (comment, documentation, ...).
   Actually the idea behind extending the WorkingCodes was to prevent too many application specific solutions.
2. Our MES department knows this topic already. Currently I can't tell you anything about the final solution or time line, but I guess it will last some time.
3. The Bosch division PS has specified our OpconWorkingCode enum (0-28) as standard for new PS projects. I am not sure about the specification of your fuel cell project, but the PS standard specification should apply for it. Maybe the MES colleage doesn't know this?