Vermeiden von Globalenvariablen aber wie?

Das tönt ja ganz genial!!
Vielen dank für deine Antworte(n)!!
Werde das ganze mal so probieren wie du es beschrieben hast!

Da sehe ich mal wieder wie wenig ich eigentlich von LabVIEW weiss!!
Ich arbeite jetzt schon 2.5Jahre mit LabVIEW und kenn immer noch nicht alle Funktionen!!

Anzeige

Verdamt ist das geil! Du bist mein Held eq!!!!!!!!!!!!!!!!!

' schrieb:Verdamt ist das geil! Du bist mein Held eq!!!!!!!!!!!!!!!!!

Ich habe noch was, das noch geiler ist

Es kommt glaub langsam gut!
Aber habe noch eine Frage zu meinem Programm!
Ich habe ja die 8 parallel while Loops und führe in denen 8 mal meine Statemachine aus! Nun verwende ich in den Statemachines etliche SUBVI's
öffters! So nun habe ich ein geschwindigkeits Problem da die mehrfachverwendeten SUBVI's ja nur einmal zum gleichen Zeitpukt ausgeführt werden können!

Variante 1: Bei allen mehrfach verwendeten SUBVI's VI properties :
"Reentrant Execution—Enables a VI to run in more than one execution system. Normally, a VI can run only in one execution system. However, if you want two execution systems to run the same VI simultaneously, place a checkmark in the Reentrant Execution checkbox. You cannot debug a reentrant VI." einschalten! Nachteil es ist kein debuging möglich

Variante 2 Die SubVI's 8mal mit verschiedenem Name speicher 1.SUB.vi, 2.SUB.vi use.......
Vorteil:debuging möglich
Nachteil: Statisch sehr viel aufwand für änderungen

Variante 3
Siehe http://www.LabVIEWforum.de/index.php?showt...trant+Execution
"du machst eine Referenz für das VI auf, hier macht er standardmäßig immer die Referenz zum selben VI auf, du brauchst aber verschiedene für die reentrant möglichkeit!

Das machst du in dem du bei open reference eine Option mit übergibst - in der online Hilfe siehst du die Opitonen die du hast.

Das wäre passend:
0x08 Prepare for reentrant run. Reserves the target VI so it cannot be edited and if the target VI is reentrant, allocates a dedicated parallel data space for this VI reference. If the target VI is not reentrant, the function returns an error."

Ist da debuging möglich? Ich denke nicht!?





Nun welche Variante würdet ihr mir empfehlen! Das ganze Programm sollte schon einfach zu debugen sein somit würde ich wohl Variante 2 wählen!
Oder wie seht ihr das?

Variante 1 und 3 sind fast gleich. Bei der 1 statischer Aufruf von reentranten VI bei 3 dynamischer Aufruf. Bei beiden ist kein Debugging möglich. Ich benutze meistens die erste Variante. Zum Debuggen schalte ich Reentrance aus und benutze es nur in einem parallelen VI, sobald es in einem funktioniert, schalte ich Reentrance wieder ein und benutze es dann in mehreren parallelen VIs.

Ich brauche nochmals eure Hilfe bei meinem Projekt!
Und zwar werden meine 8 MCU's in einem SUB'VI programmiert (die Applikation)! Dieses VI habe ich als reentrent eingestellt!
Nun wenn ich ein Stück programmiere geht der Download ca. 50s! Wenn ich nun alle 8 MCU's aufeinmal programmiere geht es für ein stück 2min30s!

Ich habe euch hier mal mein VI in welchem programmiert wird!
Als das File das auf die MCU programmiert werden soll wird in einen String geladen "mhx String" aus diesem werden die einzelnen Zeilen
in ein Array geladen! Und dann wird Zeilen weise aus dem Array geladen und die entsprechnde Zeile programmiert!
Dann wird auf eine Antwort von der MCU gewarte ACK oder NAK! Wenn ACK wird die nächste Zeile der MCU gesendet usw...

