Phänomen bei Speed7

Ralle

Super-Moderator , User des Jahres 2006-2007
Teammitglied
Beiträge
15.414
Reaktionspunkte
4.043
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich hab ein eigenartiges Phänomen bei einer Speed7.
Ich habe eigene Standard-FC z.Bsp. für Ventile. Funktionieren in allen CPU seit Jahren problemlos, auch in der Speed7. Allerdings passiert es, daß ein Baustein auf seinen Inputs fest ein paar Bits gesetzt hat (Bits kommen aus einem DB, z,Bsp. DB144.DBX100.4), obwohl diese Bits ein paar NW vorher zurückgesetzt werden.
Wenn ich jetzt ein CLR genau vor den Bausteinaufruf schreibe, ist alles wieder ok.
Der Baustein ist nicht kompliziert, nur Bitverknüpfungen, BIE und Save, alles drin, an Anfang und Ende. Der erste Befehl im Baustein ist eine Erstabfrage, also auch normal, der letzte Befehl eine Zuweisung an einen Output.

Hat irgend jemand so etwas schon einmal gesehen, oder eine Vermutung zur Ursache? Mit dem CLR vor dem Baustein geht es ja (von ca. 40 Bausteinaufrufen hab ich das bei 2 Aufrufen mchen müssen), aber irgendwie stört mich das. Auch den Lokalstack der CPU hab ich erhöht, der läuft sicher nicht über. Keine Temp-Var am FC genutzt, im FC alles ordentlich initialisiert und zugewiesen, das hab ich nochmal kontrolliert, auch hier hängt nicht in der Luft.

Werd wohl doch mal bei VIPA anrufen müssen!
 
Hallo

1. Wird die Zuweisung ein paar Netzwerke vorher immer ausgeführt oder kann sie programmtechnisch übersprungen werden?
2. Was wird in den dazwichenliegenden Netzwerken getan? Kann es sein, das ein aufgerufener Baustein die Werte aus einem Zwichenspeicher zurückschreibt?
3. Werden die Daten direkt vom aufgerufenen Baustein manipuliert? Hilft es, Zwichenmerker zu verwenden?
4. Kann(Darf) der Baustein von uns betrachtet werden?
5. Vipa ist schuld.
Grüße
FP
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo

1. Wird die Zuweisung ein paar Netzwerke vorher immer ausgeführt oder kann sie programmtechnisch übersprungen werden?
2. Was wird in den dazwichenliegenden Netzwerken getan? Kann es sein, das ein aufgerufener Baustein die Werte aus einem Zwichenspeicher zurückschreibt?
3. Werden die Daten direkt vom aufgerufenen Baustein manipuliert? Hilft es, Zwichenmerker zu verwenden?
4. Kann(Darf) der Baustein von uns betrachtet werden?
5. Vipa ist schuld.
Grüße
FP

1. Nein, nicht übersprungen.
2. Nichts "Besonderes", normale Logik.
3. Es betrifft ja u.a. Inputs, die werden im aufgerufenen Baustein nicht geschrieben.
4. nicht unbedingt, darf ich nicht so einfach
5. kann ich mir auch nicht so richtig vorstellen, aber ich rede trotzdem mal mit VIPA, vielleicht haben die ja einen Tip. Ich komm nächste Woche an eine 317 ran, vielleicht kann ich das da mal testen, aber da fehlt halt der ganze Profibus uns die Anlage dahinter, da kann man auch schlecht Aussagen machen.
 
Guten Morgen,
- wie werden denn die Bits ein par Netzwerke vorher zurückgesetzt?
Auch mit CLR? Oder mit einem "selbstgebasteltem" Signal?
Wenn letzteres der Fall sein sollte, kann man dieses Signal nocheinmal überprüfen.
- Was geschieht, wenn die Bits immer ein Netzwerk eher bis zum ursprünglichen Rücksetznetzwerk mit CLR abgelöscht werden? Damit müsste zu ermitteln sein, in welchem Netzwerk die Ursache liegt.
- Werden die Bits azyklich in Alarm/Zeit - Bausteinen bearbeitet, so das dies dazwichenhakt?
Güße
FP
 
Hallo Ralle,

ruf doch bitte mal bei uns an, dann können wir die Problematik diskutieren.

vipaner_112
Tel.: 09132 / 744-100

oder Support
Tel.: 09132 / 744-114


mfG. vipaner_112
 
Schreibt dir die HMI in die Variable?!? Hatte ich auch schon mal. Wenn du HMI-seitig nicht symbolisch arbeitest kann das schon vorkommen. Hatte ich auch schon mal.

