EA-Feld Konfiguration

[M0rti]

Zuviel Werbung?
-> Hier kostenlos registrieren

Das stimmt nicht, das kann bezüglich des C-Teils nicht völlig egal sein. Wie du in dem Screen siehst, wird ja die Variable geladen, aus der DB! Da ist es natürlich nicht egal welchen Wert die Variable hat, es macht schon einen unterschied ob ich eine Variable mit dem Wert x0 oder x1000 in den C-Tei lade!

Ja wie gesagt, für den Code bin ich nicht verantwortlich, der existiert schon seit Jahren

 

[RONIN]

Ich schließ mich noch mal Haralds Meinung an dass der Unterschied Inital/Aktualwerte nicht das Problem ist.
Harald hat oben ja schon erklärt dass das Bit welches du zum dynamisieren verwendest nicht in den gezeigten Skripten angefasst wird.

@Harald: Diese Skripte mit den dWordhelp hab ich auch schon ein paar mal gesehen. Ich glaub die entstehen wenn man Dynamik-Dialoge oder Direktverbindungen in C-Skript wandelt.
Die Setze/Rücksetze-Konstruktion wurde dann wahrscheinlich im selben Stil erweitert. Schön ist es nicht.

 

[M0rti]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo Ronin,

das Bit zum Dynamisieren habe ich nicht gesetzt!!! Das war schon so gesetzt, vor JAHREN. Daher ja die Verwirrung, ich kann natürlich hergehen und alles einzelnt per Hand umstellen, damit richtig getriggert wird, aber das macht wenig Sinn, vor allem weil es ja jahrelang funktioniert hat. Es wurde schon immer Bit8 geprüft, daran wurde nichts geändert

 

[MSB]

Das stimmt nicht, das kann bezüglich des C-Teils nicht völlig egal sein. Wie du in dem Screen siehst, wird ja die Variable geladen, aus der DB! Da ist es natürlich nicht egal welchen Wert die Variable hat, es macht schon einen unterschied ob ich eine Variable mit dem Wert x0 oder x1000 in den C-Tei lade!

Ja wie gesagt, für den Code bin ich nicht verantwortlich, der existiert schon seit Jahren

Diese C-Katastrophe beeinflusst genau 1 Bit des Words, welches sozusagen mit mask selektiert wird.
Ist dieses 1 Bit High wird es Low, ist es Low wird es High.
Vollkommen unspektakulär, da das Bit immer beeinflusst werden würde, völlig egal was im Rest vom Word steht.

 

[RONIN]

Es wurde schon immer Bit8 geprüft, daran wurde nichts geändert

Welche Aufgabe hat denn diese uminösen Bits 1,15,8?
Und zwar nicht in der Visu, sondern in der SPS?
Für irgendwas müssen die Bits innerhalb des Words ja gut sein.


Kann es nicht sein dass dieses Bit 8 von der SPS gesetzt werden muss um eine Dynamisierung zu erreichen.
Dass die Bits 1/15 die Steuerbefehle sind und Bit 8 eine Rückmeldung ist?

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wenn Du in dem WinCC nichts geändert hast - hast Du im SPS-Programm was geändert?
Nur vom Schalten des Ein/Aus-Buttons ändert sich die Hintergrundfarbe nicht. Das SPS-Programm muß irgendwie das Bit .1 vom 1/0-Button in das Bit .8 kopieren/verknüpfen, damit sich die Farbe des Ventils ändert.

Ziemlich sicher gibt es im SPS-Programm einen Baustein, der die Ventilansteuerung macht und wo die Ventil-Words aus DB9 drangehen.
Wie sieht der aus?
Wenn in dem Baustein was geändert wurde, dann wirkt es sich auf alle Ventile aus. Der Baustein sollte ja leicht zu finden sein - Du weißt ja wo Du was geändert hast bzw. siehe die Querverweise vom DB9.

Harald

 

[M0rti]

Also da würde ich gerne nochmal auf die bereits geposteten Bilder verweisen, auf Seite 2 oder so. Da ist auch zu sehen wo sich die Farbe ändern soll. Das passiert über diesen Teil hier (jetzt dochnochmal geschickt).

