(29.10.2017 14:30 )Rene123 schrieb: haben sich folgende Probleme ergeben: 1. Controls verschieben sich beim Skalieren ...
OK ich nehme alles, was ich zu Skalierung gesagt habe, zurück. Ich hab nämlich gedacht, du meinst die Skalierbarkeit der Software. FP-Skalierung, und das auch noch automatisch - so etwas verwende ich überhaupt nicht (oder: so sein Scheiß, das funktioniert hinten und vorne nicht ausreichend). Wenn du was über Skalierung von FP-Elementen wissen willst, müssen da andere was sagen.
Zitat:Ich meinte hier, dass es ggf. Verzögerungen beim UI führen könnte.
Was interessiert dich die Verzögerung beim Öffnen/Schließen eines VIs bzw. beim sichtbar/unsichtbar machen eines FP? Das geht alles schnell genug. Solltest zu Sorge haben, dass eine kontinuierliche Messwerterfassung unter dem Management eines VIs bzw. FPs leidet, kann ich dich beruhigen: Das klappt alles hervorragend - dafür benutzt du ja LabVIEW.
Zitat:Wie soll ich die schließen, wenn ich mittels Event nur die Vis anzeigen lasse???
Ich bin immer noch nicht ganz bei dir.
Du kannst das Management deiner VIs respektive FPs so machen, das wird funktionieren - halt mit den erwähnten Einschränkungen beim Debuggen.
Zitat:--> Nein! Wenn das Programm läuft, sind die SubVIs welche im Frontpanel aufgerufen werden nicht mehr zugänglich.
Hierzu muss ich sagen: Eine Programmier-Philosophie, die ein Debugging nicht ausreichendes unterstützt, muss abgelehnt werden.
Zitat:--> Bisher ging es gut.
Ein ganz schlechtes Argument. Aber dafür fragst du ja nach Verbesserungen.
Strenggenommen kann man jedes VI so gestalten, dass es standalone läuft - somit ist es ausreichend debuggbar.
Zitat:Macht es dann Sinn für jedes Cluster (Config, Header, Messdaten etc.) eine eigene FGV anzulegen?
Es ergibt schon einen Sinn, für jeden Cluster eine eigene FGV zu machen. "Datenkapselung" spricht z.B. dafür. Und Vereinfachung. Wenn natürlich die einzelnen Cluster eine gewisse enge Beziehung haben, kann man auch ein FGV nehmen.
Zitat:Ich habe die 3 Shift Register und die beiden Schleifen aus der GUI gelöscht und habe 30% weniger CPU-Auslastung. Scheinbar bringt es doch was.
Nicht, dass alleine das Löschen der Schleifen die Ersparnis bringt. Gegenbeispiel: Ich hab nur FGV, davon aber viele und selbst sonst jede Menge Schieberegister - und trotzdem eine maximale Auslastung von 7% - wegen Netzwerk-Transfer, nicht wegen Schieberegister.
Theoretisch könntest du Recht haben, dann aber musst du deinen Fall genauer beschreiben und erklären.
Zitat:Funktionieren Event-Strukturen ohne While-Loop?
Ja. Aber: dann nur ein einziges Mal - da der Datenfluss abgearbeitet ist. Sinnvollerweise liegt die Event-Struktur selbstverständlich in einer While-Schleife - dann aber alleine.
Zitat:Globale Variablen? Das sind "Ressourcen-Fresser"!
Wenn ich das noch richtig in Erinnerung habe, werden Globale Variablen wie folgt gemanagt: Jedes Element "Globale Variable lesen" bekommt ihren eigenen Speicher. Das bedeutet, dass bei "Globale Variable schreiben" jeder dieser Lese-Speicher überschrieben wird. usw. Bedenke außerdem: RaceCondition ist ein weites Feld. Globale Variablen sind extrem anfällig dafür. Mit FGV, wenn richtig angewandt, können keine RaceCondions auftreten.
Zitat:Könntest du hier mal ein Beispiel zeigen??? Bin grad nicht so sicher wie das funktionieren soll^^
Schau mer mal ...
Zitat:Bin gespannt, wie sich das auf die Leistung auswirkt, da die FGV ja ein VI ist und der Code jedesmal kopiert wird.
Wo wird da Code kopiert? Kopiert, weil Datenfluss, werden vielleicht Daten, aber kein Code. Was hast du denn für einen Rechner? Ein Smartphone? Ich schiebe Megabyte-weise Messdaten hin und her, da gibt es keine nennenswerte Prozessorauslastung. Einen Fall mit sehr viel Auslastung hab ich - mit 21 Seriellen Schnittstellen RS232.
