About SteffenR-

SteffenR- · ‎10-01-2021

I forgot another solution: MES SetupControl can also communicate via DAT files with the station, that means there is no dataDownloadRequired (OpconXml) nor DataSet (OPC UA Public Interface) for type data. The DAT files are pushed to the station via the MES Cyclic Update (which is part of the Line Configurator). This solution has some big advantages: During commissioning you can edit the local DAT file. As soon as MES SetupControl is available you set the DAT file for the HMI data editor to "read-only". When type data are changed in SetupControl they can be pushed actively to the station. In combination with DataSetManager/DatAccess a blue message occurs that new data are available. When manually starting changeover to a new type, you can select the type out of the available DAT files. So there is no necessarity to put in the new type number manually. Disadvantage of Cyclic Update: In future there could be security limiations or Windows changes in a way that it is not working anymore (because it uses the Remote Registry service).

SteffenR- · ‎09-24-2021

What I have already seen in Bosch plants and at suppliers: Some plants and business areas are providing a MES test server. Either a real computer at the supplier or via router in the cloud. Bosch AE is very exemplary and provides all suppliers access to a test server. If no test server is available: If you have MES via Public Interface (OPC UA) it is quite easy: The DataSetManager can switch between local data or MES data. Alternatively/Additionally you can use the PublicInterfaceTester to simulate MES. For MES via OpconXml: Testing could be done with the CommTester. But this tool is not available publicly. And the usage of the tool is not very convenient. Last option that is probably the default option with OpconXml nowadays: Put the MES type data temporarily into a local DAT file and use local data management (DataSetManager+DataSetAccess or DatAccess). When MES is available switch back from local data to MES data. This solutions causes the most additional effort and I guess this is the reason for your question 😀 Target is that DataSetManager supports OpconXml as well, but priorization is not yet high enough to implement it (and some technical basics would have to be improved in the platform). Feel free to contribute to a higher priorization.

SteffenR- · ‎08-25-2021

English 🠦 Deutsch Symptoms The DataSetManager add-on stays in initialization until a communication timeout occurrs although the DataSetAccess service is running on the target system. Diagnosis Check if there two configuration files for the DataSetAccess service. If you change the machine identifier of your project there can still be the old configuration file on the target system: Solution Just delete both folders and deploy the DataSetAccess again. The DataSetAccess service can connect to multiple PLCs. But if you do not have this use case there must only be one configuration file (that means only one GUID folder). Background: If there are two configuration files with the same target IP, the DataSetAccess service and DataSetManager have a handshake problem. Additional hint: You should update the service (ORD/NXRD file) at least to V1.0.11 because this fixes a similar problem after activating configuration in TwinCAT. In the documentation of the DataSetManager add-on you will find some more hints to solve problems: Deutsch 🠦 English Symptome Das DataSetManager Add-on bleibt in der Initialisierung stehen bis eine Kommunikations-Zeitüberschreitung auftritt, obwohl der DataSetAccess Service auf dem Zielsystem läuft. Diagnose Prüfen, ob es für den DataSetAccess Service zwei Konfigurationsdateien gibt. Wenn man die Maschinenkennung (machine identifier) eines Projekts ändert, bleibt die alte Konfigurationsdatei trotzdem noch auf dem Zielsystem bestehen: Lösung Einfach beide Ordner löschen und DataSetAccess nochmal deployen. Der DataSetAccess Service kann sich mit mehreren Steuerungen verbinden. Aber wenn man diesen Anwendungsfall nicht hat, darf es nur eine Konfigurationsdatei (das bedeutet nur ein GUID-Ordner) geben. Hintergrund: Wenn es zwei Konfigurationsdateien mit derselben Ziel-IP gibt, haben DataSetAccess Service und DataSetManager ein Handshake-Problem. Zusätzlicher Hinweis: Man sollte den Service (ORD/NXRD Datei) mindestens auf V1.0.11 aktualisieren, weil das ein ähnliches Problem nach Aktivieren der Konfiguration in TwinCAT behebt. In der Dokumentation des DataSetManager Add-ons gibt es weitere Hinweise zur Problembehebung:

SteffenR- · ‎07-20-2021

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. 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. 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?

SteffenR- · ‎07-19-2021

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).

Bosch Shared

About SteffenR-

Re: Commisioning of SetupControl tool during machine building

Re: Commisioning of SetupControl tool during machine building

DataSetManager/DataSetAccess stick in initialization

Re: OpconWorkingCode Enum doesn't match with XML specification

Re: OpconWorkingCode Enum doesn't match with XML specification

About SteffenR-

Re: Commisioning of SetupControl tool during machine building

Re: Commisioning of SetupControl tool during machine building

DataSetManager/DataSetAccess stick in initialization

Re: OpconWorkingCode Enum doesn't match with XML specification

Re: OpconWorkingCode Enum doesn't match with XML specification

Still looking for something?