VIPA-Cpu's haben auch ihre Eigenheiten...
CP on board - ein Drama...
Routing - ein Drama...
Bestimmete PEW's und PAW's - ein Drama...

Geschwindigkeit und Speicher - dramatisch gut... :)
 
Schreibt dir die HMI in die Variable?!? Hatte ich auch schon mal. Wenn du HMI-seitig nicht symbolisch arbeitest kann das schon vorkommen. Hatte ich auch schon mal.

VIPA-Cpu's haben auch ihre Eigenheiten...
CP on board - ein Drama...
Routing - ein Drama...
Bestimmete PEW's und PAW's - ein Drama...

Geschwindigkeit und Speicher - dramatisch gut... :)

Von der HMI kommt auf der Spur nichts.

PS: Das ganze soll ja auch kein Meckerthread von mir :)-D) sein, ich will die Sache nur mal abklären, da wir die Speed7 oft einsetzen. Wie es scheint ist ja nur die Anzeige des Status Online falsch. Die Funktion des Bausteins scheint zu stimmen, aber das überprüfe ich noch einmal an der Maschine, sobald ich dazu Zeit habe. Man kommt halt drauf, weil ein Ventil nicht schaltet und stolpert erstmal über die falsche Anzeige. Später dann, nachdem es endlich läuft zu sagen, es war das Programm, die Anzeige oder etwas Anderes ist schwierig.


PS2: 100% Ack zu deiner Signatur :ROFLMAO:!
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Leider hat die Hotline von VIPA meine Nebenbemerkung "Es brennt nicht" so ernst genommen, daß nach einer Woche noch nichts Neues zu melden ist. Ich werde mich morgen nochmal bemerkbar machen. Oder bekommen wir gleich ne neue Firmware? ;)
 
So, aufgrund meines Postings hier hat sich jemand von VIPA nochmal bei mir gemeldet und ich habe ihm den betreffenden Code zugeschickt. Man konnte den Fehler nachvollziehen, es betrifft nur die Statusanzeige, nicht die Programmlogik als solche (Gott sei Dank). Das Problem wird analysiert und behoben, also in einem der nächstmöglichen FW-Updates behoben sein.

Workarround bis dahin, falls jemand beim Status beobachten ein Problem hat, ein NOP oder CLR direkt vor den Baustein.

Vielen Dank auch nochmal an Vipaner_112 und seine wirklich bemühten Kollegen :-D.
 
Hallo,

ich hatte gestern ein ähnliches Verhalten beim Einlesen von PEWs. Es wird im Status (FUP) am FC105 (Normierung Analogwerte) Null angezeigt, obwohl der korrekte Wert rein kommt. Hab dann eine VAT benutzt, zum beobachten.

Vielleicht sollte ich auch noch Nachricht an Vipa geben, damit das auch korrigiert werden kann.

Gruss

___________________________________________
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo,

ich hatte gestern ein ähnliches Verhalten beim Einlesen von PEWs. Es wird im Status (FUP) am FC105 (Normierung Analogwerte) Null angezeigt, obwohl der korrekte Wert rein kommt. Hab dann eine VAT benutzt, zum beobachten.

Vielleicht sollte ich auch noch Nachricht an Vipa geben, damit das auch korrigiert werden kann.

Gruss

___________________________________________

Der Kollege von VIPA liest mit :rolleyes:.
Kannst du das mal mit dem NOP testen oder bist du nicht mehr vor Ort?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Das sollte Siemens auch dringendst mal machen und sich so wie VIPA bemerkbar machen!

godi

Ich glaube die haben Angst damit das Forum hier zu sprengen
icon10.gif
!!
 
Zuviel Werbung?
-> Hier kostenlos registrieren
weil dann viele unberechtiger Weise direkt bei den entsprechenden Mitlesenden den ganzen Frust ablassen würde der so in unzählichen unterschiedlichen Posts abgelassen wird

oder weil Leute auf die Idee kommen würden sich direkt an die Leute zu wenden und sie den ganzen Tag zu "spammen" würden


usw.......
 
weil dann viele unberechtiger Weise direkt bei den entsprechenden Mitlesenden den ganzen Frust ablassen würde der so in unzählichen unterschiedlichen Posts abgelassen wird

oder weil Leute auf die Idee kommen würden sich direkt an die Leute zu wenden und sie den ganzen Tag zu "spammen" würden


usw.......

OK ist ein guter Grund!
Im Prinzip is ma ja eh wurscht weil ich sie (bis jetzt) nicht brauchte und wenn ich was wissen will dann frage ich eh hier im Forum in ihr habt mir immer gut weitergeholfen! :-D

godi
 
Zurück
Oben