TIA Rätselhafte P_Trig Geisterflanken!?

L

L4s3r73k

Level-2
Beiträge
125
Reaktionspunkte
30
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo und guten Morgen zusammen.

Aus aktuellem Anlass möchte ich um Rat bei einem bestimmten Problem fragen.
Der Kollege ist gerade in den USA bei einer Inbetriebnahme unserer Maschinen.
Ihm spuckt gerade der P_Trig in die Suppe.

Zwischenablage02.png

Wie auf der Abbildung zu sehen, besitzt die Maschine eine sog. "BehindStation" und keine "FrontStation".
Die beiden genannten Bits werden von extern geschrieben.
Der P_Trig an dieser Stelle dürfte also niemals True sein.
"MainProgramData" ist ein globaler DB indem alle Daten zusammen laufen - unsere Interpretation von einer Rockwell zu Siemens Übersetzung.
Auch die Einzelbitadressierung mit z.B. ".%X0" ist darin geschuldet, dass es in der Rockwell Welt wohl komfortabler ist damit zu arbeiten (so meine Rockweller Kollegen).
Durch die Übersetzung haben die "ONS" (Oneshots) DInts unverständlicherweise den Initialwert dezimal 50.
Auch das erklärt nicht (ganz) das Phänomen des
"MainProgramData"."100_ONS".%X0 = True,
da das Bit bei dem Wert 50 false ist.
Die Bits des "ONS" DInt's werden ausschließlich von P_Trig's verwendet.

Hat vielleicht jemand ähnliche Erfahrungen gemacht oder sind Probleme mit dem Trigger bekannt?

Grüße

Dennis
 
Zuletzt bearbeitet:
Moin,
du könntest ja mal alle der Variablen in ein Trace packen und schauen ob du dabei herausfindest, ob die Variablen am CLK vom P_Trig doch mal wackeln.
Und dann würde ich nochmal schauen ob im Netzwerk davor eine Zuweisung fehlt.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Howard schrieb:
Moin,
du könntest ja mal alle der Variablen in ein Trace packen und schauen ob du dabei herausfindest, ob die Variablen am CLK vom P_Trig doch mal wackeln.
Zum Vergrößern anklicken....

Das Problem wurde vom Kollegen auf der Baustelle schon getraced, er konnte aber kein fehlerhaftes Bitverhalten der vier Bits beobachten. Deswegen sprach er auch von Geisterflanken.
Geschuldet der Uhrzeit ist er erst in frühestens 6h wieder an der Arbeit.

Howard schrieb:
Und dann würde ich nochmal schauen ob im Netzwerk davor eine Zuweisung fehlt.
Zum Vergrößern anklicken....
Ich verstehe diesen Ratschlag gerade nicht.

@all
Ich vergaß zu erwähnen, dass ich dem Kollegen bereits eine Mail geschickt habe, mit der Bitte die total sinnlosen Startwerte aus dem Global DB zu löschen.
Das erklärt zwar auf ersten Blick nicht das Problem, könnte aber womöglich zur Lösung desselben beitragen oder führen.
 
L4s3r73k schrieb:
Ich verstehe diesen Ratschlag gerade nicht.
Zum Vergrößern anklicken....
Wenn das Netzwerk davor bspw. in AWL geschrieben ist und keine Zuweisung (S/R/= usw.) enthält (weil vielleicht zum testen auskommentiert), dann wandert das VKE mit ins nächste Netzwerk und kann dann zu Problemen führen. Und dein P_Trig ist ja eine VKE-Flanke, keine "normale" Flanke. Deshalb hätte ich intuitiv mal ins vorherige Netzwerk geschaut.

@Delta: *ACK* an genau den Post habe ich gedacht
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
DeltaMikeAir schrieb:
Damit meint Howard so etwas:
( schau dir einmal das Bild in diesem Post an )
https://www.sps-forum.de/simatic/94...verarbeitungsfehler-der-sps-2.html#post709512
Zum Vergrößern anklicken....

Ich verstehe immer noch nicht, was damit genau gemeint ist. Vielleicht stehe ich ja auf dem Schlauch.
Die beiden Bits zur Maschinenkonfig haben bei dieser Version der Anlage niemals die Konstellation, dass das VKE dahinter true (sprich beide Bits false) ist.
Ebenfalls kann das Bit danach keine 1 generieren, niemals. Nur das vierte Bit in der Verkettung kann 1 werden.
Hinter dem P_Trig sind, nicht auf dem Screenshot zu sehen, zwei Move Anweisungen. Das war's.

