TIA Rätselhafte P_Trig Geisterflanken!?

Zuviel Werbung?
-> Hier kostenlos registrieren
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

Genau. Wobei ich meine ich dahinter eine Abzweigung gemacht habe, sollte am Ergebnis aber nichts ändern.
Das Raunen im Büro war gestern Nachmittag echt krass. Es fielen Siemens feindliche Aussagen, die ich hier schon gar nicht mehr wiederholen möchte.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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.



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


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.




Hallo l4

könntest du evtl noch deine Tia Version und die Firmware der CPU hier nennen nicht das Siemens mal wieder Sytemverhalten ändert!


Gruß Tia
 
Bedeutet das, dass
- Rockwell-Code mit irgendeinem Tool in Siemens-Code übersetzt wurde?
- dieses Tool bei früheren Übersetzungen funktionsfähigen Siemens-Code geliefert hat und jetzt nicht mehr?

Soviel ich weiss, sind das händische Übersetzungen. Ein Tool wäre cool.
Die Übersetzungen funktionieren gut aber es ist nach wie vor ein bisschen Nacharbeit notwendig.
Was aber nichts daran ändert, dass Siemens bei dem Problem:
1. Ein Kompilat zulässt, obwohl der Baustein P_TRIG das so nicht kann bzw. Bullshit macht.
2. Siemens an der Stelle weniger kann als Rockwell.
Wie gesagt, hier ist Rockwell der Master. Die Programme werden in Rockwell geschrieben, getestet und anschließend übersetzt.
 
Hallo l4

könntest du evtl noch deine Tia Version und die Firmware der CPU hier nennen nicht das Siemens mal wieder Sytemverhalten ändert!

Gruß Tia

TIA V15, CPU 1515F-2PN, FW V2.1.

Ihr seid gerne dazu eingeladen, dass bei euren CPUs auch zu testen. Ein paar Merker und ein FC. Der Test ist in wenigen Minuten durch.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich hab grad keine CPU zur Hand habs aber mal mit PLCSIM getestet.

TIA V15, CPU 1515-2 PN V2.5 -> Verhalten wie hier beschrieben, Ausgang des P_TRIG ist standardmäßig auf TRUE

TIA V15.1, CPU 1515-2 PN V2.6 -> Ausgang des P_TRIG ist FALSE
 
Ich hab grad keine CPU zur Hand habs aber mal mit PLCSIM getestet.

TIA V15, CPU 1515-2 PN V2.5 -> Verhalten wie hier beschrieben, Ausgang des P_TRIG ist standardmäßig auf TRUE

TIA V15.1, CPU 1515-2 PN V2.6 -> Ausgang des P_TRIG ist FALSE

Sehr hilfreiche Antwort. Danke.

Edit: Es wäre Interessant zu wissen, ob das die F CPU auch noch betrifft sowie Random andere CPUs der 1500er oder 1200er Reihe.
Hab leider keine hier und kein PLC Sim.
 
Zuletzt bearbeitet:
Zuletzt bearbeitet:
Was aber nichts daran ändert, dass Siemens bei dem Problem:
1. Ein Kompilat zulässt, obwohl der Baustein P_TRIG das so nicht kann bzw. Bullshit macht.
2. Siemens an der Stelle weniger kann als Rockwell.
Na ja, das V15-Verhalten dürfte von Siemens so nicht geplant gewesen sein und sie haben die Macke in V15.1 behoben.
Ob nun Siemens mehr kann oder Rockwell . . . es wird ja wohl niemand erwarten, dass Siemens in allen Feinheiten alles beherrscht, was Rockwell kann bzw. umgekehrt. Ist bestimmt auch besser so, sonst müssten auch die Macken von Siemens nach Rockwell übernommen werden bzw. umgekehrt.
 
Komisch (typisch?), Siemens erwähnt nirgends daß in TIA V15.1 dieser Fehler bei der Verwendung des P_TRIG beseitigt wurde, oder daß dieser Fehler jemals bestand ... ;)

Hallo,

ich habe heute Nachmittag auch als erstes in dem Siemens PDF, wo die geänderten Systemverhalten dokumentiert sind, nachgeschaut
ob irgendwas mit P_TRIG drin steht. Konnte nichts finden

Hier findet man den Link zu dem Siemens dokument.
https://support.industry.siemens.com/cs/mdm/109755202?c=117664210187&lc=de-WW

TIA V15.1 Kompatibilität von PLC-Programmen aus früheren Versionen

Probleme totschweigen. Eine populäre Lösung.

Na ja, das V15-Verhalten dürfte von Siemens so nicht geplant gewesen sein und sie haben die Macke in V15.1 behoben.
Ob nun Siemens mehr kann oder Rockwell . . . es wird ja wohl niemand erwarten, dass Siemens in allen Feinheiten alles beherrscht, was Rockwell kann bzw. umgekehrt. Ist bestimmt auch besser so, sonst müssten auch die Macken von Siemens nach Rockwell übernommen werden bzw. umgekehrt.

Wir reden hier über eine uralte Grundfunktion, die einfach funktionieren muss. Nicht über irgendeine Neuentwicklung.
Was ich noch nicht getestet habe, und wahrscheinlich auch nicht mehr werde, ist, wie das in TIA V14 aussieht.

Aber trotzdem müssen die so einen Bug dokumentieren.
Oder die haben es garnicht gemerkt... :confused:

Bei ersterem stimme ich zu, bei letzterem muss ich einfach sagen, dass das ganze ein schlechtes Bild auf Siemens wirft, wenn dem der Fall ist.