Hier einmal die Werte, die ich beobachtet habe, während ich die Knöpfe Hd-Strg und 1/0 verwendet habe.

Aktualwert, bevor irgendetwas gedrückt wird: x1020
Aktualwert nach Betätigung Hd-Strg x9020
Aktualwert nach zusätzlicher Betätigung von 1/0 x9422

Ihr müsst jetzt nicht groß rumrechnen, dass das entsprechende Bit8 auf das geprüft werden soll nicht gesetzt ist mit x9422 habe ich auch schon berechnet. Zwei Dinge gehen hier für mich hervor:
1. Der allererste Aktualwert ist anscheinend entscheidend, denn aus dem ersten Code wird ja mehr oder weniger Aktualwert und int mask x8000 verrechnet.Je nach dem wie also mein allerster Aktualwert aussieht, kann dadaruch schon dafür gesorgt werden das Bit8 irgendwann gesetzt wird.
2. Mit dem zweiten Code, wo int mask 0x002 verrechnet wird, verstehe ich nicht wie der Wert sich von x9020 auf x9422 ändert.

 

[M0rti]

Also da würde ich gerne nochmal auf die bereits geposteten Bilder verweisen, auf Seite 2 oder so. Da ist auch zu sehen wo sich die Farbe ändern soll. Das passiert über diesen Teil hier (jetzt dochnochmal geschickt).

Hier einmal die Werte, die ich beobachtet habe, während ich die Knöpfe Hd-Strg und 1/0 verwendet habe.

Aktualwert, bevor irgendetwas gedrückt wird: x1020
Aktualwert nach Betätigung Hd-Strg x9020
Aktualwert nach zusätzlicher Betätigung von 1/0 x9422

Ihr müsst jetzt nicht groß rumrechnen, dass das entsprechende Bit8 auf das geprüft werden soll nicht gesetzt ist mit x9422 habe ich auch schon berechnet. Zwei Dinge gehen hier für mich hervor:
1. Der allererste Aktualwert ist anscheinend entscheidend, denn aus dem ersten Code wird ja mehr oder weniger Aktualwert und int mask x8000 verrechnet.Je nach dem wie also mein allerster Aktualwert aussieht, kann dadaruch schon dafür gesorgt werden das Bit8 irgendwann gesetzt wird.
2. Mit dem zweiten Code, wo int mask 0x002 verrechnet wird, verstehe ich nicht wie der Wert sich von x9020 auf x9422 ändert.


Im SPS-Programm sind lediglich neue Variablen eingefügt worden (in DBs) und es sind FBs und FCs angepasst worden, hauptsächlich um die Länge der zu schickenen Pakete anzupassen, bzw Entscheidungsfunktionen wurden erweitert damit zwischen Handbetrieb und Matlabbetrieb unterschieden werden kann

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Du brauchst nicht rumrätseln und Vermutungen anstellen. Schau Dir den Ventil-Baustein im SPS-Programm an, wo die Ventilvariable verarbeitet wird - dann siehst Du ganz genau was gemacht wird.

Verabschiede Dich von dem Wort "Aktualwert" - die Ventilvariable ist sowieso eigentlich eine (unsauber deklarierte) Ansammlung von BOOLs bzw. ein BOOL-Array, vermutlich um Powertags zu sparen.

Harald

 

[RONIN]

Also da würde ich gerne nochmal auf die bereits geposteten Bilder verweisen

Bist jetz konnt ich noch kein SPS-Programm sehen...

2. Mit dem zweiten Code, wo int mask 0x002 verrechnet wird, verstehe ich nicht wie der Wert sich von x9020 auf x9422 ändert.

Weil das Bit (in dem Fall Bit 10), wie von vielen hier schon vermutet, nicht von WinCC beeinflusst wird, sondern vom SPS-Programm welches in irgendeiner Form auf das Setzen von Bit 1 reagiert.
Desbalb bleib ich auch bei der Meinung dass das gesuchte Bit8 für die Dynamik von der SPS gesetzt werden muss.

Leg also WinCC beiseite und schau mal wo die Word-Variablen verarbeitet werden.

 

[hub]

