TE2000: Lücke in LineChart erzeugen

P

PatrickSt

Level-2
Beiträge
53
Reaktionspunkte
23
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo zusammen,

da ja hier gerade so viele HMI-Experten unterwegs sind hätte ich mal eine Frage:
Ich habe Plots, in denen auf bestimmten Abschnitten der X-Achse keine Daten angezeigt werden sollen, weil diese ungültig wären.
Ich kann aber nicht sagen, wieviele ungültige Bereiche kommen werden.

Gibt es eine Möglichkeit dem Plot mitzuteilen, dass er diese Daten nicht plotten soll?

Struktur in der SPS sieht so aus:
1757664478831.png
Also 5 Linien mit je 300 Punkten.
Davon soll die erste Linie in Dunkelblau geplottet werden, die anderen in Hellblau (vergangene Daten).

Das sieht dann ungefähr so aus:
1757664532585.png

Jetzt habe ich im Linken Bereich ( bei -90 bis -80) aktuell ungültige Daten.
Ich habe schon versucht diese mit NaN zu kennzeichnen, aber dann kommt genau das raus, was ihr hier seht. NaN wird immer auf das aktuelle obere Limit der Y-Achse gesetzt (Dadurch leicht schräge Linien). -Inf und +Inf erzeugen entsprechend senkrechne Linien nach oben oder unten.

Ich suche also das Äquivalent zu der Option "connectgaps" in Plotly
https://plotly.com/python/line-charts/
1757664877201.png
1757664852222.png

Kann das LineChart so etwas?

Oder wie geht ihr damit um?
Einzige Alternative die mir einfällt wäre halt unmengen an Arrays zu erzeugen, um eine gewisse Menge an Lücken abdecken zu können.
 
Stand / stehe vor ähnlichen Herausforderungen, einschliesslich der Darstellung von Gaps.

Hatte wie du auch damit experimentiert, Linienwerte dort wo nichts dargestellt werden soll ausserhalb es sichtbaren Bereichs zu ziehen, aber es war auch dort keine grafisch akzeptable Lösung.

Die Funktionalität von LineChart und Trendlinechart ist selbst in der .14 Relase für Build 4026 einfach immer noch extrem limitiert. Bei den Trendlinecharts kam noch eine extrem schlechte Performance hinzu. Hatte TLC's zunächst mit der SQLite, danach der PostgreSQL Trendline-Extension realisiert und das laden von 6 Charts mit jeweils nur ein paar tausend Datenpunkten auf einer HMI-Seite dauerte volle 40 Sekunden.

Wegen der grafischen Limitierung und bei vielen Datenpunkten langsamen Darstellung, ist bei meiner TcHMI-Applikation jetzt letztlich genau das implementiert was du als grafisches Wunsch-Beispiel für Gaps angeführt hast:

PLOTLY.JS 📈:)

Wegen der umfangreicheren Möglichkeiten von Plotly sind bei der dortigen Applikation nun aber Unterbrüche nicht mit NULL Werten ausgeblendet, sondern weil es dort immer alle Linien betraf, werden die Bereiche mit grauen Shapes hinterlegt. Dass mit Plotly auch grafische Annotations (in meinem Fall Alarm-Markierungen und Anzeige von Produktnummern) möglich wurden, war ein weiteres Plus gegenüber den Beckhoff Chart-Controls.

Nebst der grafisch besseren Darstellung, wurden interessanterweise mit Plotly die exakt gleichen Daten vom exakt gleichen SQL-Server für welche TcHMI mit den eigenen Controls 40 Sekunden zum Laden und Anzeigen brauchte, mit Plotly über ein einfaches Node-Red Backend, in 1-2 Sekunden geladen und angezeigt.

Die Integration von Plotly.js in TcHMI hat sich jedoch leider, verglichen mit der simplen >Drag-Drop-Configure< Lösung des TcHMI Controls, als herausfordernd erwiesen, insbesondere den Speicher bei Seitenwechseln wieder frei zu bekommen, damit der Heap nicht irgendwann voll läuft. Bei mir erforderte die Plotly-Integration eine gute Woche Aufwand. Die Heap-Problematik habe ich mangels ausreichend tiefer JS Kentnisse (bin selbst immer noch "Absolute Beginner...") Stand heute immer noch nicht ganz im Griff.

Inzwischen läuft es aber und die TcHMI Applikation verwendet jetzt fast durchgend Plotly.js anstelle der Beckhoff LineChart und TrendlineChart Controls.

Dort wo Plotly die Daten aus einer SQL-Datenbank holen muss, ist der Daten-Fetch vom Backend direkt in der JS-Funktion integriert die dann auch irgend ein Chart darstellt.

Bei Charts welche (wie bei dir) ADS Daten darstellen, erfolgt die Übergabe der ADS PLC-Arrays einfach beim Aufruf der Funktion via Ereignis:1757710428852.png

Unten stehender Screenshot ist von einem Plotly-Chart das so auch direkt in der TcHMI dargestellt wird (hier aber mit Postgres-Daten). Dem Kunde gefiel das ganze mit Plotly grafisch dann doch einiges besser als die Trend-Controls von Beckhoff.
1757708177443.png
Wenn du bei Beckhoff-Controls bleibst und evtl. Trendline-Charts eine Option sind, könntest du die Daten-Aquisition einzelner Linien via JS stoppen, dann schaut es dort meines Wissens grafisch wirklich aus wie die Gap-Darstellung von Plotly bei NULL Werten.

Hier ein Link wo ein Mitarbeiter von Beckhoff Australien sowas zeigt:
beckhoff-au.teachable.com