#######
Ich habe in vergleichbar kurzen Zeit schon sehr viel Gemecker über Siemens gehört an verschiedenen Orten.
Da Siemens in meinem Aufgabenbereich liegt, versuche ich das zu ignorieren und das positive zu sehen.
Was momentan etwas schwer fällt.
 
Denk immer daran :
It's not a Bug - it's a Feature ...

Gemeckert wird immer ... aber das, was Siemens da mit TIA angestellt hat ist schon "ein dicker Hund".
Ich fürchte du wirst im Laufe der Zeit noch das eine oder andere Feature entdecken.

Gruß
Larry
 
Zuviel Werbung?
-> Hier kostenlos registrieren
im Laufe der Zeit noch das eine oder andere Feature entdecken.
Wenn man bei jeder neuen Version so innovativ ist, dann kann schon mal das eine oder andere ungewollte Feature mit durchschlüpfen. ;) Allerdings ist dann die Chance groß, dass über dieses Feature hier im SPS-Forum.de geschrieben wird, weil:
Lieferfreigabe SIMATIC STEP 7 Professional / Basic V15.1
SIMATIC STEP 7 ist weltweit die bekannteste und meist genutzte Programmiersoftware in der Industrieautomatisierung. SIMATIC STEP 7 (TIA Portal) überzeugt durch innovaties Engineering für bewährte und neue SIMATIC Controller.
Qualitätswesen und Geschriebenes nochmal durchlesen scheint bei Siemens ein einsparbarer Kostenfaktor zu sein, die kriegen ja noch nicht mal ein paar Zeilen Werbe-Blabla fehlerfrei hin ... :ROFLMAO:

Harald
 
Wenn man bei jeder neuen Version so innovativ ist, dann kann schon mal das eine oder andere ungewollte Feature mit durchschlüpfen. ;) Allerdings ist dann die Chance groß, dass über dieses Feature hier im SPS-Forum.de geschrieben wird, weil:
Lieferfreigabe SIMATIC STEP 7 Professional / Basic V15.1

Qualitätswesen und Geschriebenes nochmal durchlesen scheint bei Siemens ein einsparbarer Kostenfaktor zu sein, die kriegen ja noch nicht mal ein paar Zeilen Werbe-Blabla fehlerfrei hin ... :ROFLMAO:

Harald

Wobei böse Zugen behaupten, TIA wäre ja kein neues Programm, sondern Step7 mit neuer Oberfläche.
Ich würde mir echt wünschen, die wären bei Daten etwas sparsamer, sei es Festplatten oder Arbeitsspreicher.
Und wo wir gerade beim Meckern sind. Ich muss aktuell auf Kundenwunsch ein bestehendes Programm mit SPS Softwarebausteinen von Siemens verunstalten.
Leider hat die Doku zu diesen Bausteinen mindestens genausoviele Fehler wie Seiten. Und das sind 293 Seiten.

So genug gemeckert.
 
Wobei böse Zugen behaupten, TIA wäre ja kein neues Programm, sondern Step7 mit neuer Oberfläche.

Wenn dem so wäre dann gäbe es vermutlich SEHR viel weniger Probleme.
Es wäre jedoch besser gewesen, so vorzugehen - also erst das Frontend neu und danach die Logik dahinter (oder umgekehrt) ...

Gruß
Larry
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Es wäre jedoch besser gewesen, so vorzugehen - also erst das Frontend neu und danach die Logik dahinter (oder umgekehrt) ...

Naja, mal neu anzufangen ist ja im Prinzip schon richtig gewesen, die Zeiten ändern sich einfach und der Markt verlangt einfach viele neue Funktionen.
Die S7-300/400 Integration hätte man sich meiner Meinung nach sparen können, aber neue Steuerungen mit ganz neuen Funktionen in Step7 reinzufummeln
ist ja auch nicht das gelbe vom Ei. Irgendwann muss man eben einen Schnitt ziehen, ansonsten würden wir heute mit einem TIA Protal arbeiten, welches auf dem PG685-Step5 aufgebaut ist.
 
... ich hatte jetzt hier nur ein Beispiel genannt, wie andere Firmen, die Anwendungssoftware erstellen, das so handhaben. Macht man das so (also in mehreren Steps) dann erspart man sich viele Fehler in der SW und man verliert die Benutzer-Akzeptanz nicht so schnell - ist jetzt nicht meine Erfahrung sondern die eines SW-Herstellers, der so etwas schon länger (erfolgreich) so macht ...

´... aber wir schweifen hier jetzt vom eigentlichen Thema ab - das gehört jetzt eigentlich eher in der großen TIA-Topf ...

Gruß
Larry
 
Mir ist bei erneuert Überlegung eingefallen, dass wir das Thema noch nicht ganz eindeutig geklärt haben.
Man wies mich nämlich darauf hin, dass wir einige 1515F-2PN mit Firmwares <V2.5 im Feld haben.

Ich wollte dazu also noch abklären, ob das Problem mit FW <= V2.5 und TIA V15.1 immer noch auftritt.
Also habe ich unsere Test SPS mit der original FW V2.1 bespielt und nochmals mit V15.1 das Programm geladen - läuft wie es soll.

Dem zufolge ist das TIA Portal 15 Schuld an dem Problem und die FW nicht von Bedeutung.

Die Frage die mich jetzt noch beschäftigt:
Macht das TIA Portal V15 nur mit dieser SPS diesen Fehler oder sind das alle SPSen?
Gerade ging ein Projekt mit einer CPU 1511F-1 PN raus, welches meine Eigenproduktion ist und auch so ein Problemnetzwerk hat.
Projektiert natürlich mit V15 und FW V2.5. Kann das mal jemand mit PLCSIM testen?




 
Zurück
Oben