Bis vor kurzem hat auch mit den Backups alles funktioniert, dies ist jetzt auch nicht mehr der Fall

Hier mußt du als erstes ansetzen.
Vermutlich ist das Backup nicht der letzte/aktuelle Stand.
Wenn es mit dem Backup auch nicht geht, stimmen SPS-Programm und Visualisierung nicht zusammen.

Welches Backup hast du denn?
Von der Steuerung? Von der Visu? Oder beide?

Sollte es kein aktuelles Backup mehr geben, musst du entweder den Ventilbaustein an die Visu anpassen, oder die Visu an den Ventilbaustein.

 

[hub]

Zuviel Werbung?
-> Hier kostenlos registrieren

Funktionieren denn die Ventile überhaupt?
Richtigerweise dürfte das Ventil in der Visu. erst grün werden, wenn das echte Ventil eine Rückmeldung (offen) an die SPS übergibt.

Funktionieren die anderen Aktionen an den Eigenschaften Geometrie/Stile/Blinken/Sonstige/Kreis-Farbe?

Und zeig uns doch mal den Ventilbaustein.
(Bitte keine Hardcopy, sondern Programmcode)

 

[M0rti]

Hallo Ronin,

also ich bin etwas überrascht wie hier manche reagieren bzw Texte nicht gründlich lesen. Mir ist durchaus klar WIE einzelne Programm-Codes funktionieren oder wie auf welches Bit getriggert wird. Ich versuche deshalb nochmal zusammenfassen was hier passiert.

Betrachtet wird EIN Ventil.
1. Eine entsprechende Variable ist in einer DB angelegt.
2. Diese Variable wird in einem SPS-Program derart "verarbeitet", um zu prüfen und zu entscheiden von wo die Information für das Ventil herkommt -> Matlab oder WinCC
3. Ohne an dem Projekt in WinCC je etwas geändert zu haben, wird in WinCC durch drücken von Buttons der Wert der gleichnamigen verknüpften Variable verändert.
4. Eine Änderung des Wertes soll im laufenden Programm im HMI ein Farbumschlag herbeirufen.
5. Nachdem das Projekt erweitert wurde, wobei es sich dabei ausschließlich um Variablenerweiterung und nicht um Funktionsveränderung oder -Erweiterung handelte
kommt es im HMI für dieses Ventil zu keiner Farbänderung mehr, wobei im WinCC NICHTS geändert wurde.

6. Da mit dem drücken von Tasten im HMI eine Änderung des Aktualwerts einhergeht und so soll es doch auch verdammt nochmal sein, muss etwas dafür gesorgt haben, dass sich dieser verändert hat. Denn ansonsten wurde ja nichts geändert.
Und ich wiederhole mich da jetzt schon zum x-ten mal. Dennoch höre ich immer wieder : "Schau wo du die Word-Variablen änderst" Geändert werden diese ausschließlich übers HMI selbst, es gibt sonst keinen weiteren Kontrollfluss für diese
Art von Variablen.

Das sich der Fehler nicht in WinCC befindet, habe ich von Anfang vermutet. Ansonsten gibt es auch nur 2 Stellen wo etwas "passieren" kann.
In der DB selbst -> da habe ich mal gelesen kann es schon einen Einfluss haben wenn mehrere Datentypen gemischt werden, aslo beispielsweise Digitale und Analoge Variablen
Oder in der einen SPS-Funktion, die gebraucht wird um zu entscheiden woher ein Signal kommt.

@ hub
Ja die echte Funktion klappt, also alle Aktoren funktionieren nach wie vor an der Anlage.
Kümmere mich gleich mal darum den Programmcode herauszufiltern

 

[PN/DP]

Hallo M0rti,

ich bin ebenfalls etwas überrascht wie man als Hilfesuchender Hinweise standhaft ignoriert bzw. Texte nicht gründlich liest...

Nach ziemlich langer Diskussion ist nun klar, daß die Bits welche vom HMI beeinflußt werden, NICHT den Farbumschlag im HMI hervorrufen. Das Farbumschlag-Bit muß woanders beeinflußt werden - höchstwahrscheinlich in der SPS.

