Tasking Library

' schrieb:Dieses versagt in jeder anderen Programmiersprache. Man muss den Datentyp entweder global und projektabhängig definieren, oder halt datentypunabhängige Übertragungsmethode verwenden und Datentyp casten.

eben gerade nicht. In C++ funktioniert das wunderbar, sonst könntest du z.B. in LV keinen Anschluss "anything" an einem "Initialize Array" haben und jeden x-beliebigen Datentyp zu einem Array initialisieren.

' schrieb:Ich glaube du verwechselst etwas mit dem Polymorphysmus. Du kannst mit LVOOP ruhig solche überladende Methoden machen und es ist ähnlich oder fast genauso wie polymorphe VIs im nativen LV.

ich stelle nur die Anforderungen, die in z.B. in diesem Schriftstück beschrieben sind. Wenn es nur "geschützte Cluster" sind, warum wurde das Kind dann LVOOP genannt? Warum erstellt man dann Klassen und kann vererben? Ich glaube eher, es soll sehr wohl OOP sein, ist aber halt lange noch nicht fertig.

Ich kenn mich mit der Materie nicht aus, muss aber glaub ich i2dx zustimmen. Die Library an sich ist ne sehr gute Idee, bei mir scheitert die Verwendung jedoch am festgelegten Datentyp String.

Vielleicht liegt der Fehler aber auch bei mir, also frag ich mal: Was ist denn die sinnvollste Möglichkeit, Daten (z.bsp. nen Cluster) in einen String zu wandeln? Klar, eine Möglichkeit wäre, von Anfang an alles auf die Übertragung per String auszulegen. Wenn jedoch das Signal schon besteht (z.Bsp. ein Cluster mit Zeitstempel, nem Array, usw., also allen Möglichen Datentypen) wie kanns denn am besten in nen String und wieder zurück wandeln? Das geht doch nur mittels Variant, oder? Wobei ich dort dann bei Änderung des Clusters wieder den Typenstring ändern muss. Das ist zwar alles möglich, aber halt wesentlich umständlicher als ein Rechtsklick und "Konstante erstellen".

Hoff, man versteht was ich sagen will. Wie gesagt, kenn mich mit der Materie nicht gut aus, habe mich nun zum ersten Mal überhaupt mit Queues beschäftigt . Dacht nur, wenn sich jmd schon so ne Arbeit macht, soll er wenigstens Feedback bekommen.

Gruß

Du kannst mit Flatten To String beliebige Cluster in binäre Strings umwandeln (funktioniert genauso wie Data To Variant). Oder habe ich was falsch verstanden?

Oh mein Gott... keine Ahnung, warum ich da drumrum gewurschtelt hab.
Danke, dann geh ich ma abstimmen :-)

' schrieb:eben gerade nicht. In C++ funktioniert das wunderbar, sonst könntest du z.B. in LV keinen Anschluss "anything" an einem "Initialize Array" haben und jeden x-beliebigen Datentyp zu einem Array initialisieren.

Das ist nicht C++. LabVIEW wurde bis vor ein paar Jahren ausschliesslich in ANSI C programmiert und hatte das seit mindestens Version 2. LabVIEW verwendet oder zumndest verwendete intern ein eigenes Object orientiertes System das in purem C programmiert wurde. Der Code einer Addition z.B. ist so aufgebaut dass er zur Edit/Compilierzeit den Datentyp bestimmt und die entsprechende Methode einbindet.

Das Ganze wurde in alten Zeiten mit Spreadsheets konfiguriert die die verschiedenen Objekte und die entsprechenen Methoden definierten und mit Tools wurde dann daraus der C Code erzeugt, der die enstprechenen Dispatch Tables erzeugt.

Obwohl LabVIEW heutezutage in C++ compiliert wird nehme ich mal an, dass ein grosser Teil dieses alten Codes nach wie vor existiert. Er hat sich bewährt und funktioniert gut. Einziger Vorteil einer Umsetzung in C++ wäre dass der Konfigurationsteil der Dispatchtables vom C++ Compiler vorgenommen würde anstelle von einer (inzwischen wohl auch schon lange nicht mehr handgemachten) Konfigurationstabelle.

