IPB

Welcome Guest ( Log In | Register )

 
Reply to this topicStart new topic
> Funktionale globale Variable
eg
post 21. Mar 2007, 15:44
Post #1


new Member
*

Group: Premium Members
Posts: 25
Joined: 19.03.2007
Member No.: 24
LV Version: LV 8.0.1
Zertifizierung: CLAD
LV User seit: 2004



Hallo Leute,

kann mir jemand erklären was an der funktionaler globaler Variable besser ist als an der normalen globalen Variable. Ich, persönlich nutze weder das eine noch das andere, aber trotzdem möchte ich es gerne wissen.

Danke


--------------------
nobody is perfect
Go to the top of the page
 
+Quote Post
CB
post 21. Mar 2007, 20:07
Post #2


proven Member
****

Group: Administrators
Posts: 315
Joined: 16.10.2006
From: Düsseldorf
Member No.: 2
LV Version: current
Zertifizierung: CLA
LV User seit: 2001



QUOTE(labviewer @ 21. Mar 2007, 15:44) [snapback]152[/snapback]
Hallo Leute,

kann mir jemand erklären was an der funktionaler globaler Variable besser ist als an der normalen globalen Variable. Ich, persönlich nutze weder das eine noch das andere, aber trotzdem möchte ich es gerne wissen.

Danke


mit der functional Global (aka "LV2-Style Global" oder "old style Global" -> guckst du hier) kann man s.g. "Race Conditions" vermeiden, weil von der Runtime Engine sichergestellt ist, dass ein VI nur genau einmal im Speicher ist und nur genau einmal zur gleichen Zeit bearbeitet wird. Ausserdem kann man OSGs relativ leicht zur Action Engine aufbohren und damit Konstrukte erzeugen, die eine gewisse Änlichkeit mit C++ Objekten haben, weil man "Methoden" aufrufen kann und die Action Engine die benötigten Variablen ("Members") in sich selbst speichert ...

Auf gut deutsch: mit der Action Engine spart man sich eine Menge Drähte, wenn man sie geschickt programmiert smile.gif


--------------------
künstliche Intelligenz ist besser als natürliche Dummheit!
rotabench:rotierende Prüfstände nach dem Baukasten-Prinzip
Go to the top of the page
 
+Quote Post
eg
post 21. Mar 2007, 23:36
Post #3


new Member
*

Group: Premium Members
Posts: 25
Joined: 19.03.2007
Member No.: 24
LV Version: LV 8.0.1
Zertifizierung: CLAD
LV User seit: 2004



Danke für die ausfühliche Antwort.

Race Conditions ist nicht so eindeutig gut zu verstehen. Also meiner Meinung nach, passiert Race Condition, wenn man nicht weiss in welcher Reihenfolge eine Variable beschrieben oder ausgelesen wird, also der Programmierer und sogar NI Support biggrin.gif nicht weiss wie die Zugriffe passieren, weil es das Betriebssystem nicht eindeutig definiert hat. Man könnte z.B. sagen Schreibzugriff hat höhere Priorität als Lesezugriff, dann muss z.B. die lesende Task solange warten, bis der aktuelle Wert in die Variable von der schreibenden Task reingeschrieben wird. Der Programmierer könnte dann davon ausgehen, dass wenn beide Zugriffe quasi gleichzeitig passieren immer der aktuelle Wert in der Variablen ist. Ich denke, daß die OSG dieses Problem genauso behandelt, wie die "normale" globale Variable auch.
Der einzige Unterschied wäre:
wenn das Betriebssystem nicht sicherstellen könnte, daß ein Schreib- oder Lesezugriff abgebrochen wäre, wenn eine andere Task darauf zugreift, würde die OSG dies nicht zulassen (unter Voraussetzung, daß es nicht reentrant ist, es wäre aber nicht sinnvoll, sonst wäre die quasi lokal). Ich glaube aber, daß auch "normale" globale Variable in dem Sinne auch vernünftig von NI programmiert wurde. Somit würde ich sagen, die SOG hat keinen Unterschied in Bezug auf Race Conditions. Auf die Assemblerprogrammierung könnte man hier auch eingehen, aber es wäre viel zu tief.

Das zweite Vorteil ist wirklich ein Hammer! Man kann also eine funktionale globale Variable so erweitern, daß diese nicht nur eigene Properties(Werte in Form von Variablen), sondern auch eine bestimmte Funktionalität(Methoden) beinhaltet. Man könnte diese Variablen zum einfachen Beispiel global skalieren, auch anzeigen oder gar in eine Datei speichern. Ist es nicht toll? Diese Funktionalität fehlt einer "normalen" globalen Variable. Deshalb ist diese auch funktional.

