TIA 1515 F Steuerung, kleine Änderung im nicht sicheren Teil-> F Program nicht konsistent

jok3r

Level-2
Beiträge
370
Reaktionspunkte
8
Zuviel Werbung?
-> Hier kostenlos registrieren
1515 F Steuerung, kleine Änderung im nicht sicheren Teil-> F Program nicht konsistent

Hallo,
wir setzen seit neuem die F Steuerung von Siemens ein. Biser hatte ich nur eine 1515 2PN F in der Hand.
Diese zeigt die Probleme, dass wenn ich eine Kleinigkeit zb ein "und" zu einem "oder" ändere ich das komplette Program übertragen muss(sporadisch). Die SPS bleibt im Hochlauf stehen und geht in Stop weil es heißt das F Program ist nicht konsistent.
Kennt diese problematik jemand?

Gruß
 
Moin,
Ähnliche Phänomene habe ich in V13 beobachtet. Bei V14 tritt das eigentlich nicht mehr auf.
Konsistenz im F-Programm stellst du her, indem du das F-Programm übersetzt und dann Software lädst.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo,
wir setzen seit neuem die F Steuerung von Siemens ein. Biser hatte ich nur eine 1515 2PN F in der Hand.
Diese zeigt die Probleme, dass wenn ich eine Kleinigkeit zb ein "und" zu einem "oder" ändere ich das komplette Program übertragen muss(sporadisch). Die SPS bleibt im Hochlauf stehen und geht in Stop weil es heißt das F Program ist nicht konsistent.
Kennt diese problematik jemand?

Gruß

In welchem Bereich führst du denn die Änderungen durch? Wenn du sie im F-Bereich durchführst musst du in der tat übersetzen und (mit gezwungenem Stop) neu laden. Aber das ist ja nichts TIA-Eigenes bzw. Neues.
 
Das ist eigentlich so nicht akzeptabel, und kann nicht sein. Ich muss jetzt aber zugestehen ich hab nie nachgesehen ob die CRC noch die selbe ist, aber ich tendiere zu nein. Blödegesagt müsste ich immer wieder sicherstellen dass das F Program das selbe ist !!!
Ab und zu würd mir echt übel.....
Aber schön das dieses "Phänomen" eigentlich nicht mehr vorhanden sein soll :D

Gruß
 
Hallo Jok3r,

ich habe erst bis letzte Woche selber eine Maschine in Betrieb genommen mit einer 1515F und kann daher sagen, dass das von Dir beschriebene Verhalten absolut nicht normal ist. Ich habe TIA V14 Update 2 verwendet und passend dazu Step 7 Safety V14.

Edit: Das was Blackpeat geschrieben hat klingt für mich plausibel.
 
Zuletzt bearbeitet:
Ich versuche die Variablen aus dem nichtsicheren Bereich, welche ich im sicheren Bereich nutzen will/muss in einen extra DB zu packen. Dann hab ich einige Variablen zwar doppelt, aber wenn ich im nichtsichern DB mal was ändern muss, bleibt der "Kommunikations-DB" der selbe ohne Änderungen. Anknüpfend an Blackpeats Vermutung.
 
Grundsätzlich ist es empfehlenswert alle Variablen von und zum F-Programm zu entkoppeln.
Dazu nutzt man wie in vielen Siemens Beispielen zwei Datenbausteine, typischer Weise als
'DataFromSafety' und 'DataToSafety'. bezeichnet.

Hm, ich hab das bei meinem letzten Projekt nicht so gemacht. Hat den Vorteil, dass man im "normalen" Programm sofort sieht, wenn Safety-Variablen genutzt werden, die sind ja gelb hinterlegt.
Ansonsten habe ich bisher keine weiteren Probleme damit gehabt, wozu genau ist das also gut?
Allerdings nutze ich bisher keine "unsicheren" DB-Variablen im Safety-Programm.
 
Hi,

hab die Probleme mit dem nicht konsistenten Sicherheitsprogramm auch so gehabt. Dann die Datenbausteine wie von Credofire ausgelagert und das hat das Problem bei mir zumindest behoben.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hm, ich hab das bei meinem letzten Projekt nicht so gemacht. Hat den Vorteil, dass man im "normalen" Programm sofort sieht, wenn Safety-Variablen genutzt werden, die sind ja gelb hinterlegt.
Ansonsten habe ich bisher keine weiteren Probleme damit gehabt, wozu genau ist das also gut?
Allerdings nutze ich bisher keine "unsicheren" DB-Variablen im Safety-Programm.
Ich packe die Variablen aus dem Safety-Bereich in einen F-DB. So habe ich die Variable dann im nicht Safety-Bereich gelb hinterlegt und sehe es sofort.
Natürlich umgekehrt auch dann in einen normalen DB.
 
Hm, ich hab das bei meinem letzten Projekt nicht so gemacht. Hat den Vorteil, dass man im "normalen" Programm sofort sieht, wenn Safety-Variablen genutzt werden, die sind ja gelb hinterlegt.
Ansonsten habe ich bisher keine weiteren Probleme damit gehabt, wozu genau ist das also gut?
Allerdings nutze ich bisher keine "unsicheren" DB-Variablen im Safety-Programm.

Aber das nutzen von Safety Variablen, kann dazu führen das TIA beim anklicken dieser
Gelben Variable, nach dem Passwort für das Sicherheitsprogramm fragt. Meiner Meinung
nach kann das vielleicht zu den Effekt führen, das noch einmal alles übersetzt und übertragen
werden muss.
Dieses kann man durch Verwendung der nicht Sicheren Koppel-DBs vermeiden. Dieses für
jeweils für beide Richtungen getrennt zu machen, halte ich für sehr angebracht.

Zur Verwendung von nicht Sicheren Signalen im Safety Teil kann ich dir folgendes
Beispiel benennen. Wenn ich Heizungen mit einen Halbleiterschütz ansteuere, habe ich immer ein
Hardware Schütz vorgeschaltet. Wenn jetzt die Heizung, einer mir vergebenen Grenze überschreitet
oder ich einen Drahtbruch am Fühler habe, schalte ich das Hardwareschütz im Safety Teil ab.
 
Das mit dem Passwort hab ich so noch nicht erlebt. Nur beim Rückladen von Programmteilen muß man aufpassen, dass man nicht oben auf der Wurzel ("Programm") steht, dann wird der Safety-Bereich irgendwie mit angefaßt und macht Ärger.
 
Zurück
Oben