Kleine Exkursion der Anlagenmigrierung

[vollmi]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich habe grad wieder ein Paar Anlagen die migriert werden sollen da die SPS soweit gealtert sind, dass die Serielle RS485 Kommunikation soviele Retries macht dass zu oft Kommfehler auftauchen oder Remote IO Module in Timeout laufen und einfach die default Ausgänge setzen.

Aus Zeitgründen habe ich schon eine Anlage bestehend aus zwei OP45 der Firma ABB auf eine s7-1512sp migriert. Das heisst zwei SPS zusammengefasst und in eine S7 geworfen. die gehören Programmtechnisch eh zusammen und haben zuvor Daten ausgetauscht (Kältemaschine und Rückkühler)

Das Programm ist im Original vorwiegend so geschrieben:

Jetzt habe ich die Variablen (die waren da schon als Absolutadressensymbole enthalten) Das heisst grundsätzlich ist das Symbolik, aber sie bildet die Absolutadresse ab. Also hab ich gleich in Absolutadressen gearbeitet.

Also für jede Anlage einen DB welche den alten Speicherbereich abbildet gebaut.


Der Plan war, das Programm abzuschreiben und nichts daran zu verändern um die Umstellung möglichst klein zu halten. Nachdem ich die Quelle aber etwas Studiert habe, habe ich mich mehr oder weniger davon verarbschiedet.
FUP sah in dem DOS Programm einigermassen vernünftig aus und war auch recht kompakt. In TIA sieht FUP einfach nur bescheuert aus. Und man kommt auch nicht wirklich vorwärts da man ständig versucht mit der Tastatur von Variablenfeld zu variablenfeld zu navigieren und am schluss doch vieles mit der Maus machen muss.

Dazu kommt. Im OP wurden sehr viele Variablen an verschiedenen Stellen beschrieben auch nacheinander und der Letzte gewinnt. im Leitsystem und im Textdisplay hat man kein Flackern der Werte gesehen aber ich gehe davon aus in S7-1500 ohne Zykluskontrollpunkt hätte nachher der Wert im Comfortpanel und auf dem Leitsystem geflackert.

Also mehrmals eine Variable beschreiben fällt flach, ich hätte es auf jedenfall irgendwie zusammenfassen müssen. Ein Künstlicher Zykluskontrollpunkt wäre mühsam zu realisieren Also fasse ich so mehrfachvariablenbeschreibungen zusammen. Und weils in FUP so umständlich ist, hab ich dann auf SCL umgestellt geht schneller zu tippen aber ist nicht mehr ganz so übersichtlich zu beobachten.


Die Crux ist jetzt natürlich. Dass im alten FUP das was unten steht immer gewonnen hat. Also der letzte der Auf die Variable schreibt, wenn man das jetzt in ein IF Konstukt packt. Muss man das Alte Programm von unten nach oben im IF von oben nach unten abbilden.

Ich wollte jetzt mal eine Diskussion anfangen. Wie löst ihr solche Ablösungen? Schreibt ihr die Programme neu? Oder versucht ihr die Software ohne Änderungen zu übernehmen
Habt ihr Beispiele? Tips?

 

[MFreiberger]

Moin vollmi,

neu schreiben oder übernehmen kommt m.E. auf die Komplexität des Programms an. Wenn das Programm überwiegend aus einfachen logischen Verknüpfungen besteht, würde ich mir über eine Migration gedanken machen. Kommen Kommunikationsaufgaben, indirekte Adressierung etc. dazu, würde ich darüber nachdenken, das Programm neu zu schreiben.

Für den konkreten Fall der Wertzuweisung finde ich KOP eigentlich eine schöne Lösung.

Also erst einmal 'MOVE' aufrufen, um einen Defaultwert zu laden. Dann, in Abhängigkeit von digitalen Verknüpfungen wieder 'MOVE' aufrufen, um einen entsprechenden Wert zu laden.

VG

MFreiberger

 

[vollmi]

Zuviel Werbung?
-> Hier kostenlos registrieren

Für den konkreten Fall der Wertzuweisung finde ich KOP eigentlich eine schöne Lösung.

Also erst einmal 'MOVE' aufrufen, um einen Defaultwert zu laden. Dann, in Abhängigkeit von digitalen Verknüpfungen wieder 'MOVE' aufrufen, um einen entsprechenden Wert zu laden.

Das Problem ist halt. im Beispiel wird ja auf RW 106 ein Wert gemoved. Wenn ich da einen Defaultwert reinschreibe mit Move und danach je nach digitaler verknüpfung diesen Wert überschreibe, dann ändert sich der Wert innerhalb des Programmzyklus diverse male. Und wenn ein SCADA oder WinCC Panel drauf zugreift kriegt der den Wert irgendwo im Zyklus mit. Was dann eben zu den Flackernden Werten im Panel oder flackernden Objekten führt.

 

[ducati]

Ich wollte jetzt mal eine Diskussion anfangen. Wie löst ihr solche Ablösungen? Schreibt ihr die Programme neu? Oder versucht ihr die Software ohne Änderungen zu übernehmen
Habt ihr Beispiele? Tips?