Rolf Kalbermatter

' schrieb:Das ist nicht C++. LabVIEW wurde bis vor ein paar Jahren ausschliesslich in ANSI C programmiert und hatte das seit mindestens Version 2. LabVIEW verwendet oder zumndest verwendete intern ein eigenes Object orientiertes System das in purem C programmiert wurde. Der Code einer Addition z.B. ist so aufgebaut dass er zur Edit/Compilierzeit den Datentyp bestimmt und die entsprechende Methode einbindet.

Das Ganze wurde in alten Zeiten mit Spreadsheets konfiguriert die die verschiedenen Objekte und die entsprechenen Methoden definierten und mit Tools wurde dann daraus der C Code erzeugt, der die enstprechenen Dispatch Tables erzeugt.

Obwohl LabVIEW heutezutage in C++ compiliert wird nehme ich mal an, dass ein grosser Teil dieses alten Codes nach wie vor existiert. Er hat sich bewährt und funktioniert gut. Einziger Vorteil einer Umsetzung in C++ wäre dass der Konfigurationsteil der Dispatchtables vom C++ Compiler vorgenommen würde anstelle von einer (inzwischen wohl auch schon lange nicht mehr handgemachten) Konfigurationstabelle.

Rolf Kalbermatter

ok:)das sind jetzt infos die deutlich über meinen horizont hinausgehn:)drum glaub ich das einfach mal ...

' schrieb:Old-Style Globals sind SEHR WOHL Datenfluss-kompatibel:
da für jedes VI gilt (sofern es nicht reentrant ist) dass es nur einmal im Speicher vorhanden ist und "parallele" Aufrufe nacheinander abgearbeitet werden (wodurch die Race Conditions verhindert werden)...

Grundsätzlich stimme ich deinem Posting zu, nur die Aussage mit Old-Style Globals/AE/FGLs und Race Conditions habe ich schon zu oft falsch gehört/gesehen.
Man kann FGL schon so bauen das man damit Race Conditions verhindert/vermindert, allerdings sind gefühlte 80% der eingesetzten FGLs nur hübschere Globale Variablen mit Get/Set Methoden und Error Clustern.

Sry musste bißchen meckern

Gruß
Götz

' schrieb:Grundsätzlich stimme ich deinem Posting zu, nur die Aussage mit Old-Style Globals/AE/FGLs und Race Conditions habe ich schon zu oft falsch gehört/gesehen.
Man kann FGL schon so bauen das man damit Race Conditions verhindert/vermindert, allerdings sind gefühlte 80% der eingesetzten FGLs nur hübschere Globale Variablen mit Get/Set Methoden und Error Clustern.

Wie würdest du das machen?

' schrieb:Wie würdest du das machen?

Je nach Anwendungfalls mglw. recht große AEs die alles wichtige atomar erledigen. Also möglichst keine Abfolgen von Get -> ext. Operation -> Set, sondern falls möglich gleich die Operation intern machen (z.b. Einzelelement eines Datenclusters ersetzen, Listenverwaltung, Berechnungungen wie inkrement usw. oder Mischformen davon). Das dämmt dann zumindest die möglichen Race Conditions ein.
Das Problem der Skalierbarkeit von FGLs bleibt damit allerdings. Ich nehme dafür lieber SingleElementQueues mit entsprechenden Wrapper VIs. Der Aufwand zahlt sich spätestens dann aus, wenn die statischen FGLs nicht mehr reichen und die sie entweder instanziert werden oder sie intern mehrere Datenbereiche verwalten können müssen.

Also ich wüsste nicht, wie man mit FGVs Race Conditions bei parallelen Schleifen vermeiden könnte. Hat jemand ein Beispiel parat? Ok, vielleicht mit einem Flag - "new data available" oder ähnliches, aber dann bleibt ja noch das Problem mit dem Polling. Oder verstehe ich was falsch? Ich bleibe in dem Fall also lieber bei der Sync Palette.