Problem mit Umgebungsvariablen

' schrieb:Synchro-SV = "Synchronisierungs-Shared-Variable" = Synchronisierungs-Umgebungsvariable...

D.h. du erzeugst weitere Variablen, die du als Handshake hier True und dort False setzt...ich glaube, so hat es Markus gemeint!

Hm bei der kann dann doch genausogut das Problem austreten oder?
will mir jetzt nicht umsonst die mühe für mitlerweile 40 Variablen machen.

Anzeige

Richtig. :top:
Genau so mache ich das auch, um diese Probleme zu vermeiden. Durch so einen "Handshake" hast man keine Racing-Conditions, weil wirklich erst gelesen wird, wenn auch schon geschrieben wurde und das machst Du mit einer boolschen (Synchro-)SV, die Du auf True setzt, wenn Du einen Wert in eine SV geschrieben hast. Dann wird in einem Case im anderen VI, den genau diese boolsche SV auf True setzt, der Wert ausgelesen. Gleichzeitig wird die boolsche SV wieder auf "False" gesetzt und dann wird wieder auf "True" gewartet. Außerdem kann man dann nach dem Auslesen eine 2. boolsche SV auf "True" setzen, die dem anderen VI dann "mitteilt", dass ausgelesen wurde. Danach kann man im anderen VI diese 2. boolsche SV auf "False" setzen, wieder einen Wert in die SV schreiben, die 1. boolsche SV auf "True" setzen,.....................
War das jetzt klarer?

Gruß Markus

' schrieb:Synchro-SV = "Synchronisierungs-Shared-Variable" = Synchronisierungs-Umgebungsvariable...

D.h. du erzeugst weitere Variablen, die du als Handshake hier True und dort False setzt...ich glaube, so hat es Markus gemeint!

Wenn es an Racing-Conditions liegt, dann nicht. Du wartest in Deinen VIs (in State-Machines) im Leerlauf-Case, bis die boolschen SVs gesetzt wurden (nachdem geschrieben und gelesen wurde, vgl. dazu auch den letzten Post).

Gruß Markus

' schrieb:Hm bei der kann dann doch genausogut das Problem austreten oder?
will mir jetzt nicht umsonst die mühe für mitlerweile 40 Variablen machen.

' schrieb:Richtig. :top:
Genau so mache ich das auch, um diese Probleme zu vermeiden. Durch so einen "Handshake" hast man keine Racing-Conditions, weil wirklich erst gelesen wird, wenn auch schon geschrieben wurde und das machst Du mit einer boolschen (Synchro-)SV, die Du auf True setzt, wenn Du einen Wert in eine SV geschrieben hast. Dann wird in einem Case im anderen VI, den genau diese boolsche SV auf True setzt, der Wert ausgelesen. Gleichzeitig wird die boolsche SV wieder auf "False" gesetzt und dann wird wieder auf "True" gewartet. Außerdem kann man dann nach dem Auslesen eine 2. boolsche SV auf "True" setzen, die dem anderen VI dann "mitteilt", dass ausgelesen wurde. Danach kann man im anderen VI diese 2. boolsche SV auf "False" setzen, wieder einen Wert in die SV schreiben, die 1. boolsche SV auf "True" setzen,.....................
War das jetzt klarer?

Gruß Markus

Hm, gibt es denn keine Synchronisationstools dafür? Muss man das wirklich mit zusätzlichen Variablen absichern? Also ich kenne mich da nicht so aus. Wenn, dann benutze ich ein normales TCP/IP Server-Client Modell.

eg

Ich kenne bisher keine Tools dafür.
Das Client-Server-Modell ist dafür m.E. zu kompliziert und auch zu komplex. Wenn er 40 unterschiedliche SVs hat, dann müsste er ja 40 Client-Server-Modelle verwenden.....
Ich finde SVs um Daten von einem Rechner auf den anderen Rechner zu übertragen sehr praktisch.

Gruß Markus

' schrieb:Hm, gibt es denn keine Synchronisationstools dafür? Muss man das wirklich mit zusätzlichen Variablen absichern? Also ich kenne mich da nicht so aus. Wenn, dann benutze ich ein normales TCP/IP Server-Client Modell.

eg

' schrieb:Ich kenne bisher keine Tools dafür.
Das Client-Server-Modell ist dafür m.E. zu kompliziert und auch zu komplex. Wenn er 40 unterschiedliche SVs hat, dann müsste er ja 40 Client-Server-Modelle verwenden.....
Ich finde SVs um Daten von einem Rechner auf den anderen Rechner zu übertragen sehr praktisch.

Gruß Markus

Eins reicht vollkommen. Die "Variablen" werden zu Paketen, mit dem Identifier könnte man diese unterscheiden.

eg

Achso.... Damit kenne ich mich leider nicht so toll aus, weil ich von Anfang an SVs verwendet habe.

Gruß Markus

' schrieb:Eins reicht vollkommen. Die "Variablen" werden zu Paketen, mit dem Identifier könnte man diese unterscheiden.

eg

' schrieb:Achso.... Damit kenne ich mich leider nicht so toll aus, weil ich von Anfang an SVs verwendet habe.

Gruß Markus

Vielleicht denkst du noch dass SV leichter zu handhaben sind, als TCP/IP Server-Client Modell? Vom ersten Blick vielleicht, aber wenn du tiefer gräbst, wie jetzt in diesem Topic, merkst du direkt, dass SVs einige schwere Nachteile haben. Mit TCP/IP hätte man keine Probleme mit Race Conditions. Mit Synchronisation kann man auch das Polling im Programm vermeiden.

Sorry, wenn ich da bissel zu viel gesagt habe. Wenn NI diese eingeführt und freigegeben hat, dann darf man die SVs natürlich auch benutzen. Nur denkt bitte an Race Conditions. Diese können bei lokalen, globalen und shared Variables auftreten! Race Conditions sind schwer zu orten. Wenn man Variablen im Projekt verwendet, sind Race Conditions die erste Fehlerquelle.

eg

Leute das würde ich viel lieber machen, da habe ich auch schon nen (fast) fertiges Modell was LÄUFT aber mein Chef will das unbedingt mit den Umgebungsvariablen haben.

Zum TCPModell kann ich sagen....da kann man ganze Cluster oder eig was man will übertragen.

Also ich spreche das jetzt nochmal mit dem Chef ab, ich sitze jetzt schon seit Tagen an dem Problem und komme daher nicht voran.... das nervt mich langsam (...aber sicher xD).

' schrieb:Leute das würde ich viel lieber machen, da habe ich auch schon nen (fast) fertiges Modell was LÄUFT aber mein Chef will das unbedingt mit den Umgebungsvariablen haben.

Zum TCPModell kann ich sagen....da kann man ganze Cluster oder eig was man will übertragen.

Also ich spreche das jetzt nochmal mit dem Chef ab, ich sitze jetzt schon seit Tagen an dem Problem und komme daher nicht voran.... das nervt mich langsam (...aber sicher xD).

Gute Entscheidung.

eg

P.S. mit SVs kann man auch Cluster übertragen soweit ich weiss, das muss dich aber nicht von deiner Entscheidung ablenken.