TIA 1400Bit Schieberegister + Visu (314C 2PN/DP) 15" Com.Panel

R

rogseut

Level-2
Beiträge
280
Reaktionspunkte
21
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo ihr lieben,

Benötige ein Schieberigster mit 1400 Bit um eine Anzeige von belegten Nestern zu erstellen. Irgendwie kann ich mir nicht vorstellen wie das gehen soll. Die Nester werden alle 2s einen Takt weiter geschoben und mit Produkt belegt oder eben nicht. Am Ende werden diese abgenommen. Die Anzeige soll am besten auf einem Bild alle 1400 Nester mit kleinen farbigen Punkten angezeigt werden.

Wie um Himmelswillen soll man das Visualisieren?

1400 einzelne Bool Variablen wird beim besten Willen nicht funktionieren. Bitte helft mir weis nicht weiter. Gibt es für diese Aufgabe überhaupt eine Lösung?

Gesendet von meinem SM-A750FN mit Tapatalk
 
Du kannst ein DWORD Array verwenden, und die Bits durch shiften der DWORDs dadurchschieben. Das sind dann nur 44 DWORDs.
Ich habe mir vor einiger Zeit mal einen kleinen Logikanalysator damit programmiert:
https://www.sps-forum.de/hmi/66893-bit-kontrolle-ueber-wincc-flexible-runtime.html#post463079

Wenn du entsprechende Bildobjekte pro DWORD erstellst, ist das noch einigermaßen einfach zu projektieren. Bei deinem Bediengerät musst du nur darauf achten, dass es die entsprechende Anzahl an Objekten darstellen kann.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Müssen die Bits am HMI immer mit dem ersten Nest ganz oben/vorn angezeigt werden?
Anstatt 1400 Bits alle 2s komplett zu verschieben würde ich lieber einen Ringpuffer nehmen und nur einen Zeiger auf den logischen Anfang des Rings um 1 Bit weiterstellen.
Müssen alle 1400 Nester zu sehen sein? Reichen vielleicht die ersten 32 und die letzten 32? Und eventuell dazwischen nur eine Zahl mit der Anzahl der belegten Nester?

Harald
 
rogseut schrieb:
Wie um Himmelswillen soll man das Visualisieren?
Zum Vergrößern anklicken....
Wozu um Himmelswillen soll man so etwas Visualisieren?
Eine Visualisierung soll es doch erleichtern, irgendeinen Sachverhalt schnell zu erfassen.
Aber welchen Sachverhalt, worauf kommt es denn wirklich an?
Es kann doch nicht angehen, dass jemand in den max. 2 s, in denen das Bild stillsteht, die Anzahl belegter Nester zählen soll? Oder vielleicht soll er erfassen, wie viel Prozent belegt sind?
Oder, an welcher Stelle das Befüllen der Nester in Verzug gerät? Oder was? :confused:
 
Thomas_v2.1 schrieb:
Du kannst ein DWORD Array verwenden, und die Bits durch shiften der DWORDs dadurchschieben. Das sind dann nur 44 DWORDs.
Ich habe mir vor einiger Zeit mal einen kleinen Logikanalysator damit programmiert:
https://www.sps-forum.de/hmi/66893-bit-kontrolle-ueber-wincc-flexible-runtime.html#post463079

Wenn du entsprechende Bildobjekte pro DWORD erstellst, ist das noch einigermaßen einfach zu projektieren. Bei deinem Bediengerät musst du nur darauf achten, dass es die entsprechende Anzahl an Objekten darstellen kann.
Zum Vergrößern anklicken....

Ich habe nur das Thema gelesen und hatte direkt den gleichen Einfall. Sprich "nur" 1400 / 8 / 4 = 43,75 ~ 44 DWORDS. Und die über n SHL / SHR zu schieben sollte in ner FOR-Schleife mit SCL kein Problem darstellen.
Was willst du denn in der Visu visualisieren? Und mit welcher Refresh-Rate? Und müssen es immer alle Variablen sein?

Ich hab das "Problem" bei nem Pferdestall gehabt. Da wollte der Betreiber einstellen können, wann das Pferd essen darf und wann nicht, im viertel-Stunden-Takt.

24h * 4 1/4 h = 96 Zeiten => 96 Bit / 8 Bit/Byte = 12 Byte / 4 Byte/Doppelwort = 3 Doppelwörter. Und das mal 42 Boxen sind 126 Doppelworte - Wenn man jetzt versucht, das auf einer Visu Seite darzustellen: Ja tolle Wurst... Pro Box geht das aber!
Und wenn das bei dir Abschnittsweise für "Nestgruppen" oder Bearbeiotungsstationen geht - dann ist das doch auch OK. Schlimmstenfalls zeigst du das DWORD als Binärfolge an: Das ist zwar "hässlich", aber nach einer Zeit wissen die Leute schon, was da was bedeutet. Denn wenn der Mensch was kann, dann in einem normalerweise symmetrischen Muster eine Auffälligkeit finden.

