TIA S7-1500 und/oder Open Controller. System Memory Bits funktionieren nicht.

[JesperMP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Bei mein S7-1515SP Open Controller erfahre ich das die sogenannte "System Memory Bits" nicht funktionieren, obwohl das sie aktiviert sind in den Konfiguration von der CPU.
Das sind die Bits für M1.0 First Scan, M1.2 Always True und M1.3 Always False.
Ich finde es gut das man nicht selber diese Bits bereistellen muss, und das ist ein Standard. Aber Sie funktionieren nicht !

Hat jemand diese Erfahrung bei der Open Controller ?
Hat jemand diese Erfahrung bei ein "standard" S7-1500 ?

 

[RONIN]

Hmmm, in den Standard-CPUs 1200/1500 funktionieren die eigentlich.

"Funktionieren nicht" heißt z.B. dass dein M1.2 nicht True ist?

 

[ducati]

Zuviel Werbung?
-> Hier kostenlos registrieren

oha... wieder so ne Geschichte, die ich eigentlich nicht glauben kann. Würde mich aber mittlerweile nicht mehr wundern, wenn sie trotzdem wahr wäre...

Hab leider keine Soft-SPS ums mal zu testen...

Gruß.

PS, vielleicht kann ichs morgen mal spasseshalber in PLCSIM v13 testen...

 

[Thomas_v2.1]

Ich würde mal versuchen die SPS zurückzusetzen und die HW-Konfig und Programm neu zu übertragen. Ich hatte bei der 1200 mal so ein Phänomen, dass bestimmte Einstellungen in der HW-Konfig nicht übertragen wurden. On-/Offline Vergleich hat keine Unterschiede gezeigt.

Wenn ich eine Aufzeichnung von der Programmübertragung sehen würde, könnte ich bei der 1200 zumindest sehen, ob die aktivierten Systemmerker in der HW-Konfig an die SPS übertragen werden. D.h. dann weiß man ob das TIA-Portal die Einstellung nicht überträgt, oder ob die SPS die Einstellung nicht übernimmt. Hilft einem aber auch nicht weiter, weil letztenendes Siemens es reparieren muss.

 

[ducati]

Ich hatte bei der 1200 mal so ein Phänomen, dass bestimmte Einstellungen in der HW-Konfig nicht übertragen wurden. On-/Offline Vergleich hat keine Unterschiede gezeigt.

Nicht Dein Ernst, oder???? Man, was haben die für einen Schrott entwickelt...

 

[rostiger Nagel]

Zuviel Werbung?
-> Hier kostenlos registrieren

Nicht Dein Ernst, oder???? Man, was haben die für einen Schrott entwickelt...

Ich kann das auch gerade nicht fassen!

 

[Blockmove]

Ich hatte bei der 1200 mal so ein Phänomen, dass bestimmte Einstellungen in der HW-Konfig nicht übertragen wurden. On-/Offline Vergleich hat keine Unterschiede gezeigt.

Kann ich bestätigen. Ich hab hier eine 1200 mit einem CP. Übertrage ich die Konfig über die Onboard-Schnittstelle ist alles gut. Übertrage ich die Konfig über den CP gibts Probleme.
Hab heute auf V14 hochgerüstet. Wenn da das Problemauch beteht, gibts nen Fehlerreport an Siemens.

 

[rostiger Nagel]

Kann ich bestätigen. Ich hab hier eine 1200 mit einem CP. Übertrage ich die Konfig über die Onboard-Schnittstelle ist alles gut. Übertrage ich die Konfig über den CP gibts Probleme.
Hab heute auf V14 hochgerüstet. Wenn da das Problemauch beteht, gibts nen Fehlerreport an Siemens.

Das könnte ja zu Jesper sein Problem passen, die Schnittstellen am IPC sind ja quasi ein CP.

 

[Stefan592]

Zuviel Werbung?
-> Hier kostenlos registrieren

Mein Gott. Jetzt kann man noch nicht mal mehr vernünftig seine Hardwarekonfig laden.

Wer hat sich bei Siemens eigentlich die Merker x.2 und x.3 für Always TRUE / FALSE ausgedacht. Ich kenne niemanden dem das einfallen würde.
Merker x.0 und x.1 für FALSE und TRUE waren für Siemens bestimmt zu Mainstream.
Ich stelle mir meine Systemmerker nach wie vor selber auf vernünftigen Adressen bereit!

 

[DeltaMikeAir]

Guten morgen zusammen,

ich hatte dieses Phänomen ebenfalls einmal. CPU1200 mit einem Beckhoff Buskoppler und daran ein paar Analogklemmen.
Die Steuerung lief bereits eine Woche und dann habe ich den EK9300 Buskoppler hinzugefügt. HW übertragen, Status der
Analogklemmen gestört. Nochmal versucht zu übertragen ( CPU meldet "HW wurde nicht übertragen, da aktuell ).
Eine Stunde lang probiert, dann CPU auf Werkseinstellungen zurück gesetzt, alles neu geladen, funktioniert sofort.

Schon sehr ärgerlich, war jetzt bei mir auf dem Schreibtisch aber wenn ich sowas abends in einer Anlage machen, muss das
auf Anhieb funktionieren.

Da sich in so kurzer Zeit doch mehrere gemeldet haben, scheint das Problem ja nicht so selten zu sein.

 

[ducati]

Wenn da das Problemauch beteht, gibts nen Fehlerreport an Siemens.

Das hat ja nun nix mit v14 zu tun. Wenn der Bug besteht, MUSS er auch für v13 behoben werden! Aber Siemens findet sicherlich eh wieder nen Grund, warum dieses Systemverhalten so gewollt ist, und dokumentiert es dann in v14 SP1 nach :sm11:F

 

[JesperMP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ein bisschen mehr Info zu das Problem:



Man kann AlwaysTrue M1.2 manuell setzen oder rücksetzen.
Ausgangswert ist FALSE.

Ich habe nicht probiert den CPU auf Werkseinstellung zu rücksetzen und der HW Konfiguration wieder einspielen. Das dauert bei der Open Controller sehr lange, und es ist mir egal wenn das Problem damit behoben wird oder nicht.
Das Punkt ist das der Funktionalität nicht vertrauenswert ist.
Deswegen setze ich AlwaysTrue ind rücksetze AlwaysFalse selber. Und 1stScan generiere ich von jetzt ab auch selber.

Und ja, warum hat Siemens nicht x.0 für FALSE und x.1 für TRUE gewählt ??

 

[Zombie]

Das is ja mal ein dicker Fisch. Hast du dein Projekt mal durchsucht ob du die Merker auch wirklich nicht neu zuweist?
Ich habs mal geschafft mittels VKE1 und VKE0 totgelegte IO Variablen an einem FB aus dem FB heraus zurückzusetzen.
Das war mir auch länger nicht aufgefallen weil es im vorletzten Bausteinaufruf des OB1 und nur selten passierte und ich VKE1 im letzten Baustein nur in einem ganz speziellen Fall nochmal brauchte.
Dieser eine Fall sorgte dann aber jedes mal für Probleme.

Ich bin aber gerade froh dass ich die Funktion in TIA Portal noch gar nicht kannte, deshalb hab ich mir da aus Classic bekannte Netzwerk für VKE1 und VKE0 auch in TIA im OB1 eingebaut.
Damit sollte das ja behoben sein, oder könnte das daran liegen, dass die CPUs Probleme haben einmal gesetzte Merker über den Zyklus auf ein und demselben Wert zu behalten?
Dann wäre das doch eine Fehlfunktion in der wirklich Grundlegendsten Funktion einer SPS?

 

[JesperMP]

Hast du dein Projekt mal durchsucht ob du die Merker auch wirklich nicht neu zuweist?

Ja habe ich.
Und wenn man AlwaysTRUE auf versehen FALSE gesetzt habe, sollte dann nicht der CPU es wieder auf TRUE setzen ?

 

[Zombie]

Zuviel Werbung?
-> Hier kostenlos registrieren

Eigentlich schon, oder zumindest denke ich dass es so funktioniert. Einmalig zum OB1 Start wird das neu zugewiesen. Aber ich habe gestern schon festgestellt, dass auch wenn ich einem Wert im DB über Beaobachten einen neuen Wert zuweise, der selbe Wert wenn er dann im Programm aufgerufen wird, seinen vorherigen Wert behält. Erst nach Ändern des Wertes im DB und erneutem Laden des DB hat der Baustein den neuen Wert bekommen.
Die Variable war die Variable HW-Kennung für den Baustein "DeviceState". Ich dachte, dass alle DB Werte zur Laufzeit geändert werden können, aber anscheinend nicht alle.

 

[JesperMP]

Eigentlich schon, oder zumindest denke ich dass es so funktioniert. Einmalig zum OB1 Start wird das neu zugewiesen.

Nein. Wenn AlwaysTRUE von mein Program nicht gesetzt wird, startet es als FALSE.
Auch bei Neustart.
Es funktioniert einfach nicht.