Step 7 Einzelne Bits sind eingefroren

Zuviel Werbung?
-> Hier kostenlos registrieren
Und es wurde auch nicht gesagt das sich Merker aufgehangen haben, sondern das sie eingefrohren sind.

Daher würde ich zu einer Schaltschrankheizung raten...
Oder einer Tüte Deutsch

ODER dumme Kommentare einfach lassen die einem nicht weiterhelfen, was ich echt bevorzugen würde o_O
 
Zuviel Werbung?
-> Hier kostenlos registrieren
... aber ich tippe mal - weil das wird ja immer wieder gerne gemacht :
- Timer sind innerhalb eines IF-Blocks oder einem CASE programmiert
- mit den Merkern wird es wohl so ähnlich sein
-> also bedingte Bearbeitung ... und kein korrekter Umgang damit ...
Hallo Larry,

danke für deine Antwort.

den Code von der AWL SK ist weiter oben gepostet.

Das Problem mit den Timern sieht so, dass sie dauerhaft nach CPU start gesetzt gewesen sind, sofern der Messwert i.O. war. Das hat über Jahre funktioniert. Nach dem Softwareupdate (code) und der Reinitialisierung des Bausteinst oder what ever, kam es dann dazu, dass der TON nicht mehr gestartet ist.


Hier ein Bild. Der Vgl. Operator wurde von mir hinzugefügt. Davor lag die Zuweisung dauerhaft auf TRUE
1720782756253.png