Trotzdem überzeugt es mich nicht eine davon zu benutzen, ich bin halt ein Multitasking-Freak und benutze die LV-Synchronisationspalette, denn das obengenannte ist mit Polling verbunden, was eine ZUSÄTZLICHE CPU-Auslastung bedeutet.

Labviewer


--------------------
nobody is perfect
Go to the top of the page
 
+Quote Post
CB
post 22. Mar 2007, 07:24
Post #4


proven Member
****

Group: Administrators
Posts: 315
Joined: 16.10.2006
From: Düsseldorf
Member No.: 2
LV Version: current
Zertifizierung: CLA
LV User seit: 2001



QUOTE(labviewer @ 21. Mar 2007, 23:36) [snapback]154[/snapback]
Also meiner Meinung nach, passiert Race Condition, wenn man nicht weiss in welcher Reihenfolge eine Variable beschrieben oder ausgelesen wird, also der Programmierer und sogar NI Support biggrin.gif nicht weiss wie die Zugriffe passieren, weil es das Betriebssystem nicht eindeutig definiert hat.

Das hat zwar nix mit dem Betriebssystem zu tun, sondern nur mit der LV Runtime Engine, aber der Rest stimmt so.


QUOTE(labviewer @ 21. Mar 2007, 23:36) [snapback]154[/snapback]
Das zweite Vorteil ist wirklich ein Hammer! Man kann also eine funktionale globale Variable so erweitern, daß diese nicht nur eigene Properties(Werte in Form von Variablen), sondern auch eine bestimmte Funktionalität(Methoden) beinhaltet. Man könnte diese Variablen zum einfachen Beispiel global skalieren, auch anzeigen oder gar in eine Datei speichern. Ist es nicht toll? Diese Funktionalität fehlt einer "normalen" globalen Variable. Deshalb ist diese auch funktional.

Trotzdem überzeugt es mich nicht eine davon zu benutzen, ich bin halt ein Multitasking-Freak und benutze die LV-Synchronisationspalette, denn das obengenannte ist mit Polling verbunden, was eine ZUSÄTZLICHE CPU-Auslastung bedeutet.


Hast du dir das functional Global Beispiel man angeschaut? Der Vorteil ist, dass dieses eine SubVI alles gespeichert hat, was es zum Funktionieren braucht. In dem Beispiel mit dem DAQmx-Task kannst du das SubVI kreuz und quer irgendwo in deinem Programm verteilen, OHNE dass du z.B. den Task dahin verdrahten musst, das macht die Programmierung sehr übersichtlich. Und Semaphoren kann man sich damit praktisch schenken


--------------------
künstliche Intelligenz ist besser als natürliche Dummheit!
rotabench:rotierende Prüfstände nach dem Baukasten-Prinzip
Go to the top of the page
 
+Quote Post
eg
post 22. Mar 2007, 08:41
Post #5


new Member
*

Group: Premium Members
Posts: 25
Joined: 19.03.2007
Member No.: 24
LV Version: LV 8.0.1
Zertifizierung: CLAD
LV User seit: 2004



QUOTE(CB @ 22. Mar 2007, 07:24) [snapback]157[/snapback]
Das hat zwar nix mit dem Betriebssystem zu tun, sondern nur mit der LV Runtime Engine, aber der Rest stimmt so.


Ich dachte, daß Speicher genauso eine Shared Reccource ist wie z.B. ein Drucker und das Betriebssystem als Layer zwischen dem Runtime und Speicher liegt. Ist es nicht so?

Das mit der Übersichtlichkeit dank OSG stimmt allerdings.


--------------------
nobody is perfect
Go to the top of the page
 
+Quote Post
CB
post 22. Mar 2007, 11:55
Post #6


proven Member
****

Group: Administrators
Posts: 315
Joined: 16.10.2006
From: Düsseldorf
Member No.: 2
LV Version: current
Zertifizierung: CLA
LV User seit: 2001



QUOTE(labviewer @ 22. Mar 2007, 08:41) [snapback]158[/snapback]
Ich dachte, daß Speicher genauso eine Shared Reccource ist wie z.B. ein Drucker und das Betriebssystem als Layer zwischen dem Runtime und Speicher liegt. Ist es nicht so?


ja, das stimmt schon, die OSG hat *erstmal* mit dem OS und dem physischen Speicher nichts zu tun, das regelt alles die LV Runtime Engine, die Reihenfolge lautet also VI --> Runtime Engine --> OS --> phys. Speicher.