Dynamic Historize symbols including add, remove, update

This is a collection of hints and tips for TE2000 TwinCAT HMI
beckhoff-au.teachable.com beckhoff-au.teachable.com
 
Glon schrieb:
Ich benutze aus dem Grund ECharts ( https://echarts.apache.org/en/index.html )

Das läuft sehr schnell und es gibt eine gute Dokumentation.
Zum Vergrößern anklicken....

Ja, ECharts gilt wohl als eine der schnellsten Charting-Libraries. Hatte mir beim Entscheid welche zum Einsatz kommt die Charting-Library-Comparison auf Wikipedia angeschaut und landete letztlich bei Plotly. Ein Bug von Plotly ist wenn man mehr als 2 Y-Achsen hat und die HMI Applikation responsive sein muss, dann verschiebt es einem beim Resize die 3. Y-Achse.

Denke am besten ist man nimmt das was man evtl. schon kennt, egal ob Plotly, ECharts, Charts, etc.

Comparison of JavaScript charting libraries - Wikipedia

en.wikipedia.org en.wikipedia.org

Womit hast du das Backend für deine mit ECharts dargestellten Daten gemacht?
 
Danke für eure Tipps und Ideen.

Trendline-Charts sind leider für meinen Anwendungszweck nicht passend. Und wenn diese eh schon eine schlechte Performance haben, dann bringen die mich auch nicht weiter.

Heap-Problematiken bei Plotly hören sich leider auch nicht gut an. Hatte die letzten Monate schon massive Probleme damit (Arbeitsspeicher und CPU-Last sind durch die Decke gegangen). Erst mit der 14.6 (und auch 14.7) hat Beckhoff etwas am Server geändert (was genau verraten sie aber nicht), das meine HMI wieder stabil gemacht hat.

Und da ich mich mit JS leider so gar nicht auskenne wird das wohl deutlich mehr Aufwand als nur eine Woche werden.

Aber danke für die Anregungen. Mal schaun, was ich draus mache.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
PatrickSt schrieb:
Heap-Problematiken bei Plotly hören sich leider auch nicht gut an. Hatte die letzten Monate schon massive Probleme damit (Arbeitsspeicher und CPU-Last sind durch die Decke gegangen). Erst mit der 14.6 (und auch 14.7) hat Beckhoff etwas am Server geändert (was genau verraten sie aber nicht), das meine HMI wieder stabil gemacht hat.
Zum Vergrößern anklicken....
Hier hast du mich falsch verstanden. Es gibt nach meinem Kenntnisstand kein "Heap-Problem" mit Plotly. Es ist einfach so, dass TcHMI bei Nutzung der integrierten Controls wenn diese entladen werden alles selbst wieder "aufräumt". Implementiert man eine externe Chart-Library, egal ob Plotly, ECharts, etc. muss man selbst dafür sorgen dass bspw. bei einem Seitenwechsel in der HMI alles auch wieder schön entladen wird. Das sind Sachen die gerade für Anwender mit wenig Erfahrung (dazu zähle ich auch mich) nicht gleich augescheinlich werden, die HMI funktioniert ja. Bis ein paar Tage oder Wochen später der Kunde anruft...

Den Link zum Trend-Example hatte ich dir vor allem auch geschickt weil man dort ja sieht, dass ein Beckhoff Chart-Display prinzipiell offenbar doch in der Lage zu sein scheint, Gaps darzustellen. Ob die Daten nun weil es ein Chart ist aus einem Array kommen, oder wenn es ein TrendlineChart ist aus einer Datenbank, dürfte da keinen generellen Unterschied machen. Könnte daher durchaus Sinn machen mal bei Beckhoff nachzufragen.

1757940555593.png

Von hoher Speicher- und CPU-Auslastung bei TcHMI Versionen <14.6 habe ich nichts gemerkt. Arbeite seit ende letzten Jahres an einer sehr grossen TcHMI Applikation wo bis zu 10 Clients zeitgleich verbunden sind, dort traten auch mit Builds prior 14.6 keine Ressourcen-Probleme auf. Allerdings läuft TcHMI dort auch auf einem IPC mit 32GB RAM, bis dem die Luft ausgeht braucht es schon einiges.
 
APT schrieb:
Womit hast du das Backend für deine mit ECharts dargestellten Daten gemacht?
Zum Vergrößern anklicken....
Mit nichts Besonderem. Das Backend ist ein recht großes, mehrdimensionales Array ([0..3, 0..4000] OF LREAL <- Beispiel) in der PLC.
Ich habe die Aufgabe, einen Prozessabschnitt darzustellen, nicht kontinuierlich etwas anzuzeigen.
Dazu habe ich einen Counter, der mir sagt, wie viele valide Datenpunkte im Array stecken. Diese Anzahl schiebe ich dann in das eChart-Diagramm.

1758008785370.png
Das Diagramm wird alle 75 ms aktualisiert, was sehr ansprechend aussieht. Auf einem CX5340 läuft das sehr performant.
 
Glon schrieb:
Das Backend ist ein recht großes, mehrdimensionales Array
Zum Vergrößern anklicken....
Dann war das ein Missverständnis. Ich meinte deine Applikation erfordert auch ein echtes Datenbank Backend. Die Daten werden bei mir zwar mit der PLC aquiriert, aber nur um diese in eine Postgres Datenbank zu schreiben. Die Chart-Scripte in TcHMI müssen SQL Queries via HTTP Backend an die Datenbank schicken. Bin mit meinem aktuellen Node-Red "Backend" nicht ganz glücklich, daher hatte ich die Frage gestellt, was du verwendest.
 
Zurück
Oben