Grundsätzlich versuche ich, alles neu zu machen, nach unserem aktuellen Programmierstandard...

Das geht aber nur, wenn man verfahrenstechnisch/technologisch versteht, was man machen will...

Wenn man keine Ahnung von der Anlage hat, wirds aber so oder so schwierig, da man spätestens bei der Inbetriebnahme dann auch keinen Plan hat. Und die Aussage, es ist alles so wie vorher, funktioniert aber trotzdem nicht, hilft dann auch nicht

Gruß.

 

[MFreiberger]

Moin vollmi,

ich hätte es so versucht:



VG

MFreiberger

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

ich hätte es so versucht:

Anhang anzeigen 50720

Du hast da 3 Zuweisungen an "TEST_DATA".RH.*00106*
Wenn Du diese Variable an einem HMI oder Leitsystem anzeigst, dann wird da der angezeigte Wert "flackern": mal den zuletzt zugewiesenen Wert anzeigen, mal den initialen Wert 0 und manchmal den Wert von der mittleren Zuweisung. Damit die Anzeige nicht flackert, müsstest Du nach der letzten Zuweisung den Wert in eine zusätzliche Variable für das HMI kopieren.

Harald

 

[escride1]

Ich erstelle einen DB in welchem die Variable liegt die mit dem OP verbunden ist. Im eigentlichen Baustein beschreibe ich mehrmals eine Temp-Variable, die im letzten Netzwerk auf den DB geschoben wird. Somit gibt es kein Flackern und die Werte sind zyklisch einmalig bearbeitet worden, ändern sich also nicht mittendrin.

Bei 300er-Anlagen konnte die Temp-Variable noch mit Falschwerten überschrieben werden wenn ein anderer OB durch Zwischenaufruf abgearbeitet wurde, das Verhalten habe ich bisher bei keiner 12/1500er mehr gehabt und bin mit dieser Lösung zufrieden.

Oder hab ich nur Glück und meine Temp-Variablen bleiben stabil, bei anderen jedoch nicht?


Anlagen neu programmieren oder migrieren hängt bei uns vom Budget des Kunden ab . 90% wollen nur Korrekturen und Optimierungen aber kein neues Programm weil sie Angst haben das danach nix mehr geht :lach:.

 

[PN/DP]

Bei 300er-Anlagen konnte die Temp-Variable noch mit Falschwerten überschrieben werden wenn ein anderer OB durch Zwischenaufruf abgearbeitet wurde

Kannst Du das mal genauer beschreiben? Meines Wissens ist das nicht möglich, daß ein unterbrechender OB auf Temp-Variablen des unterbrochenen Bausteins zugreift oder diese gar verändert (höchstens bei Firmware-Fehlern)

Harald

 

[vollmi]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich erstelle einen DB in welchem die Variable liegt die mit dem OP verbunden ist. Im eigentlichen Baustein beschreibe ich mehrmals eine Temp-Variable, die im letzten Netzwerk auf den DB geschoben wird. Somit gibt es kein Flackern und die Werte sind zyklisch einmalig bearbeitet worden, ändern sich also nicht mittendrin.

Früher (s7-300 und andere) konnte man eben aus dem SPS Programm mehrfach auf Variablen schreiben und trotzdem hat auf dem Leitsystem nichts geflackert und wenn nichts auf die Variable geschrieben hat, konnte man aus dem Leitsystem ebenfalls auf ebenjene Variable schreiben. Bei den SPS ohne Zykluskontrollpunkt muss man eben darauf achten, das man nur ein mal auf eine Variable schreibt und eine weitere Variable nutzt welche vom Leitsystem geschrieben und auf Änderung überwacht werden muss um auf die SPS Variable übertragen zu werden.

Ich weiss aber z.B. auch nicht ob die OP einen Zykluskontrollpunkt hatten oder ob es einfach nie aufgefallen ist da die Zykluszeit ja doch sehr lang ist und die Chance dass das Leitsystem in den 0.1 Prozent des Zyklus zugereift in denen die Variable dreimal überschrieben wird recht klein ist.

 

[de vliegende hollander]

Hi Vollmi,

Wenn ich Retrofit Anlagen hab wird auch nach unser neuste Stand programmiert.
Aber erst:
Parameter und Anlagen spezifike Logik werden aber aus dem alte programm ausgewertet.
Mit original Daten verglichen. Und Funktionspläne kontrolliert.

Etwas anders sieht es aus bei Anlagen wo nur der SPS getauscht wird.
Im Bereich Errregung und Synchronisation des Generators wird die alte FUP Logik 1 zu 1 übernommen.

Alte Programme in ALW werden immer komplet neu.

Mit Zykluskontrollepunkt hab ich noch niet Problemen gehabt (S7-1500)
Nicht mit Comfortpanel, WinCC Professional und WinCC 7.5. Wer weiss mach ich was richtig

Grüß Bram

 

[escride1]

