OP
- Beiträge
- 9.189
- Reaktionspunkte
- 2.936
-> Hier kostenlos registrieren
Indem ich es selber am Panel nachprogrammiere. Oder meinst du was anderes?
S7 Datenkonsistenz bei HMI Kommunikation
- Ersteller Thomas_v2.1
- Erstellt am
-> Hier kostenlos registrieren
- Beiträge
- 16.459
- Reaktionspunkte
- 6.065
der Status ist doch beim lesen und beim schreiben wirksam, ich bin bisher davon ausgegangen,
wenn dazu eine SPS Variable genutzt wird, das diese dann auch den zustand rausgiebt, ob
der Datensatz komplett gelesen bzw. geschrieben ist und die Werte auch gültig in der Steuerung
stehen.
wenn dazu eine SPS Variable genutzt wird, das diese dann auch den zustand rausgiebt, ob
der Datensatz komplett gelesen bzw. geschrieben ist und die Werte auch gültig in der Steuerung
stehen.
OP
- Beiträge
- 9.189
- Reaktionspunkte
- 2.936
-> Hier kostenlos registrieren
Ah, du meinst den Bearbeitungsstatus bei der WinCCflexible Funktion SchreibeDatensatzInSteurung. Das funktioniert wirklich. Wenn ich das anstoße wird erst nur der Bearbeitungsstatus=2 geschrieben, dann eine oder mehrere PDUs mit den Rezeptdaten, und dann nochmal separat der Bearbeitungsstatus=4 hinterher. Wenn man das im SPS-Programm auswertet (d.h. solange Bearbeitungsstatus=2 dann Finger weg) ist es garantiert konsistent.
Den Status auszuwerten ist über die erweitere Rezepturanzeige aber nicht möglich, wenn ich das richtig sehe.
Den Status auszuwerten ist über die erweitere Rezepturanzeige aber nicht möglich, wenn ich das richtig sehe.
OP
- Beiträge
- 9.189
- Reaktionspunkte
- 2.936
Zu früh gefreut. Die Auswertung des Bearbeitungsstatus ist wohl nur bei einer 300er mit "nicht priorisierter BuB Kommunikation" ausreichend.
Ich habe bei meiner 1200er diesen Status auf ein Merkerwort gelegt, die Rezeptdaten in einen DB. Trotz Auswertung des Bearbeitungsstatus habe ich inkonsistente Daten in dem DB. Evtl. werden Merkerbereiche eher oder anders eingebunden als Datenbausteine.
Ich habe bei meiner 1200er diesen Status auf ein Merkerwort gelegt, die Rezeptdaten in einen DB. Trotz Auswertung des Bearbeitungsstatus habe ich inkonsistente Daten in dem DB. Evtl. werden Merkerbereiche eher oder anders eingebunden als Datenbausteine.
Zuletzt bearbeitet:
OP
- Beiträge
- 9.189
- Reaktionspunkte
- 2.936
Bei der 1200er habe ich mir eben selber einen Fehler eingebaut, indem ich den Bearbeitungsstatus als InOut verwendet habe. Wenn man das richtig macht, dann funktioniert das mit dem Bearbeitungsstatus wohl auch bei Steuerungen welche die Daten mitten im Zyklus einbinden zuverlässig.
- Beiträge
- 14.474
- Reaktionspunkte
- 3.309
-> Hier kostenlos registrieren
Hallo Thomas,
erstmal recht herzlichen Dank für deine Untersuchungen zu diesem (mich auch brennend interessierenden) Thema und im gleichen Zug für diesen Thread.
Für mich ist an dieser Stelle immer wieder interessant, Ereignisgesteuert Daten aus der SPS zu Lesen um sie dann zu speichern - es handelt sich hier i.d.R. um Daten, die zu einem gefertigten Bauteil erfasst / ermittelt wurden.
Wenn ich dich also recht verstanden habe dann ist es so, dass wenn man "priorisierte BuB" aktiviert hat man bei einer neueren 317 oder sogar einer 319 auch nicht sicherstellen kann, dass man mit der Rückmeldung der Lade-Routine die Daten wirklich zusammengehörig in der Visu hat ...? (es können also immer noch "alte" Daten mit in dem Block stecken ?)
Gruß
Larry
erstmal recht herzlichen Dank für deine Untersuchungen zu diesem (mich auch brennend interessierenden) Thema und im gleichen Zug für diesen Thread.
Für mich ist an dieser Stelle immer wieder interessant, Ereignisgesteuert Daten aus der SPS zu Lesen um sie dann zu speichern - es handelt sich hier i.d.R. um Daten, die zu einem gefertigten Bauteil erfasst / ermittelt wurden.
Wenn ich dich also recht verstanden habe dann ist es so, dass wenn man "priorisierte BuB" aktiviert hat man bei einer neueren 317 oder sogar einer 319 auch nicht sicherstellen kann, dass man mit der Rückmeldung der Lade-Routine die Daten wirklich zusammengehörig in der Visu hat ...? (es können also immer noch "alte" Daten mit in dem Block stecken ?)
Gruß
Larry
OP
- Beiträge
- 9.189
- Reaktionspunkte
- 2.936
Prinzipiell geht das nur 100%ig zuverlässig mit einem extra Handshake.
D.h. wenn man einen Datensatz konsistent aus der SPS lesen will, muss man erst ein Flag in der SPS setzen damit diese die Daten nicht mehr schreibend anfasst. Dann die Daten auslesen und über ein Flag die Bearbeitung in der SPS wieder freigeben.
Ich habe gerade nochmal versucht aufzudröseln wie weit die Daten überhaupt konsistent geschrieben werden. Im S7-Protokoll gibt es die Möglichkeit als Transportgröße DWord anzugeben. Selbst damit landet nicht einmal dieses DWord garantiert konsistent im Speicher!
Mein Testprogramm schreibt abwechselnd 0xa5a5a5a5 und 0x5a5a5a5a in die SPS. Mein SPS Programm prüft ob eines dieser beiden erlaubten Werte im Datenbaustein stehen, und das ist NICHT immer der Fall.
Beispiel was das für Auswirkungen haben kann:
Ich habe einen Sollwert als DINT.
Erste Einstellung: 1 (16#0000_0001)
Jetzt schreibt jemand von der Visualisierung einen neuen Sollwert -1 (16#FFFF_FFFF).
Es besteht die Möglichkeit, dass die SPS für einen oder mehrere Zyklen den Wert 65535 (16#0000_FFFF) sieht.
Es wäre zu prüfen ob das nur bei der 1200er so ist, oder ob das die 300/400er auch schon ignoriert haben.
D.h. wenn man einen Datensatz konsistent aus der SPS lesen will, muss man erst ein Flag in der SPS setzen damit diese die Daten nicht mehr schreibend anfasst. Dann die Daten auslesen und über ein Flag die Bearbeitung in der SPS wieder freigeben.
Ich habe gerade nochmal versucht aufzudröseln wie weit die Daten überhaupt konsistent geschrieben werden. Im S7-Protokoll gibt es die Möglichkeit als Transportgröße DWord anzugeben. Selbst damit landet nicht einmal dieses DWord garantiert konsistent im Speicher!
Mein Testprogramm schreibt abwechselnd 0xa5a5a5a5 und 0x5a5a5a5a in die SPS. Mein SPS Programm prüft ob eines dieser beiden erlaubten Werte im Datenbaustein stehen, und das ist NICHT immer der Fall.
Beispiel was das für Auswirkungen haben kann:
Ich habe einen Sollwert als DINT.
Erste Einstellung: 1 (16#0000_0001)
Jetzt schreibt jemand von der Visualisierung einen neuen Sollwert -1 (16#FFFF_FFFF).
Es besteht die Möglichkeit, dass die SPS für einen oder mehrere Zyklen den Wert 65535 (16#0000_FFFF) sieht.
Es wäre zu prüfen ob das nur bei der 1200er so ist, oder ob das die 300/400er auch schon ignoriert haben.
christoph2630
Level-1
- Beiträge
- 74
- Reaktionspunkte
- 3
Hallo alle,
habe auch gerade ein Projekt mit einer 1200 + WinCC RT. Das HMI sendet Auftragsdaten an die SPS, bestehend aus diversen Sollwerten und Startbefehlen.
Ich stelle nun in der SPS die Aktualität sicher mit folgendem Mechanismus:
- die SPS initialisiert die Sollwerte im Auftragsdatenbaustein mit lauter -999999 Werten (also prozesstechnisch irgendein unsinniger Wert)
- die RT beschreibt alle Sollwerte neu und setzt das Startbit
- SPS erkennt irgendwann das Startbit und wartet solange, bis alle Sollwerte <> -999999 sind. Dann werden alle relevanten Sollwerte in einen separaten DB übernommen und effektiv gestartet. Bei Übernahme der Daten werden die HMI-Auftragsdaten wieder mit -999999 beschrieben.
Das erscheint mir als effiziente Prüfungsmethode - was meint ihr dazu?
LG, Christoph
habe auch gerade ein Projekt mit einer 1200 + WinCC RT. Das HMI sendet Auftragsdaten an die SPS, bestehend aus diversen Sollwerten und Startbefehlen.
Ich stelle nun in der SPS die Aktualität sicher mit folgendem Mechanismus:
- die SPS initialisiert die Sollwerte im Auftragsdatenbaustein mit lauter -999999 Werten (also prozesstechnisch irgendein unsinniger Wert)
- die RT beschreibt alle Sollwerte neu und setzt das Startbit
- SPS erkennt irgendwann das Startbit und wartet solange, bis alle Sollwerte <> -999999 sind. Dann werden alle relevanten Sollwerte in einen separaten DB übernommen und effektiv gestartet. Bei Übernahme der Daten werden die HMI-Auftragsdaten wieder mit -999999 beschrieben.
Das erscheint mir als effiziente Prüfungsmethode - was meint ihr dazu?
LG, Christoph
OP
- Beiträge
- 9.189
- Reaktionspunkte
- 2.936
-> Hier kostenlos registrieren
Sollte vom Prinzip her funktionieren.
Wenn du Rezepturen an einem Siemens-HMI verwendest, sollte es aber auch funktionieren wenn du den Bearbeitungsstatus in der SPS auswertest. Zumindest habe ich dabei noch keine Inkonststenz festgestellt.
Mit deiner Variante bist du unabhängig von Funktionen eines Siemens Gerätes, d.h. könntest unter Umständen auch eine andere Visualisierung verwenden.
Wenn du Rezepturen an einem Siemens-HMI verwendest, sollte es aber auch funktionieren wenn du den Bearbeitungsstatus in der SPS auswertest. Zumindest habe ich dabei noch keine Inkonststenz festgestellt.
Mit deiner Variante bist du unabhängig von Funktionen eines Siemens Gerätes, d.h. könntest unter Umständen auch eine andere Visualisierung verwenden.
OP
- Beiträge
- 9.189
- Reaktionspunkte
- 2.936
Mal eine Frage an die TIA-Experten:
Wie muss ich bei der Stringverarbeitung in der SPS (1200/1500) vorgehen, damit ein HMI garantiert einen konsistenten String einliest?
Die Strings liegen in optimierten Datenbausteinen.
Beispielweise wenn ich einen String dynamisch in der SPS mit CONCAT zusammensetze, dann muss ich wenn ich direkt auf dem HMI-String arbeite damit rechnen, dass der String während der Bearbeitung gelesen wird.
Jetzt könnte ich auf einem temporären String arbeiten, und wenn dieser fertiggestellt ist dem HMI-String zuweisen. Es ist jedoch nirgends angegeben, dass diese Operation ununterbrechenbar ist. Es wird dann höchstens die Wahrscheinlichkeit verringert, dass ein nicht konsistenter String gelesen wird.
Mit UMOVE_BLK lassen sich direkt keine Strings in "optimierten" DBs verschieben.
Wie muss ich bei der Stringverarbeitung in der SPS (1200/1500) vorgehen, damit ein HMI garantiert einen konsistenten String einliest?
Die Strings liegen in optimierten Datenbausteinen.
Beispielweise wenn ich einen String dynamisch in der SPS mit CONCAT zusammensetze, dann muss ich wenn ich direkt auf dem HMI-String arbeite damit rechnen, dass der String während der Bearbeitung gelesen wird.
Jetzt könnte ich auf einem temporären String arbeiten, und wenn dieser fertiggestellt ist dem HMI-String zuweisen. Es ist jedoch nirgends angegeben, dass diese Operation ununterbrechenbar ist. Es wird dann höchstens die Wahrscheinlichkeit verringert, dass ein nicht konsistenter String gelesen wird.
Mit UMOVE_BLK lassen sich direkt keine Strings in "optimierten" DBs verschieben.
Wenn du einen String zusammen baust, kostet das in der CPU wesentlich mehr Rechenzeit, als nur den fertig gebauten auf den Zugriffsbereich des HMI zu kopieren.
Das reine Kopieren sollte also so schnell laufen, das die Wahrscheinlichkeit das HMI liest nur einen Teil der neuen Daten weil es mitten in diesem Kopiervorgang liest, so gering ist, das du eher deinen Platz bei der NASA bekommst und zum Mars fliegst
MfG Fabsi
Das reine Kopieren sollte also so schnell laufen, das die Wahrscheinlichkeit das HMI liest nur einen Teil der neuen Daten weil es mitten in diesem Kopiervorgang liest, so gering ist, das du eher deinen Platz bei der NASA bekommst und zum Mars fliegst
MfG Fabsi
OP
- Beiträge
- 9.189
- Reaktionspunkte
- 2.936
-> Hier kostenlos registrieren
Das mit "die Wahrscheinlichkeit ist sehr gering" hatte ich bei der S7-400 schon einmal die sich bezüglich Kommunikation gleich verhält, und habe das Programm dann anschließend umgestellt als das Problem dann doch gelegentlich aufgetreten ist. Je kleiner das Programm ist, desto größer ist die Wahrscheinlichkeit.
Ich will es aber nicht höchstwahrscheinlich richtig machen, sondern richtig machen.
Und ich habe noch keinen Weg gefunden wie ich es richtig machen kann.
Ich will es aber nicht höchstwahrscheinlich richtig machen, sondern richtig machen.
Und ich habe noch keinen Weg gefunden wie ich es richtig machen kann.
- Beiträge
- 21.965
- Reaktionspunkte
- 6.836
Das kannst Du voll vergessen. Weil SPS zyklisch arbeiten und das auch noch sooo schnell, kann man sich bezüglich Wahrscheinlichkeit für das Auftreten von "unwahrscheinlichen" Ereignissen merken: wenn eine Wahrscheinlichkeit > 0 besteht, dann wird das Ereignis noch zu Lebzeiten des Programmierers und ganz bestimmt auch noch während der Gewährleistungszeit auftreten.Das reine Kopieren sollte also so schnell laufen, das die Wahrscheinlichkeit das HMI liest nur einen Teil der neuen Daten weil es mitten in diesem Kopiervorgang liest, so gering ist, das du eher deinen Platz bei der NASA bekommst und zum Mars fliegst
SPS-programmieren hat exakt zu erfolgen und nicht so schlampig wie bei vielen Computer- oder Smartphone-Programmen. Eine Einstellung "das wird schon nicht passieren, und wenn, dann merkt es bestimmt keiner" zeugt von Verantwortungslosigkeit und disqualifiziert einen SPS-Programmierer für seinen Job.
Harald
- Beiträge
- 11.607
- Reaktionspunkte
- 3.866
Letztlich bleibt eigentlich nur das Arbeiten mit getrennten Datenbereichen für HMI und Logik.
Also eigenen Zykluskontrollpunkt bzw. HMI-Prozessabbild bauen.
Alles andere macht irgendwann Ärger
Gruß
Blockmove
Also eigenen Zykluskontrollpunkt bzw. HMI-Prozessabbild bauen.
Alles andere macht irgendwann Ärger
Gruß
Blockmove
-> Hier kostenlos registrieren
Ich mache bei beiden Richtungen (wenn ich es kann) ein zeitversetztes Freigeben.
Z.B. wenn ich Daten aus der Visu übertragen muss, gebe ich die Daten ein und speichere sie in der SPS ab. Dann muss man bestätigen und eine Wartezeit muss ablaufen. Vorher akzeptiere ich die eingegebenen Daten einfach nicht. So wird kein VOrgang mit halben Daten gestartet.
Auf der Visu läuft das etwas anders. Dort lasse ich die Daten in die Variablen schreiben und lasse dann eine Wartezeit auf der SPS ablaufen, die ein Bit setzt womit ich die Sichtbarkeit der angezeigten Daten steuere. Durch die Wartezeit muss die Visu die Daten gelesen haben, bevor sie im übernächsten Abfragezyklus das Bit zum anzeigen bekommt.
So kann ich zu jeder Zeit sicherstellen, dass nur angezeigt wird was auch vollständig ist.
Das schließt leider schnelle Anzeigenwechsel aus, da ich mindestens 3 Sekunden brauche bis alles korrekt angezeigt wird.
Z.B. wenn ich Daten aus der Visu übertragen muss, gebe ich die Daten ein und speichere sie in der SPS ab. Dann muss man bestätigen und eine Wartezeit muss ablaufen. Vorher akzeptiere ich die eingegebenen Daten einfach nicht. So wird kein VOrgang mit halben Daten gestartet.
Auf der Visu läuft das etwas anders. Dort lasse ich die Daten in die Variablen schreiben und lasse dann eine Wartezeit auf der SPS ablaufen, die ein Bit setzt womit ich die Sichtbarkeit der angezeigten Daten steuere. Durch die Wartezeit muss die Visu die Daten gelesen haben, bevor sie im übernächsten Abfragezyklus das Bit zum anzeigen bekommt.
So kann ich zu jeder Zeit sicherstellen, dass nur angezeigt wird was auch vollständig ist.
Das schließt leider schnelle Anzeigenwechsel aus, da ich mindestens 3 Sekunden brauche bis alles korrekt angezeigt wird.
OP
- Beiträge
- 9.189
- Reaktionspunkte
- 2.936
Zugriffe auf einfache Datentypen stellen auch kein unlösbares Problem dar, da diese höchstwahrscheinlich (wahrscheinlich weil von Siemens nicht dokumentiert) mit atomaren d.h. ununterbrechenbaren Anweisungen geschrieben werden können.
Wenn ich eine z.B. 16-Bit Integervariable beschreibe, dann geschieht das mit einer einzigen Anweisung die nicht unterbrechenbar ist.
Bei Variablen mit größeren Längen wie auch bei Strings ist das wahrscheinlich nicht mit einer atomaren Anweisung möglich.
Wenn ich selber auf einem Controller programmiere und ich Variablen auch in Interrupts verwende, dann ist das nur ohne anzunehmende Fehler möglich wenn ich auf diese Variablen mit atomaren Anweisungen zugreifen kann, oder ich muss die Interrupts für den Zeitraum des Zugriffs sperren. Das kann ich aber dann alles im Datenblatt des Controllers nachlesen, bzw. mir den Assemblercode ansehen.
Bei den 1200/1500 weiß ich das aber nicht wie Siemens das umgesetzt hat. Wenn ich aber davon ausgehe, dass Strings nicht mit atomaren Anweisungen kopiert werden können, fehlen mir so wie es aussieht die Werkzeuge um das zu gewährleisten. Das wäre nur mit einer Anweisung wie dem UMOVE_BLK möglich (das Äquivalent dazu könnte für diesen Zweck auch auf der S7-400 verwendet werden), der aber gerade so wie es aussieht mit Strings nicht funktioniert. Wahrscheinlich ist das Problem mit anderen großen Datentypen wie DT auch vorhanden.
Am einfachsten wäre es wenn es zwei Anweisungen gäbe mit denen es möglich ist HMI-Zugriffe zu sperren und wieder freizugeben.
Wenn ich eine z.B. 16-Bit Integervariable beschreibe, dann geschieht das mit einer einzigen Anweisung die nicht unterbrechenbar ist.
Bei Variablen mit größeren Längen wie auch bei Strings ist das wahrscheinlich nicht mit einer atomaren Anweisung möglich.
Wenn ich selber auf einem Controller programmiere und ich Variablen auch in Interrupts verwende, dann ist das nur ohne anzunehmende Fehler möglich wenn ich auf diese Variablen mit atomaren Anweisungen zugreifen kann, oder ich muss die Interrupts für den Zeitraum des Zugriffs sperren. Das kann ich aber dann alles im Datenblatt des Controllers nachlesen, bzw. mir den Assemblercode ansehen.
Bei den 1200/1500 weiß ich das aber nicht wie Siemens das umgesetzt hat. Wenn ich aber davon ausgehe, dass Strings nicht mit atomaren Anweisungen kopiert werden können, fehlen mir so wie es aussieht die Werkzeuge um das zu gewährleisten. Das wäre nur mit einer Anweisung wie dem UMOVE_BLK möglich (das Äquivalent dazu könnte für diesen Zweck auch auf der S7-400 verwendet werden), der aber gerade so wie es aussieht mit Strings nicht funktioniert. Wahrscheinlich ist das Problem mit anderen großen Datentypen wie DT auch vorhanden.
Am einfachsten wäre es wenn es zwei Anweisungen gäbe mit denen es möglich ist HMI-Zugriffe zu sperren und wieder freizugeben.
- Beiträge
- 9.712
- Reaktionspunkte
- 2.788
tja, da hast Du leider Recht! Nur wer macht das denn in der Praxis? Vor allem wenn Siemens in den tollen 5min Videos einfach ne xbeliebige Variable per Drag n Drop aus dem SPS-Programm in die Visu zieht...
Das Ganze stoert mich bei den 400er schon lange. Bei den 300er ist es zum Glueck kein Problem, solange niemand diesen Haken setzt....
M.M. nach wollte Siemens in den neuen Steuerungen auf Teufel komm raus werbewirksam die Kommunikation beschleunigen! Warum um Gottes Willen haben die das nicht einstellbar gemacht?
Wir habens letztens mal getestet, ner 300er mit dem "priorisierte BuB" Haken kommuniziert genauso schnell wie ne 1500, wenn man die PDU ausser acht laesst.
Die Kommunikation mit HMI und anderen SPSn zu vereinfachen waere mal ne wirklich gute Sache gewesen, stattdessen machen die das mit dem TIA noch kommplizierter...
Danke Siemens!
-> Hier kostenlos registrieren
Harald, ich schrieb nichts von "das merkt schon keiner"...
Da die tollen TIA-CPUs nun aber keinen eigenen Zykluskontrollpunkt mehr haben, bekommt man die gleichen Probleme wie bei den 400er CPUs vorher auch.
(gut, das wissen wir alle...)
Also was bleibt einem dann an Möglichkeiten?
a) eigenen Zykluskontrollpunkt schreiben. / Hier besteht nun einmal die Gefahr, dass das HMI genau in diesem kurzen Umkopierzeitraum liest/schreibt. Da bleibt nur die Wahrscheinlichkeitsanalyse mit der man dann bewerten muss, ob und wie wahrscheinlich dieses Ereignis eintreten kann und den Betrieb der Anlage stört.
b) eine Möglichkeit wie zombie sie beschreibt, was noch aufwändiger ist und alle sonstigen Nachteile enthält. Zusätzlichen Eingriff durch den Bediener und Wartenzeiten bei der Kommunikation.
( Möglichkeit c) einfach so arbeiten, als wäre es wie bei den 300er geht auch, klammere ich hier aber einfach aus, weil sche*** )
Aus diesen Möglichkeiten muss nun der Programmierer verantwortungsbewusst, die für seine Anwendung optimale Version auswählen und korrekt umsetzen.
Wir haben auch Anlagen, bei der teils für eine SPS "riesige Datenmengen" auf einen Schlag geändert werden. Das geht dann eben nur bei Auftragswechsel oder in Zeiten auf denen die SPS eben nicht auf diese Daten zugreift.
Solltest du noch eine mir bisher unbekannte wesentlich bessere Möglichkeit kennen, dann würde ich mich natürlich freuen, dies mal an einer unserer Anlagen auszuprobieren
MfG Fabsi
OP
- Beiträge
- 9.189
- Reaktionspunkte
- 2.936
Bei der 400er kann ich dieses Problem aber durch UBLKMOV konkret bei Strings umgehen.
Wir haben nämlich beispielsweise eine Anlage, wo wir einem MES-System einen eingescannten Barcode als String übermitteln. Bzw. das MES greift über einen OPC-Server auf die Daten zu. Ich wollte zwar ein zusätzliches Handshakesignal, aber der vom MES wollte es so haben, dass er auf eine Änderung des Strings reagiert. Funktioniert ja auch prinzipiell.
Wenn wir die Anlage jetzt mit einer 1500er umsetzen dann muss ich dem Kunden sagen, dass es jetzt einmal wöchentlich zu einem Datenversatz kommt, weil das mit der 1500er nicht mehr zuverlässig umzusetzen ist. Bei 10.000 Stück pro Tag ist man sehr schnell an der Eintrittswahrscheinlichkeit von 1.
Wir haben nämlich beispielsweise eine Anlage, wo wir einem MES-System einen eingescannten Barcode als String übermitteln. Bzw. das MES greift über einen OPC-Server auf die Daten zu. Ich wollte zwar ein zusätzliches Handshakesignal, aber der vom MES wollte es so haben, dass er auf eine Änderung des Strings reagiert. Funktioniert ja auch prinzipiell.
Wenn wir die Anlage jetzt mit einer 1500er umsetzen dann muss ich dem Kunden sagen, dass es jetzt einmal wöchentlich zu einem Datenversatz kommt, weil das mit der 1500er nicht mehr zuverlässig umzusetzen ist. Bei 10.000 Stück pro Tag ist man sehr schnell an der Eintrittswahrscheinlichkeit von 1.
- Beiträge
- 11.607
- Reaktionspunkte
- 3.866
@Thomas
Bei der Kopplung zum MES kämpe ich genau mit den selben Themen.
Ich arbeite hier mit getrennten Datenbereichen, aber auch hier sind zusätzliche Handshakes notwendig.
Da ich aber systembedingt nix am Verhalten ändern kann, muß eben der MES-Programmierer hier damit klar kommen.
Allerdings arbeiten die MES-Kollegen wohl zusammen mit Siemens an OPC-UA. Da werden sie wohl auf die selben Tretminen treffen
Gruß
Blockmove
Bei der Kopplung zum MES kämpe ich genau mit den selben Themen.
Ich arbeite hier mit getrennten Datenbereichen, aber auch hier sind zusätzliche Handshakes notwendig.
Da ich aber systembedingt nix am Verhalten ändern kann, muß eben der MES-Programmierer hier damit klar kommen.
Allerdings arbeiten die MES-Kollegen wohl zusammen mit Siemens an OPC-UA. Da werden sie wohl auf die selben Tretminen treffen
Gruß
Blockmove
Similar threads