Oder geht es dir um fehlerhafte Darstellung der Bits? Oder muss dem P_Trig eine Boolsche bitzuweisung folgen, dass er vernünftig funktioniert?

Tante Edith meint:
Zwischen dem Q des P_Trig und den beiden MOVE Blöcken ist noch ein Vergleich (<>), aber keine Bitzuweisung (S,R,--() oder --(/)).
 
Zuletzt bearbeitet:
Howard schrieb:
Wenn das Netzwerk davor bspw. in AWL geschrieben ist und keine Zuweisung (S/R/= usw.) enthält (weil vielleicht zum testen auskommentiert), dann wandert das VKE mit ins nächste Netzwerk und kann dann zu Problemen führen. Und dein P_Trig ist ja eine VKE-Flanke, keine "normale" Flanke. Deshalb hätte ich intuitiv mal ins vorherige Netzwerk geschaut.
Zum Vergrößern anklicken....

Bei uns sind 99,8% in KOP geschrieben. Somit ist das Netzwerk davor eine Verundung mit --() am Ende.
Warum sollte das VKE im nächsten Netzwerk denn noch eine Rolle spielen? Was wäre denn eine "normale" Flanke? Nur ein Operand am Eingang?
 
Ich verstehe immer noch nicht
Zum Vergrößern anklicken....

Es ist so, wenn in dem Netzwerk über deinem Netzwerk keine VKE Zuweisung existiert ( also z.b. = M10.0 ), dann passieren auf recht wundersame Dinge

Schau dir mal dieses Bild an:
vke.png
Im unteren Netzwerk ist eine UND Box, beide Variablen sind TRUE aber sie schaltet nicht durch.
Ursache ist das Netzwerk darüber, wo nur "U M100.0" steht aber keine Zuweisung. Somit fällt
dieses U M 100.0 mit in die UND Box aus Netzwerk 2.
 
Ich habe nochmal ein Screenshot gemacht mit den Netzwerken davor und dahinter.
Zwischenablage03.jpg

Vielleicht machen wir ja einen trivialen Fehler, was man bei Siemens einfach nicht machen "darf".
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ein P_TRIG kann eigentlich niemals den Ausgang TRUE haben wenn der Eingang FALSE ist, selbst wenn das Speicherbit irgendwie manipuliert wird.

Könnt Ihr für das P_TRIG-Speicherbit mal eine normale BOOL-Variable verwenden anstatt dieser Slice-Sparvariante? (Es sollte doch nicht schwer sein, diese Slice-Verwendungen auf "Array[0..31] of Bool" umzuschreiben.)
Wird "MainProgramData"."100_ONS" noch an anderen Programmstellen (als Ganzes) beschrieben, oder irgendeins der Slice-Bits in einem Alarm-OB verwendet?
Wird das selbe Bit "MainProgramData"."100_ONS".%X0 noch woanders verwendet?
Ist der "MainProgramData"-DB "optimiert" oder mit Standard-Zugriff? Gibt es evtl. fehlerhaft funktionierende indirekte Adressierungen im Programm?
Wie lange ist das P_TRIG TRUE, so daß Ihr einen Screenshot davon machen konntet?

Welche TIA-Version verwendet Ihr?
Welche CPU mit welcher Firmware?

Wurde das Programm schon mal "Software komplett" übersetzt?

Harald
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Larry Laffer schrieb:
Dann wird es wohl nicht an den Vorgänger-Netzwerken liegen.
Aber andere Frage :
Woher kommen denn die Bits / Werte ? Ggf. von einer anderen Steuerung ?
Zum Vergrößern anklicken....

Die Bits zur Maschinenkonfiguration kommen von einem Industrie PC wo eine von uns geschriebene Visu drauf läuft.
Seit Ewigkeiten schreiben wir so Werte runter in die SPS.

PN/DP schrieb:
Ein P_TRIG kann eigentlich niemals den Ausgang TRUE haben wenn der Eingang FALSE ist, selbst wenn das Speicherbit irgendwie manipuliert wird.

