Mehrere Instanzen aufrufen

Da ist dann auch gleich noch eine kleine Unsauberkeit drinnen.
   

Referenzen die nicht geschlossen werden könnten die das Programm auch killen... allerdings dauert das normalerweise etwas und endet mit Memory full.

Falls das natürlich überall so aussieht...?

Leider nichts, ich habe dieses VI disabled.
Interessanterweise klappt es mit EXEs und AllowMultipleInstances=True

Was bei "magischen" Probleme mitunter hilft, ist ein forced recompile per "Shift+CTRL+RunButton" aufm Main.
Ist aber auch nur Fischen im Trüben.

Ich habe gerade 3 Executables und ein VI gestartet, somit kann ich nun eine Instanz debuggen, während drei weiteren in EXE-Form nebenbei laufen.

Zumindest eine Workarroundlösung des Problems.

Danke schön

Könnte es sein, dass dir SubVIs, die du nicht als Reentrant definiert hast, deinen Ärger verursachen?

Wenn du dein Main-VI reentrant definierst, dann sind die darin enthaltenen SubVIs nämlich nicht automatisch reantrant, und somit hast du keine "unabhängigen" Instanzen, so wie jetzt bei 3x Exe parallel.

Gruß, Jens

Ja, sowas in der Richtung, aber es sind bestimmt über 500 VIs. Klar, da muss man nicht alle als reentrant definieren, aber viele. Ich habe jetzt übrigens 50 davon reentrant gemacht. Das Problem ist, dass man reentrante VIs schlecht debuggen kann.

Anzeige

Gegen ein Reentrancy Problem spricht allerdings das Fehlerbild "LV geht einfach zu".
Wenn es nur daran liegt, daß entscheidene VIs nicht reentrant sind, müßte es zu einem Deadlock kommen und Alles bzw. Teile stehen bleiben.
Im Zweifel würde ich eher mehr als weniger VIs reentrant setzen.

Benutzt du spezielle DLLs o.ä.? Rekursion (was allerdings m.E. nach gut funktioniert)?

Debugging von reentrant VIs ist mitunter lästig. So wie es aussieht hast du nur statische Instanzen, da müßtet du dich im Editmode durch- bzw. reinklicken können.
Beim Debuggen hilft manchmal in paar wichtigen VIs über per VI-Server das BD zu öffnen.

Queue´s, Notifier, TimedLoops usw.in Reentrant-Vi´s sollten meiner Erfahrung nach mit "unikaten" Namen versehen werden,
das heißt aber auch das diese dynamisch bei Reentrant Vi´s erstellt werden müssen.
Ist dies bei Dir der Fall?

Wie ist die Einstellung "VI-Properties - Execution - Enable automatic error handling" ?

Gruß
Ralf

' schrieb:Queue´s, Notifier, TimedLoops usw.in Reentrant-Vi´s sollten meiner Erfahrung nach mit "unikaten" Namen versehen werden,

Bei Queues und Notifier "könnte" es Sinn haben sie mit globalen Namen auszustatten. Ich vermute allerdings das in diesem Fall, keine Namen verwendet wurden, was für den dynamischen Ansatz hier wahrscheinlich passend ist.

Bei doppelten Namen für TimedLoops _sollte_ es nur zum normalen Fehler beim Starten der zweiten Schleife kommen (error out an der TimedLoop).

' schrieb:Queue´s, Notifier, TimedLoops usw.in Reentrant-Vi´s sollten meiner Erfahrung nach mit "unikaten" Namen versehen werden,
das heißt aber auch das diese dynamisch bei Reentrant Vi´s erstellt werden müssen.
Ist dies bei Dir der Fall?

Wie ist die Einstellung "VI-Properties - Execution - Enable automatic error handling" ?

Gruß
Ralf

Eher umgekehrt, wenn man einer Queue keinen Namen gibt, wird von LabVIEW automatisch eine unikale Referenz erzeugt, die ich dann auch in meinem Programm benutze. Ansonsten muss ich aufpassen, dass ich überall unikale Queues-Namen vergebe.

Wie gesagt, ich habe leider keine Zeit rauszufinden warum LV rausfliegt, wenn ich die 4 VIs reentrant starte. Ich bin auch mit der Variante 3 Executables + 1 VI halbwegs zufrieden und kann zumindest diese eine Instanz debuggen.