Viele Grüße!
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Wie schon geschrieben, ist das kein Programmieraufwand in einer For-Schleife 44 DWords zu shiften, und jeweils das letzte Bit in das nächste DWord zu übernehmen.
Die Visualisierung ist auch kein Aufwand. In dem verlinkten Post von mir habe ich einen Bildbaustein mit 32 Linien für ein DWord erstellt. Da machst du dann 44 mal Copy&Paste, passt die Verknüpfung an und bist fertig.
Das ginge prinzipiell auch als Bool-Array, aber das benötigt in der SPS mehr Laufzeit und in der Visualisierung mehr Projektierungsaufwand.
 
Wie ist denn die Systemgrenze "Objekte pro Bild" für Comfort Panels?
Im Systemhandbuch WinCC V15.1 Kapitel "16.2 Leistungsmerkmale der Geräte" gibt es die Angabe "Anzahl Felder pro Bild: 600". Wenn 1400 Pixel im Bild animiert werden sollen dann braucht man doch auch 1400 Rechtecke oder Kreise. Oder sollte man besser mehrere Pixel gleichzeitig per Grafiklisten animieren?

Harald
 
PN/DP schrieb:
Wie ist denn die Systemgrenze "Objekte pro Bild" für Comfort Panels?
Im Systemhandbuch WinCC V15.1 Kapitel "16.2 Leistungsmerkmale der Geräte" gibt es die Angabe "Anzahl Felder pro Bild: 600". Wenn 1400 Pixel im Bild animiert werden sollen dann braucht man doch auch 1400 Rechtecke oder Kreise. Oder sollte man besser mehrere Pixel gleichzeitig per Grafiklisten animieren?
Zum Vergrößern anklicken....

Ich meine hier im Forum hat mal jemand geschrieben, dass gruppierte Objekte dann wieder als eines zählen. Ob das Ganze dann funktioniert steht auf einem anderen Blatt. In meiner WinCC flexible PC Runtime habe ich 5120 animierte Linien in einem Bild, in Runtime läuft das besser als im Projektierungseditor. Ich vermute mal, das TIA-Portal stürzt bei der Anzahl direkt ab oder wird unbenutzbar.
 
Also der Kunde möchte alle Nester sehen um zu sehen wo der Anfang sich gerade befindet und wann dieser am Ende ist. Bei evtl. Produktionslücken auch die Lücke bzw. dessen Neuanfang. Ich habe ihm vorgeschlagen das ich ihm die Zeit bis die ersten Produkte das Ende erreichen anzeige, wurde von Ihm abgelehnt. Er sagt das ist doch in 20min programmiert und meint er bekommt das für lau (schwieriger Kunde). Die Nester sind in einer Kette eingebaut und laufen in Schlangen hoch und runter. Ich dachte an eine Matrix z.B. aus 35x40 kleinen Kreisen in grauer bzw. dann gelber Farbe. Wenn ich mir das alleine schon vorstelle werd ich wahnsinnig. Eine andere Idee ist so eine art Ladebalken der sich mit zwei Farben für voll und leer immer weiter bewegt.

Gesendet von meinem SM-A750FN mit Tapatalk
 
Man kann sich ja so viele Varianten ausdenken und zum Teil sicherlich auch realisieren.
Projektier und realisier doch mal eine Variante, die nicht übermäßig Arbeit macht und mit den verfügbaren Mitteln machbar ist - nur so, als abschreckendes Beispiel!
Und gut aufbewahren - lässt sich bestimmt immer wieder mal für solche Zwecke verwenden! ;)

Kann denn der Kunde so absolut gar nichts dazu sagen, worauf es ihm ankommt? Welche TeilAspekte sind ihm wichtig? Lassen sich diese evtl. gruppieren bzw. auf mehrere Bilder aufteilen?
Könnte mir vorstellen, dass z.B. einige wenige Zahlen oder BalkenDiagramme mehr zur Übersichtlichkeit beitragen könnten, als ein Gewusel von bunten Rechtecken auf dem Bildschirm.
Aber das hängt natürlich davon ab, welche Informationen man aus den 1400 Bits ablesen möchte ...
 
Zuviel Werbung?
-> Hier kostenlos registrieren
PN/DP schrieb:
Müssen die Bits am HMI immer mit dem ersten Nest ganz oben/vorn angezeigt werden?
Anstatt 1400 Bits alle 2s komplett zu verschieben würde ich lieber einen Ringpuffer nehmen und nur einen Zeiger auf den logischen Anfang des Rings um 1 Bit weiterstellen.
Müssen alle 1400 Nester zu sehen sein? Reichen vielleicht die ersten 32 und die letzten 32? Und eventuell dazwischen nur eine Zahl mit der Anzahl der belegten Nester?