Mit dem "ein VI nur einmal im Speicher" meinte ich, dass parallele, nicht reentrante VIs nicht parallel, sondern sequentiell abgearbeitet werden. die LV Runtime Engine entscheidet nach dem Datenfluss, welche der parallelen Instanzen zuerst abgearbeitet wird. Wenn der Datenfluss zu allen VIs die gleiche Priorität ergibt, ist die Ausführung mehr oder weniger zufällig. Beispiel: du verwendest in einer While-Schleife 3 mal das gleiche SubVI, der Datenfluss dahin ist gleich, dann kann man nicht genau sagen, welche der 3 Instanzen zuerst und welche zuletzt abgearbeitet wird.


--------------------
künstliche Intelligenz ist besser als natürliche Dummheit!
rotabench:rotierende Prüfstände nach dem Baukasten-Prinzip
Go to the top of the page
 
+Quote Post
eg
post 23. Mar 2007, 15:57
Post #7


new Member
*

Group: Premium Members
Posts: 25
Joined: 19.03.2007
Member No.: 24
LV Version: LV 8.0.1
Zertifizierung: CLAD
LV User seit: 2004



Kann das sein, dass das ExpressVI vom XY-Plot intern eine SOG nutzt?

Labviewer


--------------------
nobody is perfect
Go to the top of the page
 
+Quote Post
CB
post 23. Mar 2007, 16:41
Post #8


proven Member
****

Group: Administrators
Posts: 315
Joined: 16.10.2006
From: Düsseldorf
Member No.: 2
LV Version: current
Zertifizierung: CLA
LV User seit: 2001



QUOTE(labviewer @ 23. Mar 2007, 15:57) [snapback]162[/snapback]
Kann das sein, dass das ExpressVI vom XY-Plot intern eine SOG nutzt?

Labviewer


nein, der verwendet ganz schnöde ein "Build Array" ...


--------------------
künstliche Intelligenz ist besser als natürliche Dummheit!
rotabench:rotierende Prüfstände nach dem Baukasten-Prinzip
Go to the top of the page
 
+Quote Post
eg
post 24. Mar 2007, 01:08
Post #9


new Member
*

Group: Premium Members
Posts: 25
Joined: 19.03.2007
Member No.: 24
LV Version: LV 8.0.1
Zertifizierung: CLAD
LV User seit: 2004



QUOTE(CB @ 23. Mar 2007, 16:41) [snapback]163[/snapback]
nein, der verwendet ganz schnöde ein "Build Array" ...



Ja, aber dann braucht es doch einen Schieberegister in der Schleife, von der es aufgerufen wird. Ein Build Array ist offensichtlich auch drin, sonst konnten die neuen Daten nicht an die alten angehängt werden, ich habe gemeint zum Puffern.

Labviewer


--------------------
nobody is perfect
Go to the top of the page
 
+Quote Post
CB
post 24. Mar 2007, 09:36
Post #10


proven Member
****

Group: Administrators
Posts: 315
Joined: 16.10.2006
From: Düsseldorf
Member No.: 2
LV Version: current
Zertifizierung: CLA
LV User seit: 2001



QUOTE(labviewer @ 24. Mar 2007, 01:08) [snapback]164[/snapback]
Ja, aber dann braucht es doch einen Schieberegister in der Schleife, von der es aufgerufen wird. Ein Build Array ist offensichtlich auch drin, sonst konnten die neuen Daten nicht an die alten angehängt werden, ich habe gemeint zum Puffern.

Labviewer


jau das stimmt, da hast du recht smile.gif


--------------------
künstliche Intelligenz ist besser als natürliche Dummheit!
rotabench:rotierende Prüfstände nach dem Baukasten-Prinzip
Go to the top of the page
 
+Quote Post
eg
post 26. Mar 2007, 22:21
Post #11


new Member
*

Group: Premium Members
Posts: 25
Joined: 19.03.2007
Member No.: 24
LV Version: LV 8.0.1
Zertifizierung: CLAD
LV User seit: 2004



QUOTE(CB @ 24. Mar 2007, 10:36) [snapback]165[/snapback]
jau das stimmt, da hast du recht smile.gif


Wenn es so ist, dann sieht es für mich schon mal schlimm aus. Es ist schwer nachzuvollziehen was im VI passiert, es entspricht dem Datenflussprinzip nicht mehr. Aus diesem Grund bevorzuge ich andere Möglichkeiten die Daten zu puffern, so kann ich besser das BD verstehen.

Labviewer


--------------------
nobody is perfect
Go to the top of the page
 
+Quote Post
eg
post 26. Mar 2007, 23:10
Post #12


new Member
*

Group: Premium Members
Posts: 25
Joined: 19.03.2007
Member No.: 24
LV Version: LV 8.0.1
Zertifizierung: CLAD
LV User seit: 2004