Könnt Ihr für das P_TRIG-Speicherbit mal eine normale BOOL-Variable verwenden anstatt dieser Slice-Sparvariante? (Es sollte doch nicht schwer sein, diese Slice-Verwendungen auf "Array[0..31] of Bool" umzuschreiben.)
Wird "MainProgramData"."100_ONS" noch an anderen Programmstellen (als Ganzes) beschrieben, oder irgendeins der Slice-Bits in einem Alarm-OB verwendet?
Wird das selbe Bit "MainProgramData"."100_ONS".%X0 noch woanders verwendet?
Ist der "MainProgramData"-DB "optimiert" oder mit Standard-Zugriff? Gibt es evtl. fehlerhaft funktionierende indirekte Adressierungen im Programm?
Wie lange ist das P_TRIG TRUE, so daß Ihr einen Screenshot davon machen konntet?

Welche TIA-Version verwendet Ihr?
Welche CPU mit welcher Firmware?

Wurde das Programm schon mal "Software komplett" übersetzt?
Zum Vergrößern anklicken....

Die Slice-Sparvariante kommt halt eben aus der Rockwell Welt.
Da kann man wohl beim Programmen live sehen, welches der Bits schon verwendet wird.
Bei uns in der Firma ist Rockwell der Master und Siemens soll ein Klon davon sein. Für eine Array Umstellung fehlt gerade die Erlaubnis.
100_ONS wird nur in diesem FC verwendet und das Bit ist einmalig belegt.
Der "MainProgramData" DB ist optimiert.
TIA V15, 1515F-2PN.
Der Kollege ist sehr fähig, komplett übersetzen hat er bestimmt schon gemacht. Aufgrund der Zeitverschiebung wird er jetzt aber wahrscheinlich gleich erst aufstehen.
Wie gesagt, weil Rockwell hier die erste Geige spielt, hab ich mich als Siemens'ler als Slave zu verhalten.
 
Meine Frage hatte den Hintergrund, dass es möglicherweise daran liegen könnte, dass von der Visu die Bits / Bytes in der Datenübertragung gegenüber der von Siemens gewünschten Reihenfolge vertauscht werden.
Habt ihr diese Kommunikation vorher in eurem Haus getestet ?

Gruß
Larry
 
Zuviel Werbung?
-> Hier kostenlos registrieren
L4s3r73k schrieb:
Durch die Übersetzung haben die "ONS" (Oneshots) DInts unverständlicherweise den Initialwert dezimal 50.
Auch das erklärt nicht (ganz) das Phänomen des
"MainProgramData"."100_ONS".%X0 = True,
da das Bit bei dem Wert 50 false ist.
Die Bits des "ONS" DInt's werden ausschließlich von P_Trig's verwendet.
Zum Vergrößern anklicken....
Was meinst Du damit? DInt ist ein Doppelwort (32 Bit), in dem bis zu 32 Bit als FlankenMerker belegt sind?
Warum DINT? Wenn's DWORD wäre, würde statt dezimal 50 hexadezimal 0000 0032 angezeigt?
Was meinst mit InitialWert? Dass das DoppelWort mit dezimal 50 initialisiert wird und sich fortan nicht mehr ändert?
Ich muss Deiner Tante Edith Recht geben - mir will der Vergleich zwischen P_Trig und den MOVEs auch nicht einleuchten.
Was wird denn dort womit verglichen und wie wird das VergleichsErgebnis mit dem ImpulsMerker verknüpft? Sorry, wenn ich's total falsch deute, habe äusserst selten mit KOP gearbeitet und etwas derartiges noch nie gesehen. Wahrscheinlich ist das kein Vergleich. Bedeutet <> vielleicht, dass das Bit invertiert wird?

Gruss, Heinileini
 