Harald
Zum Vergrößern anklicken....
Ja der Anfang und das Ende der Schlange sollen statisch sein. So wie es auch bei der Maschine ist. Hier gehen mehrere Schleifen hoch und runter mit den Nestern. Bestimmt 30 Schleifen so die Richtung. Die Punkte sollen nach jedem Takt ein Nest weiter Wandern.

Gesendet von meinem SM-A750FN mit Tapatalk
 
rogseut schrieb:
Die Nester sind in einer Kette eingebaut und laufen in Schlangen hoch und runter.
Zum Vergrößern anklicken....
Na, die Schlangen sind immerhin auch schon eine Art Ansatz.
Hoch und runter könnte man evtl. auf die Bildschirm-freundlichere Darstellung in Zeilen "abwechselnd von links nach rechts und umgekehrt" anpassen.
Hier im Forum hatten wir zumindest schon mal das Thema, wie man die BitReihenfolge in einem DWORD spiegelt.
Wie oft rauf und runter? Wie viele Nester jeweils bei rauf und bei runter? Es müssen ja nicht alle 32 Bit eines DWORD und nicht insgesamt exakt 44 DWORDs sein.
Das könnte man doch den mechanischen Gegebenheiten anpassen und dann überschlagen, ob sich das vernünftig auf 1 Bildschirm wiedergeben lässt.

Warum soll dies nun übersichtlicher sein? Nun ja, wenn man die Mechanik erkennbar nachvollzieht, kann man evtl. die UmlenkPunkte der Kette als OrientierungsPunkte gut wiederfinden.
Das kann schon einiges zur Übersichtlichkeit beitragen.
 
Heinileini schrieb:
Wozu um Himmelswillen soll man so etwas Visualisieren?
Eine Visualisierung soll es doch erleichtern, irgendeinen Sachverhalt schnell zu erfassen.
Aber welchen Sachverhalt, worauf kommt es denn wirklich an?
Es kann doch nicht angehen, dass jemand in den max. 2 s, in denen das Bild stillsteht, die Anzahl belegter Nester zählen soll? Oder vielleicht soll er erfassen, wie viel Prozent belegt sind?
Oder, an welcher Stelle das Befüllen der Nester in Verzug gerät? Oder was? :confused:
Zum Vergrößern anklicken....
Er will Lücken erkennen, wie groß diese sind und wo der Anfang und das Ende ist. Verstehe ihn schon, um zu sehen was ab geht muss man in einen extra Raum wo diese Maschine steht und mal kurz entlang laufen um zu sehen wie die Lage ist. Das will er sich sparen.

Gesendet von meinem SM-A750FN mit Tapatalk
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Heinileini schrieb:
Na, die Schlangen sind immerhin auch schon eine Art Ansatz.
Hoch und runter könnte man evtl. auf die Bildschirm-freundlichere Darstellung in Zeilen "abwechselnd von links nach rechts und umgekehrt" anpassen.
Hier im Forum hatten wir zumindest schon mal das Thema, wie man die BitReihenfolge in einem DWORD spiegelt.
Wie oft rauf und runter? Wie viele Nester jeweils bei rauf und bei runter? Es müssen ja nicht alle 32 Bit eines DWORD und nicht insgesamt exakt 44 DWORDs sein.
Das könnte man doch den mechanischen Gegebenheiten anpassen und dann überschlagen, ob sich das vernünftig auf 1 Bildschirm wiedergeben lässt.

Warum soll dies nun übersichtlicher sein? Nun ja, wenn man die Mechanik erkennbar nachvollzieht, kann man evtl. die UmlenkPunkte der Kette als OrientierungsPunkte gut wiederfinden.
Das kann schon einiges zur Übersichtlichkeit beitragen.
Zum Vergrößern anklicken....
Genau wie du schreibst habe ich mir das vorgestellt. Die Mechanik am Bildschirm nachzubilden. Damit hat man einen besseren Zusammenhang. Nir wie ich die einzelnen Bits projektiere ist mir ein Rätsel.

Gesendet von meinem SM-A750FN mit Tapatalk
 
Also ich kann mir schon Anwendungsfälle vorstellen wo so eine Darstellung sinnvoll ist.
Z.B. bei einer langen nicht einsehbaren Produktionslinie wo von Mitarbeitern manuell etwas ausgeführt werden muss. Und da kannst du anhand so einer Darstellung eben schnell sehen, ob da gleich in einer Minute ein riesen Schwall kommt, oder ob du bis zum nächsten Teil noch grad einen Kaffee holen gehen kannst.
 