Und ich wiederhole mich da jetzt schon zum x-ten mal. Dennoch höre ich immer wieder : "Schau wo du die Word-Variablen änderst" Geändert werden diese ausschließlich übers HMI selbst, es gibt sonst keinen weiteren Kontrollfluss für diese
Art von Variablen.

Falls diese Aussage wirklich stimmt: hast Du in der SPS lediglich die neuen Variablen im DB angelegt und bearbeitest Du diese Variablen überhaupt nicht in der SPS? Dann kann der Farbumschlag auch garnicht funktionieren...
Ich kann Dir auch nur zum x-ten mal empfehlen: schau, wo die Word-Variablen im SPS-Programm verwendet werden und tue das mit den neuen Variablen genauso.


Im übrigen halte ich die Art, wie bei Dir vom SPS-Programm und von der HMI in das selbe DB-Wort geschrieben wird, für äußerst unsauber. Wenn man Variablen liest, Bits ändert und wieder zurückschreibt, dann muß man garantieren, daß in der Zwischenzeit niemand anders die Variable ändert. Ansonsten kann und wird es passieren, daß die Änderungen des anderen "Schreibers" überschrieben/rückgängig gemacht werden. Das geht nur solange gut, wie die SPS die selbst geschriebenen Bits immer schreibt und nie zurückliest.

Harald

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

PS: Wir wissen nicht, wie "tricky" Deine Ventilansteuerung programmiert wurde. Du solltest über die Querverweise des SPS-Ausgangs zu der Verarbeitungstelle finden können. Oder werden die Ventilausgänge womöglich direkt vom HMI programmiert?!

Harald

 

[hub]

Betrachten wir mal den Ablauf einer Ventilansteuerung und Rückmeldung,
ohne irgendeinen Programmcode zu berücksichtigen.

1. der Bediener drückt in der Visualisierung einen Button zum Öffnen/Schließen des Ventils
2. dieser Befehl geht von der Visualisierung an die SPS-Steuerung
3. die SPS-Steuerung steuert das Ventil hardwaremäßig an
4. das Ventil öffnet/schließt daraufhin und meldet den Zustand an die SPS zurück
5. die SPS schickt die Rückmeldung zur Visualisierung
6. die Visualisierung zeigt den Zustand mit einem Farbumschlag an

Punkt 3 und 5 sind die Programmroutinen im SPS-Programm. Üblicherweise werden diese Funktionen mit einem Baustein realisiert.

Bis zum Punkt 4 scheint alles in Ordnung zu sein.
Wahrscheinlich hängt es am Punkt 5, womit die Aussagen vom Ronin äußerst plausibel erscheinen.

Genaueres können wir erst sagen, wenn wir den Programmcode gesehen haben.

 

[hub]

... und es sind FBs und FCs angepasst worden, hauptsächlich um die Länge der zu schickenen Pakete anzupassen, bzw Entscheidungsfunktionen wurden erweitert damit zwischen Handbetrieb und Matlabbetrieb unterschieden werden kann

Wie schon von mehreren vermutet wurde, dürfte hier dein Problem liegen.
Ich bin mal auf den Programmcode gespannt.

 

[M0rti]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo Harald,

also ich ignoriere Texte und Hinweise keinesfalls. Bislang ergaben nur die Hinweise keinen Erfolg. Du hast aber gleichzeitig mein Argument untermauert das zumindest du meine Texte nicht richtig liest. Denn der "Vorwurf" das ich meine Programme unsauber schreiben würde, zeigt recht genau das du meine Texte nicht liest. Ich habe diese Programme nämlich nicht geschrieben, sondern übernommen. Die Art der Programmierung existiert meines Wissens seit 2007, praktisch seitdem damals die Anlage bei uns in Betrieb genommen wurde.

 

[M0rti]

@Hub

das denke ich auch. Ich versuche mal den Programmcode an Montag zu schicken, auch dieser ist äußert umfangreich und ebenfalls nicht von mir
geschrieben, sondern auch dieser existiert praktisch seit anno Zwieback

Gruß und schönes Wochenede

M0rti

 

[hub]

Nicht das ganze Programm.
Nur den Teil, der das Ventil steuert.
Wenn vorhanden, den Ventilbaustein.