Heinileini schrieb:
Was meinst Du damit? DInt ist ein Doppelwort (32 Bit), in dem bis zu 32 Bit als FlankenMerker belegt sind?
Warum DINT? Wenn's DWORD wäre, würde statt dezimal 50 hexadezimal 0000 0032 angezeigt?
Was meinst mit InitialWert? Dass das DoppelWort mit dezimal 50 initialisiert wird und sich fortan nicht mehr ändert?
Ich muss Deiner Tante Edith Recht geben - mir will der Vergleich zwischen P_Trig und den MOVEs auch nicht einleuchten.
Was wird denn dort womit verglichen und wie wird das VergleichsErgebnis mit dem ImpulsMerker verknüpft? Sorry, wenn ich's total falsch deute, habe äusserst selten mit KOP gearbeitet und etwas derartiges noch nie gesehen. Wahrscheinlich ist das kein Vergleich. Bedeutet <> vielleicht, dass das Bit invertiert wird?
Zum Vergrößern anklicken....
Es werden gemäß Vorlage halt DInts verwendet um Arrays of Bool abzubilden, das ist halt so und das kann und darf ich zur Zeit nicht ändern.
Variablen in DBs können Initialwerte haben. Aus irgendeinem Grund hat die Übersetzung von Rockwell zu Siemens da bei jedem DInt den Wert 50 stehen.
Die Logik hinter der Programmpassage ist folgende:
Wenn die Flanke ansteht, dann soll damit in dem Zyklus zweimal Daten kopiert/verschoben werden durch die MOVE Blöcke, was jedoch durch einen Vergleich abgefangen werden soll.
Rockwell kann das so, Siemens scheinbar nicht, siehe weiter Unten.

Larry Laffer schrieb:
Meine Frage hatte den Hintergrund, dass es möglicherweise daran liegen könnte, dass von der Visu die Bits / Bytes in der Datenübertragung gegenüber der von Siemens gewünschten Reihenfolge vertauscht werden.
Habt ihr diese Kommunikation vorher in eurem Haus getestet ?
Zum Vergrößern anklicken....

Die Visu hat mit diesen P_Trig Bits gar nichts zu tun. Das läuft schon seit Jahren so, ohne Probleme.
Der Problemstellen bzw. der Problem FC ist seit der neuesten Übersetzung halt eben drin in der Form und ein Problem.
Lösung kommt im folgenden.


#########################################################################
Lösung bzw. Problem gefunden:

Siemens ist anscheinend immer noch nicht fähig, problematische Programmierungen beim Kompilieren mit einem Fehler zu verweigern.
Ähnlich wie bei dem weiter oben genannten Beispiel mit dem AWL Code wo das U M100.0 in das UND weiter unten rutscht.

Siemens schreibt
In KOP darf die Anweisung P_TRIG nicht am Anfang oder Ende eines
Netzwerks angeordnet werden.
Zum Vergrößern anklicken....

Dem sollten Sie hinzufügen, dass dem P_Trig unbedingt eine Einzelbitzuweisung (Boolsche Zuweisung : ---(R), ---(S), ---(/) oder ---( )) folgen muss.
Ich habe das Problemnetzwerk am Arbeitsplatz mit einer kurzfristig organisierten 1515F-2PN SPS nachgestellt.
Wenn dieser Konstellation keine Bitzuweisung folgt, ist der Ausgang des P_Trigs Standardmäßig = True.
Erst wenn man dahinter irgendeine der o.g. Zuweisungen macht, verhält er sich so, wie er soll.
Für Siemens sind demnach Größenvergleiche und MOVE nicht existent. :p

Ich hoffe, das hilft jemandem hier, wenn er in Zeit X mal über den Thread stolpert.
 
L4s3r73k schrieb:
Dem sollten Sie hinzufügen, dass dem P_Trig unbedingt eine Einzelbitzuweisung (Boolsche Zuweisung : ---(R), ---(S), ---(/) oder ---( )) folgen muss.
[...]
Wenn dieser Konstellation keine Bitzuweisung folgt, ist der Ausgang des P_Trigs Standardmäßig = True.
Erst wenn man dahinter irgendeine der o.g. Zuweisungen macht, verhält er sich so, wie er soll.
Zum Vergrößern anklicken....
Also mit dieser Zwischenspeicher-Erweiterung funktioniert es?
Code: 
                      +----------+                        +--------+
                      |  P_TRIG  |  [COLOR="#FF0000"]#tmp1[/COLOR]     | <> |      |  MOVE  |
---|/|------| |---+---|CLK      Q|-[COLOR="#FF0000"]--( )--[/COLOR]----|SInt|------|EN   ENO|- ...
                  |   +----------+                       -|IN  OUT1|-
                  |                                       +--------+
                 ...

Harald
 
Zurück
Oben