QUOTE(labviewer @ 22. Mar 2007, 09:41) [snapback]158[/snapback]
Das mit der Übersichtlichkeit dank OSG stimmt allerdings.


QUOTE(labviewer @ 26. Mar 2007, 23:21) [snapback]166[/snapback]
Wenn es so ist, dann sieht es für mich schon mal schlimm aus. Es ist schwer nachzuvollziehen was im VI passiert, es entspricht dem Datenflussprinzip nicht mehr. Aus diesem Grund bevorzuge ich andere Möglichkeiten die Daten zu puffern, so kann ich besser das BD verstehen.



Komisch, da schreibe ich mal so mal anders, ein Widerspruch. Wahrscheinlich kommt es darauf an, wo und wann man es anwendet.

Labviewer


--------------------
nobody is perfect
Go to the top of the page
 
+Quote Post
CB
post 27. Mar 2007, 17:30
Post #13


proven Member
****

Group: Administrators
Posts: 315
Joined: 16.10.2006
From: Düsseldorf
Member No.: 2
LV Version: current
Zertifizierung: CLA
LV User seit: 2001



QUOTE(labviewer @ 26. Mar 2007, 21:21) [snapback]166[/snapback]
Wenn es so ist, dann sieht es für mich schon mal schlimm aus. Es ist schwer nachzuvollziehen was im VI passiert, es entspricht dem Datenflussprinzip nicht mehr. Aus diesem Grund bevorzuge ich andere Möglichkeiten die Daten zu puffern, so kann ich besser das BD verstehen.

Labviewer


eine OSG entspricht absulut dem Datenfluss-Prinzip smile.gif


--------------------
künstliche Intelligenz ist besser als natürliche Dummheit!
rotabench:rotierende Prüfstände nach dem Baukasten-Prinzip
Go to the top of the page
 
+Quote Post
eg
post 27. Mar 2007, 19:57
Post #14


new Member
*

Group: Premium Members
Posts: 25
Joined: 19.03.2007
Member No.: 24
LV Version: LV 8.0.1
Zertifizierung: CLAD
LV User seit: 2004



QUOTE(CB @ 27. Mar 2007, 18:30) [snapback]169[/snapback]
eine OSG entspricht absulut dem Datenfluss-Prinzip smile.gif



Ja, nur dann wenn man weiss, dass im SubVI eine SOG drin ist. Wenn ich aber so eins, wie das ExpressVI vom Extended XY-Plot sehe, dann denke ich da stimmt doch was nicht. Dieses Gefühl bekommt man bei Verwendung von Queues und Notifiers auch, aber wenn man weiss was, wo und wann passiert und man sieht das ganze BD und die Verbindungen, dann ist es OK. Aber wenn es versteckt ist, ist es besonders für Anfänger eine schlechte Schule. Also das Datenflussprinzip ist hier nicht gemeint, wahrscheinlich vielmehr die Übersichtlichkeit des Programms.

Labviewer


--------------------
nobody is perfect
Go to the top of the page
 
+Quote Post
CB
post 27. Mar 2007, 20:29
Post #15


proven Member
****

Group: Administrators
Posts: 315
Joined: 16.10.2006
From: Düsseldorf
Member No.: 2
LV Version: current
Zertifizierung: CLA
LV User seit: 2001



QUOTE(labviewer @ 27. Mar 2007, 18:57) [snapback]170[/snapback]
Ja, nur dann wenn man weiss, dass im SubVI eine SOG drin ist. Wenn ich aber so eins, wie das ExpressVI vom Extended XY-Plot sehe, dann denke ich da stimmt doch was nicht. Dieses Gefühl bekommt man bei Verwendung von Queues und Notifiers auch, aber wenn man weiss was, wo und wann passiert und man sieht das ganze BD und die Verbindungen, dann ist es OK. Aber wenn es versteckt ist, ist es besonders für Anfänger eine schlechte Schule. Also das Datenflussprinzip ist hier nicht gemeint, wahrscheinlich vielmehr die Übersichtlichkeit des Programms.

Labviewer


ja ok, aber das ist - zumindest bei mir - eine Frage der Gewohnheit. Ich hab es mir z.B. angewöhnt alles, was mit Hardware zu tun hat in eine Funktional Global zu stecken ... macht Sinn und hält die SW übersichtlich


--------------------
künstliche Intelligenz ist besser als natürliche Dummheit!
rotabench:rotierende Prüfstände nach dem Baukasten-Prinzip
Go to the top of the page
 
+Quote Post

Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



Lo-Fi Version Time is now: 19.03.2024 - 05:54