rogseut schrieb:
Genau wie du schreibst habe ich mir das vorgestellt. Die Mechanik am Bildschirm nachzubilden. Damit hat man einen besseren Zusammenhang. Nir wie ich die einzelnen Bits projektiere ist mir ein Rätsel.
Zum Vergrößern anklicken....

Ich habe mein Schieberegister damals so programmiert:
Code: 
FUNCTION "Logik-1Ch" : VOID
//
// Logikanalysator Funktion zur Aufzeichnung eines Kanals
// Bei Speicherung wird das Eingangsbit in das
// Speicherarray hineingeschoben. Das aktuellste Bit steht somit
// immer im Array an Position 1, Bit 0.
//
CONST
    DATASIZE := 20;     // Größe des Dword-Arrays
    IN_BITPOS := 7;     // Bit-Position im Bool-Array an der reingeschoben wird
    OUT_BITPOS := 24;   // Bit-Position im Bool-Array an der rausgeschoben wird
END_CONST

VAR_INPUT
    Signal : BOOL;      // Aufzuzeichnendes Signal
    Speichern : BOOL;   // bei 1 wird der Signalzustand gespeichert
END_VAR

VAR_IN_OUT
    Speicher : ARRAY[1..DATASIZE] OF DWORD; // Speicher
END_VAR

VAR_TEMP
    i : INT;
    HM_DW : DWORD;
    AT_HM_DW AT HM_DW : ARRAY[0..31] OF BOOL;
    BitOut : BOOL;
    BitIn : BOOL;
END_VAR

BEGIN
IF Speichern THEN     
    BitIn := Signal;
    FOR i := 1 TO DATASIZE DO
        HM_DW := Speicher[i];
        BitOut := AT_HM_DW[OUT_BITPOS];
        HM_DW := SHR(IN := HM_DW, N := 1);
        AT_HM_DW[IN_BITPOS] := BitIn;
        Speicher[i] := HM_DW;
        BitIn := BitOut;
    END_FOR;
END_IF;

END_FUNCTION
Da ich in der Visualisierung ebenfalls ein DWord als Bildbaustein hatte, habe ich mir das so projektiert dass die Reihenfolge passt.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Interessantes Thema,

was mir Sorgen machen würde, speziell bei dem Comfort Panel wären die Systemgrenzen, dass das Panel mit dem bei mir berühmten
Fehler "Application hmiRTm.exe encountered a serious erros and must shut down" abstürzt.

Das Thema wurde hier ja schon oft durch gekaut und ist gar nicht so selten :roll:
 
rogseut schrieb:
Nur wie ich die einzelnen Bits projektiere ist mir ein Rätsel.
Zum Vergrößern anklicken....
rogseut schrieb:
Er will Lücken erkennen, wie groß diese sind und wo der Anfang und das Ende ist.
Zum Vergrößern anklicken....
Das ist ja schon ein Ansatz.
Jedes einzelne Bit muss also nicht sein.
Eine denkbare Unterteilung wäre, jeweils 8 Bit zusammenzufassen und so nur noch 175 Felder zu haben oder 4 Bit zusammenzufassen, um auf 350 Felder zu kommen.
Die Anzahl der 1-Bits in einer Gruppe könnte verwendet werden, um entsprechend der Anzahl zusammengefasster Bits die Helligkeit oder Farbe der Felder in Stufen zu variieren.
Das klingt zwar nach viel Rechnerei, ist aber auch gut in einer Schleife zu realisieren. Und die SPS könnte auch bei Unter-/Überschreitung von Grenzwerten Alarm schlagen, damit nicht ständig jemand die 1400 wandernden Punkte im Auge behalten muss.

Anfang und Ende einer Lücke sollen erkannt werden? Bezieht sich das auf den aktuellen AufenthaltsOrt der Lücke oder auf den Ort, wo die Lücke entstanden ist oder auf beides?
 
Vielleicht eine Übersicht wo man mit Farben in den einzelnen Abschnitten den Füllgrad erkennen kann und dann für jeden Abschnitt ein Bild mit den einzelnen Nestern machen.

oder einfach eine oder mehrere Webcams in den Raum, Licht einschalten -> glücklich werden mit wenig Aufwand:razz:
 

Similar threads

C
Step 7 CP342-5 DP Diagnose
Antworten
5
Aufrufe
4K
Zonder
Zonder
O
Hilfe für Technikerarbeit.... mit WinCC flex
Antworten
7
Aufrufe
9K
rogseut
R
W
Schieberegister
Antworten
2
Aufrufe
3K
Wasserkraft
W
Zurück
Oben