Der Code im FB
//Freigabe der Produktion
IF #"IST Leitfähigkeit" <= #"SP Leitfähigkeit Prod." AND #"Freigabe Produktion" THEN
#"HM Start Prod. Time" := TRUE;
ELSE
#"HM Start Prod. Time" := FALSE;
END_IF;
#"Timer Produktion"(IN := #"HM Start Prod. Time",
PT := INT_TO_DINT(#"Zeit Start Produktion") * 1000,
Q => #"Produktion Ein");

Hier muss man dazu sagen, dass die Leitfähigkeit beim Auftreten des Problems dauerhaft unter dem SP lag.
 
Timer im TIA brauchen eine Flanke zum Starten, sonst wird das nüscht. Wenn direkt zu CPU-Start ein TRUE am IN liegt, läuft der Timer nicht los.

Und größere Mengen Code lassen sich besser lesen, wenn sie sinnvoll formatiert sind. Dafür gibt's die Möglichkeit, das ganze als Code zu formatieren.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
den Code von der AWL SK ist weiter oben gepostet.
Ich muss dir gestehen, dass ich du diese Schrittkette, so ohne Status, nicht durchblicke. Vielleicht ist es jetzt ja ein guter Zeitpunkt das Ganze mal zu überarbeiten.

Das Problem mit den Timern sieht so, dass sie dauerhaft nach CPU start gesetzt gewesen sind, sofern der Messwert i.O. war. Das hat über Jahre funktioniert. Nach dem Softwareupdate (code) und der Reinitialisierung des Bausteinst oder what ever, kam es dann dazu, dass der TON nicht mehr gestartet ist.
Für einen IEC-Timer ist es wichtig, dass er zur Laufzeit einen Flankenwechsel mitbekommt. Aus deiner Beschreibung entnehme ich, dass dies nicht der Fall ist und das wird hier schon das Problem sein. Das hat jetzt auch gar nichts mit der Migration zu tun ...

Den folgenden Code solltest du auf alle Fälle auch anders schreiben - sieht dann auch m.E. schöner aus.
Der Code im FB
//Freigabe der Produktion
IF #"IST Leitfähigkeit" <= #"SP Leitfähigkeit Prod." AND #"Freigabe Produktion" THEN
#"HM Start Prod. Time" := TRUE;
ELSE
#"HM Start Prod. Time" := FALSE;
END_IF;
#"Timer Produktion"(IN := #"HM Start Prod. Time",
PT := INT_TO_DINT(#"Zeit Start Produktion") * 1000,
Q => #"Produktion Ein");
Das könnte dann z.B. so aussehen :
Code:
"HM Start Prod. Time" := (#"IST Leitfähigkeit" <= #"SP Leitfähigkeit Prod.") AND #"Freigabe Produktion" ;
#"Timer Produktion"(IN := #"HM Start Prod. Time",
                    PT := INT_TO_DINT(#"Zeit Start Produktion") * 1000,
                    Q => #"Produktion Ein");
... wobei ich jetzt nicht beurteilen kann was HM Start Prod. Time genau ist ...
 
Zuletzt bearbeitet:
Mal unabhängig von deinem Problem, warum wird hier eigentlich mit (vermutlich) AlwaysHigh verundet?
1720783587246.png

Soll "VKE HIGH" überhaupt dem ImmerTRUE entsprechen?
 
Vielleicht ist es jetzt ja ein guter Zeitpunkt das Ganze mal zu überarbeiten.
Sehe ich auch so.

Auch folgende und auch die AWL Konstrukte gehören einfach mal überholt:
Code:
IF #"IST Leitfähigkeit" <= #"SP Leitfähigkeit Prod." AND #"Freigabe Produktion" THEN
    #"HM Start Prod. Time" := TRUE;
ELSE
    #"HM Start Prod. Time" := FALSE;
END_IF;
 
Mal unabhängig von deinem Problem, warum wird hier eigentlich mit (vermutlich) AlwaysHigh verundet?
Anhang anzeigen 79724

Soll "VKE HIGH" überhaupt dem ImmerTRUE entsprechen?
Das KANN zu Engineering-Zwecken sinnvoll sein. Ich habe in allen TIA-Projekten zwei Benutzerkonstanten ("IBN_FALSE" und "IBN_TRUE"), die ich an Code-Bereiche anhänge, die ich später schnell wiederfinden will, beispielsweise weil ich dort nochmal nachbessern muss.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
das Problem gibt es doch erst seit dem Hochrüsten. Richtig?
Wenn dem so ist, ist es doch naheliegend, in den Versionsunterschieden vom Tia-Portal nach der Ursache zu suchen
 
das Problem gibt es doch erst seit dem Hochrüsten. Richtig?
Wenn dem so ist, ist es doch naheliegend, in den Versionsunterschieden vom Tia-Portal nach der Ursache zu suchen
Das halte ich für sehr unwahrscheinlich - im Grunde schreibt der OP ja auch was Ähnliches.
In jedem Fall aber läßt der dargestellte Code genug Spielraum für Fehlverhalten ...
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich muss dir gestehen, dass ich du diese Schrittkette, so ohne Status, nicht durchblicke. Vielleicht ist es jetzt ja ein guter Zeitpunkt das Ganze mal zu überarbeiten.


Für einen IEC-Timer ist es wichtig, dass er zur Laufzeit einen Flankenwechsel mitbekommt. Aus deiner Beschreibung entnehme ich, dass dies nicht der Fall ist und das wird hier schon das Problem sein. Das hat jetzt auch gar nichts mit der Migration zu tun ...

Den folgenden Code solltest du auf alle Fälle auch anders schreiben - sieht dann auch m.E. schöner aus.

Das könnte dann z.B. so aussehen :
Code:
"HM Start Prod. Time" := (#"IST Leitfähigkeit" <= #"SP Leitfähigkeit Prod.") AND #"Freigabe Produktion" ;
#"Timer Produktion"(IN := #"HM Start Prod. Time",
                    PT := INT_TO_DINT(#"Zeit Start Produktion") * 1000,
                    Q => #"Produktion Ein");
... wobei ich jetzt nicht beurteilen kann was HM Start Prod. Time genau ist ...
Vielen Dank für den Tipp mit dem TON Input
 
Mit dieser Aussage wäre ich hier im Forum gaaaanz vorsichtig. Es gibt hier viele sehr aktive Mitglieder deren Muttersprache nicht Deutsch ist, mit einer solchen Einstellung steht man sonst nämlich schnell alleine da.
☹️
Ich bin für konstruktive Gedanken immer dankbar aber wenn in einem Forum jemand Hilfe sucht, halte ich es für falsch dumme Witze zu machen nur weil jemand das Fachjargon nicht kennt. Und der war nicht mal witzig.
 
Timer im TIA brauchen eine Flanke zum Starten, sonst wird das nüscht. Wenn direkt zu CPU-Start ein TRUE am IN liegt, läuft der Timer nicht los.

Und größere Mengen Code lassen sich besser lesen, wenn sie sinnvoll formatiert sind. Dafür gibt's die Möglichkeit, das ganze als Code zu formatieren.

Ich versuche den Code nochmal zu formatieren:
Vorab:
TRNS = #HM_S2_InfoBox AND #S2_InfoBox // TRNS wird genutzt, um die Variable Int = Schrittnummer hochzuzählen. Die Zuweisung für TRNS findet vor dem nachfolgenden Code statt.

Ich würde den AWL Code auch gerne in SCL umwandeln aber Zeit und Geld. Montag sehe ich mir die Geschichte vor Ort an und kann dann ein Update liefern woran es gelegen hat. Ich vermute #HM_S2_InfoBox ist daran schuld, dass sich die SK aufgehangen hat.


Code:
NW12 - Schrittkettenablauf
//Rücksetzen der Transitionsflanke

     A     #TRNS_Flanke
     R     #TRNS_Flanke
//Flanke zur Handweiterschaltung
     A     #Hand_Takt
     FP    #FP_Hand_HM
     =     #FP_Hand
//Initialisierung Schrittanfang
     L     #Schrittnummer
     L     0
     <>I
     JC    M131
     L     1
     T     #Schrittnummer
//Initialisierung Schrittende
M131: L     #Schrittnummer
     L     9
     <I
     JC    M132
     L     1
     T     #Schrittnummer
//Sprung in einen vorgegebenen Schritt
M132: A     #TRNS
     A     #Sprung
     JCN   M133
     L     #Sprungziel
     T     #Schrittnummer
     S     #TRNS_Flanke
     JU    M135
//Schrittweiterschaltung - // Meine Interpretierung: Trifft "TRNS" zu, wird auf M134 gesprungen, anschließend auf M135.
M133: A     #TRNS
AN    #Hand_Ein
     O
     A     #Hand_Ein
     A     #FP_Hand
     JC    M134
     JU    M135
M134: L     #Schrittnummer
      INC   1
T     #Schrittnummer
S     #TRNS_Flanke
//Schrittzuordnung
M135: L     #Schrittnummer
     L     1
     ==I
     =     #HM_S1_Standby
     =     #S1_Standby
     L     #Schrittnummer // Meine Interpretation: Trifft der Vergleich zu, wird HM_S2 usw. gesetzt.
     L     2
     ==I
     =     #HM_S2_InfoBox  // Hier wird HM_S2 gesetzt, oder auch nicht da die SK hängen bleibt.
     =     #S2_InfoBox
     L     #Schrittnummer
     L     3
     ==I
     =     #HM_S3_Freigabe
     =     #S3_Freigabe
     L     #Schrittnummer
     L     4
     ==I
     =     #HM_S4_Start_Steri
     =     #S4_Start_Steri
     L     #Schrittnummer
     L     5
     ==I
     =     #HM_S5_Verz_LZ
     =     #S5_Verz_LZ
     L     #Schrittnummer
     L     6
     ==I
     =     #HM_S6_LZ_Steri
     =     #S6_LZ_Steri
     L     #Schrittnummer
     L     7
     ==I
     =     #HM_S7_Druckabbau
     =     #S7_Druckabbau
     L     #Schrittnummer
     L     8
     ==I
     =     #HM_S8_Quit_SN
     =     #S8_Quit_SN
//Schrittnummer Übertragen

     L     #Schrittnummer
     T     #S_NR
//Restlaufzeit übertragen

     L     #Zeit
     T     #Laufzeit
//Rücksetzen der Transitionsbedingung

     A     #TRNS_Flanke
     R     #TRNS
     R     #TRNS_Timer
//Reset Sprungbefehl
     A     #Sprung
     R     #Sprung
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Leerzeichen in Variablen.. schade 🥺
Hey DCDCDC,

neue Bausteine die von mir verfasst werden, haben in etwa diesen Styling Guide:

Static Variablen:

statVariable1
statVariable2 isw.

temp Variablen:

tempVariable1
tempVariaible2

Constanten - CAPS ON

Input und Output ohne.

Aufgerufene Instanzen:

Inst.Instance1 usw.



Ich muss aber dazu sagen, dass ich längere Variablen auch mit Leerzeichen verfasse. Was spricht denn dagegen?
 
Ich bin für konstruktive Gedanken immer dankbar aber wenn in einem Forum jemand Hilfe sucht, halte ich es für falsch dumme Witze zu machen nur weil jemand das Fachjargon nicht kennt. Und der war nicht mal witzig.
Dumm war der Witz nicht, denn er ging auf Deine Formulierung ein und ich fand ihn passend und zum Schmunzeln.
Ja, der Kommentar hat Dich zugegebenermaßen nicht weitergebracht, aber dieses Forum erhebt auch nicht den Anspruch bierernst zu sein.
@NBerger ist hier im Forum recht aktiv und neben dem Spruch hat er sich sicher auch Gedanken über eine Lösung gemacht und Du kannst gewiss sein, dass er ganz genau weiß was mit Einfrieren gemeint ist.
Hier im Forum wird schon mal Klartext geredet und nicht zimperlich umgegangen oder ein lockerer Spruch gemacht. Man muss hier einfach locker bleiben, nicht alles zu Ernst nehmen und sich nicht gleich angegriffen fühlen.
 
Dumm war der Witz nicht, denn er ging auf Deine Formulierung ein und ich fand ihn passend und zum Schmunzeln.
Ja, der Kommentar hat Dich zugegebenermaßen nicht weitergebracht, aber dieses Forum erhebt auch nicht den Anspruch bierernst zu sein.
@NBerger ist hier im Forum recht aktiv und neben dem Spruch hat er sich sicher auch Gedanken über eine Lösung gemacht und Du kannst gewiss sein, dass er ganz genau weiß was mit Einfrieren gemeint ist.
Hier im Forum wird schon mal Klartext geredet und nicht zimperlich umgegangen oder ein lockerer Spruch gemacht. Man muss hier einfach locker bleiben, nicht alles zu Ernst nehmen und sich nicht gleich angegriffen fühlen.

Wer austeilt muss auch einstecken. Davon abgesehen kritisiere ich keinen absichtlich für seine Sprachkenntnisse.
Ivh hoffe er nimmt es mir nciht zu böse 🫠
 
Zurück
Oben