Wenn dein Problem oder deine Frage geklärt worden ist, markiere den Beitrag als "Lösung",
indem du auf den "Lösung" Button rechts unter dem entsprechenden Beitrag klickst. Vielen Dank!
(01.10.2014 21:08 )jg schrieb: EDIT: Wozu ist der Konstruktor "Connector-Types" gut? Wird ohne weiter Verwendung wieder geschlossen.
Das ist VI im blauen Kasten ist HBM-Werk.
Unterm Strich: keine Ahnung! Ich habe es benutzt, viele Probleme damit gehabt... Leider habe ich nicht genug Ahnung, um mir ein VI mit gleicher Funktion selber zu bauen.
Ohne mich dahinter zu verstecken, waren diese QXDAQ reference Bausteine mit eine Ursache dafür, dass ich nicht mehr subVIs gemacht habe... LabVIEW schmiert nämlich regelmäßig ab, wenn man irgendetwas mit ihnen tut... so sowas wie ein Anzeigeelement daraus erstellen oder so...
(01.10.2014 21:09 )GerdW schrieb: Hallo Kurt,
Zitat:Ich bin mir gerade nicht sicher, was genau du meinst...
Vielleicht beantwortet das Bild im Anhang meine Frage... (?)
Nein, tut es nicht!
Da du deine VIs hast löschen lassen, kann ich dir nun leider auch kein Bild mehr anbieten…
Sorry...!
Kannst du es umschreiben?
(01.10.2014 21:09 )GerdW schrieb: Außerdem: Die DeleteArrayElement sollten alle durch ein einzelnes IndexArray ersetzt werden!
Yop, ist im Zuge dessen auch passiert ;-)
Viele Grüße
Matthias
LV2013 SP1 Studentenversion
02.10.2014, 07:37 (Dieser Beitrag wurde zuletzt bearbeitet: 02.10.2014 07:41 von GerdW.)
Zitat:waren diese QXDAQ reference Bausteine mit eine Ursache dafür, dass ich nicht mehr subVIs gemacht habe... LabVIEW schmiert nämlich regelmäßig ab, wenn man irgendetwas mit ihnen tut... so sowas wie ein Anzeigeelement daraus erstellen oder so...
Das mit dem "Abschmieren" kann man aber auch verstehen, wenn du an den Referenzen CoercionDots erzeugst…
Veranschaulichung:
Du hattest Konstrukte, bei denen ein Indicator direkt verdrahtet war, aber zusätzlich noch über eine lokale Variable gesetzt wurde. Wenn dieser Indicator dann noch mit dem ConnectorPane verknüpft wird, wird es doppelt PFUI!
Zitat:waren diese QXDAQ reference Bausteine mit eine Ursache dafür, dass ich nicht mehr subVIs gemacht habe... LabVIEW schmiert nämlich regelmäßig ab, wenn man irgendetwas mit ihnen tut... so sowas wie ein Anzeigeelement daraus erstellen oder so...
Das mit dem "Abschmieren" kann man aber auch verstehen, wenn du an den Referenzen CoercionDots erzeugst…
Veranschaulichung:
Du hattest Konstrukte, bei denen ein Indicator direkt verdrahtet war, aber zusätzlich noch über eine lokale Variable gesetzt wurde. Wenn dieser Indicator dann noch mit dem ConnectorPane verknüpft wird, wird es doppelt PFUI!
Hier ein Video, was genau passiert (Kann das Video nicht hochladen, daher der Link..., Sorry wegen der Quali) und der zugehörige ErrorLog.
Wenn man diesen Ladevorgang abbricht, passiert übrigens nix... er erstellt also das Anzeigeelement und ich kann keinen Nachteil feststellen. Leider geht das manchmal einfach zu schnell!
Code:
####
#Date: Do, 2. Okt 2014 09:25:36
#OSName: Windows 8.1 Pro N
#OSVers: 6.2
#OSBuild: 9200
#AppName: LabVIEW
#Version: 13.0.1f2 32-bit
#AppKind: FDS
#AppModDate: 04/02/2014 12:19 GMT
#LabVIEW Base Address: 0x00400000
starting LabVIEW Execution System 2 Thread 0 , capacity: 24 at [3495079536,83596560, (09:25:36,835965634 2014:10:02)]
starting LabVIEW Execution System 2 Thread 1 , capacity: 24 at [3495079536,83596560, (09:25:36,835965634 2014:10:02)]
starting LabVIEW Execution System 2 Thread 2 , capacity: 24 at [3495079536,83596560, (09:25:36,835965634 2014:10:02)]
starting LabVIEW Execution System 2 Thread 3 , capacity: 24 at [3495079536,83596560, (09:25:36,835965634 2014:10:02)]
<DEBUG_OUTPUT>
02.10.2014 09:27:42.018
Crash 0x00000000: Crash caught by NIER
File Unknown(0) : Crash 0x00000000: Crash caught by NIER
minidump id: 591c91f2-0796-4eac-ade9-86c9ea3d8d85
ExceptionCode: 0xC0000005
Das sieht nach einem Fall für unseren "DLL/ActiveX/andere Windows-Interna"-Spezialisten RolfK aus…
Ich bezog mich auf den CoercionDot in deinem Bild oben. Ist nie wirklich gut, wenn Referenzen von LabVIEW irgendwie coerced werden!
Und warum musst willst du da einen Cluster erstellen?
meinerseits mal ein kleines Update zum Thema.
Ich habe noch ein paar Mails mit HBM getauscht, für Interessierte hier der Verlauf:
ich schrieb:Schade, dass Sie keine Lösung mit LabVIEW parat haben. Auch der angesprochene neue CommonAPI ist für uns keine Alternative, da auch 6ms Zugriffszeit für uns zu lange sind.
Was würden Sie mir da jetzt empfehlen? Geht es mit einer anderen Software schneller? Wenn Sie sich mein Programm grob angeschaut haben, haben Sie ja in etwa eine Ahnung, was unsere Anforderungen sind.
Oder brauchen wir einfach nur eine andere Hardware oder eine andere Schnittstelle?
Würde es nicht vielleicht gehen, dass ich das VI so umbaue, dass eben nicht der Connector jedes mal dem Gerät zugewiesen wird sondern nur einmal zu Beginn? Oder ist das zwingend notwendig?
Rein aus Interesse werde ich mal versuchen, die Messseite des Programms nach Ihrem Vorschlag umzubauen. Ich bin allerdings der Meinung, dass mein Programm genau das nur tut, was Sie sagen – den letzten Messwert liefern. Ich hatte in einer vorherigen Version meines Programms einmal ein anderes VI benutzt (habe die Daten gerade nicht parat), ich habe mich dabei auf das HBM Beispiel-VI QX_ContinuousMeasureTest.vi gestützt. Das war deutlich langsamer (~30ms).
worauf HBM schrieb:Ich habe heute mit unserer Entwicklung gesprochen und wie können leider keine Lösung mit Labview anbieten die schneller als eine Laufzeit von 5-6ms funktioniert.
Das können wir auch mit anderem Hardware oder Schnittstelle nicht realisieren.
Was aber uns eingefallen ist das für eine Anwendung mit 15 Hz (66 ms) sollten theoretisch sogar die 15 ms nicht so kritisch sein.
und ich schrieb:vielen Dank für Ihre Mühe, aber wir werden wohl auf Hardware von National Instruments umsteigen.
15ms Zugriffszeit bei 66ms Schwingungsdauer sind für uns nicht haltbar, der Prozess läuft so viel zu inhomogen.
Oder können wir mit einer anderen Software die nötige Zugriffszeit erreichen?
und HBM schrieb:Sie können testweiser Catman@Easy verwendet : http://www.hbm.com/de/menu/produkte/soft...re/catman/
In mein Test habe ich ein Analog Signal mit einem mx840A gemessen und weiter an mx878 gegeben (ohne Filtern)
Als Verzögerung habe ich hier ca. 2ms gemesen
(mit Catman kann man insgesamt nur messen, soweit ich das richtig überblicken kann)
Insgesamt etwas enttäuschend... :-(
Zur Anwendung mit LabVIEW: ich komme mit deren VIs auch nicht auf 5-6ms (damit könnten wir uns ja vielleicht arrangieren...), sondern auf 15-20ms. Und das geht einfach nicht...
(02.10.2014 09:13 )GerdW schrieb: Das sieht nach einem Fall für unseren "DLL/ActiveX/andere Windows-Interna"-Spezialisten RolfK aus…
Ich bezog mich auf den CoercionDot in deinem Bild oben. Ist nie wirklich gut, wenn Referenzen von LabVIEW irgendwie coerced werden!
Tjaaa.... der CoercionDot ist da... das stimmt. Aber der ist da, sobald ich das von HBM gelieferte VI öffne... ;-)