Früher (s7-300 und andere) konnte man eben aus dem SPS Programm mehrfach auf Variablen schreiben und trotzdem hat auf dem Leitsystem nichts geflackert und wenn nichts auf die Variable geschrieben hat, konnte man aus dem Leitsystem ebenfalls auf ebenjene Variable schreiben. Bei den SPS ohne Zykluskontrollpunkt muss man eben darauf achten, das man nur ein mal auf eine Variable schreibt und eine weitere Variable nutzt welche vom Leitsystem geschrieben und auf Änderung überwacht werden muss um auf die SPS Variable übertragen zu werden.

Ich weiss aber z.B. auch nicht ob die OP einen Zykluskontrollpunkt hatten oder ob es einfach nie aufgefallen ist da die Zykluszeit ja doch sehr lang ist und die Chance dass das Leitsystem in den 0.1 Prozent des Zyklus zugereift in denen die Variable dreimal überschrieben wird recht klein ist.

Ja, bei alten Panels sowie Visus mit WinCC flex und 300ern habe ich auch nie Probleme gehabt, auch unsere alten Anlagen kennen das Flackerproblem nicht.
Aber seit den 1200/1500ern bestehen diese Probleme, daher nutze ich dann diesen Umweg, der im eigentlichen Sinne ja nicht wirklich groß ist und zumindest für mich habe ich somit die Lösung gefunden das zu umgehen.

Natürlich kann man auch alles in Abfragen/Verknüpfungen legen, was bestimmt auch sauberer ist. In einigen Anlagen sehe ich oft das für sowas dann Sprünge gemacht werden um nur einmal zu schreiben, aber ob das übersichtlicher ist lass ich mal dahingestellt.

 

[escride1]

Zuviel Werbung?
-> Hier kostenlos registrieren

Kannst Du das mal genauer beschreiben? Meines Wissens ist das nicht möglich, daß ein unterbrechender OB auf Temp-Variablen des unterbrochenen Bausteins zugreift oder diese gar verändert (höchstens bei Firmware-Fehlern)

Harald

Das konnte ich bei 300er-CPUs schon beobachten.
Als Beispiel:
Speziell wurde vor meiner Zeit hier für die PID-Regler immer ein OB aufgerufen in welchem ein FB mit dem PID lag.
Sobald der FB geladen wurde und der wiederum einen FB aufgerufen hat, so hat sich beim unterbrochenen Baustein die Temp-Variable auf einen zufälligen Wert gesetzt, genauso als wenn er das erste Mal gestartet worden wäre und daher einen zufälligen Wert besitzt. Das ist so nie groß aufgefallen, außer das bei überwachten Werten sporadisch eine Störung ausgegeben wurde weil z.B. Temperatur zu hoch ist. Das wurde dann umgangen indem man einfach ein TON davor gesetzt hat weil man dachte das die Analogeingänge flackern.
Die eigentliche TEMP-Variable war oft ein Teil des Konstrukts
NW1: PEW256->TempVar
NW2: Tempvar/10->MW40 (Istwert Temperatur)
.

Also:
FC aufrufen mit TEMP
in NW1 TEMP beschreiben
OB35 aufrufen
OB ruft FB auf, der öffnet den FB PID
FB wird beendet
OB wird beendet -> Rückkehr in NW2
NW2 hat anderen Wert am TEMP, für einen einzigen Zyklus, tritt aber nicht immer auf weil es nur alle x Zyklen zufällig aufeinandertrifft.

Lädt man im OB35 hingegen den PID direkt, ohne aufrufenden FB, so gab es keine Probleme. Kommt also evtl. nur vor wenn ein OB einen FB der wiederrum einen FB aufruft programmiert wird.

Ob das ein Bug ist weiß ich nicht, ich habe mich damit auch noch nie an Siemens gewandt weil ich schon immer der Meinung war Temp ist halt Temp und habe solche Probleme dann anders gelöst. Ich habe mich zu 300er-Zeiten aber auch nie wirklich mit Firmware beschäftigen müssen, ich habe sogar seltenst mal Updates gemacht, lief ja immer alles problemlos, wozu also neueren Simatic-Manager installieren wenn die vorhandene Hardware programmierbar ist? Es wurde programmiert und bei Fehlern halt so geschrieben das es einwandfrei funktionierte. Man hatte ja auch nicht auf jeder Baustelle Internet um mal eben zu recherchieren oder aber die Zeit sich während der Inbetriebnahme telefonisch mit dem Support auseinanderzusetzen der eh lange nur auf wenige Sätze beschränkt war:
"Was für ein PG nutzen Sie?"
"HP ..."
"Wird nicht unterstützt, bitte kostenpflichtigen Support kontaktieren"

Die ganze Geschichte mit Firmware muss ich erst seit TIA beachten.

Also entweder Bug oder gewollt, oder vielleicht aber haben Temp-Variablen in 300ern auch einen beschränkten Speicherbereich der von allen Bausteinen genutzt wird und irgendwann überlauft und überschrieben wird und heute sind die Speichergrenzen fast irrelevant und daher kommt es nicht mehr, keine Ahnung.