Mache ich irgendetwas mit der Seriellen Schnittstelle Falsch oder fällt sonst was auf das sehr Zeitintensiv ist?

Ich sehe selbst schon noch sachen die zu verbessern sind zum beispiel all die Lokalen Variablen rausschmeisen aber ich kann mir nicht vorstellen das dies die Ursache für den langen Download ist!

Ich bin kurz davor dieses Projekt hinzuschmeisen!!

Anzeige

' schrieb:Mache ich irgendetwas mit der Seriellen Schnittstelle Falsch

Naja, falsch eigentlich nicht. Eher unnötig. Wenn BytesAtPort Null ist, warum liest du dann diese null Zeichen aus?

Ich würde in die Schleife mit dem BytesAtPort-Property auf jeden Fall eine Wartezeit von 10ms reinmachen und auch nur Visa-Lesen, wenn was da ist.

Allgemeine Rückfrage:
1. Verstehe ich richtig: Dich ärgert nicht, dass das Programmieren einer MCU 50s dauert, aber dass das parallele Programmieren von 8 MCUs 2:30 dauert?
2. Wie ist das, wo hängen denn die MCU's dran, an einer seriellen Schnittstelle oder an 8 Schnittstellen? Wenn das zweite, was hast du für eine "Karte", die 8 serielle Schnittstellen bereitstellt. Ich habe mal gehört, dass mehrere serielle Schnittstellen unter Windows nicht gerade "schnell" ist, also man hat nicht unbedingt die doppelte Bandbreite bei 2 Schnittstellen gegenüber einer.
3. Und selbst wenn du jetzt 8 VI's parallel laufen hast, auf einem Single-Core-Rechner muss das ganze immer noch seriell ausgeführt werden.

Gruß, Jens

EDIT: Zwischen den Write- und den Read-Befehl gehört eine "gewisse" Wartezeit. Schließlich müssen die Zeichen erst mal gesendet werden, dann soll deine MCU antworten. Soll heißen: Im ersten oder den ersten paar Durchläufen hast du sicher immer "Bytes at Port = 0". Das jagt sicher immer kurzfristig die CPU-Last hoch.

EDIT 2: Ich weiss jetzt nicht, ob es das schon in LV6.1 gab, aber statt immer "Bytes at Port" zu pollen, kann man auch ein Event verwenden und warten, bis überhaupt Zeichen am Port anliegen. Die VIs findet man bei den 8er-Versionen hier:
   

1. Ja genau was mich ärgert ich habe das Programm von jemand anderem ungeschrieben war da ein föliges chaos im Programm und unübersichtlich!
Ich habe nun das vorhandene Programm etwas umgeschrieben und da habe ich für 8 MCU's parallel programmieren ca.50s
Ich habe nun das Programm koplett umgeschrieben und nun erreiche ich 8xparallel Programmieren 2min30s

2. Es ist eine MOXA 8 Fach PCI Express RS232 Schnittstellenkarte MOXA CP-168EL
http://www.moxa.com/product/download/CP-168EL.pdf

Ich kann einfach nicht verstehen wiso es mit meinem VI nicht so schnell geht wie mit dem alten!

PS:danke für deine schnelle Antwort!!

@ Jens:

2. Ich habe schon mit 16 Ports (2X8Port Karten) unter Windows gearbeitet, kein Problem
3. Serielle Übertragung ist viel langsamer als ein PC-Core rechnen kann, somit auch bei mehreren quazi-parallelen VIs, die serielle Schnittstelle auslesen, sollte es kein Problem machen.

@Cardinal, ich denke du solltest deine Kommunikation auf eventgesteuert umschreiben. Bytes On Port ist keine besonders gute Wahl. Du kennst doch das Übertragungsprotokoll, somit weisst du auch wie viele Zeichen du lesen willst, warum benutzt du denn noch Bytes On Port?