INFO: Dieses Forum nutzt Cookies...
Cookies sind für den Betrieb des Forums unverzichtbar. Mit der Nutzung des Forums erklärst Du dich damit einverstanden, dass wir Cookies verwenden.

Es wird in jedem Fall ein Cookie gesetzt um diesen Hinweis nicht mehr zu erhalten. Desweiteren setzen wir Google Adsense und Google Analytics ein.


Antwort schreiben 

Dieses Thema hat akzeptierte Lösungen:

Entwicklungsumgebung beeinflusst cDAQ in Runtime



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!

06.09.2016, 14:17
Beitrag #1

Nordvestlys Offline
LVF-Gelegenheitsschreiber
**


Beiträge: 108
Registriert seit: Sep 2014

2015 (und testweise 2016)
2005
EN

07743
Deutschland
Entwicklungsumgebung beeinflusst cDAQ in Runtime
Moin,

ich habe gestern ein etwas "spukiges" Verhalten auf einem Laborrechner festgestellt. Eine genauere Analyse steht noch aus, aber vielleicht hat ja schonmal jemand einen Tipp, woran es liegen könnte.

Was bisher geschah.....:

LV2015 Entwicklungsumgebung + Projekt + Runtimeumgebung + .exe machen im wesentlichen das was sie sollen: Etwas DB-Kommunikation, ein paar Messungen, cDAQ per Ethernet als Multi-I/O.

Bei ersten Tests mit LV2016 funktioniert die exe nur dann richtig, wenn vorher nicht die Entwicklungsumgebung offen war. Sobald das Projekt geöffnet war (auch ohne öffnen/ausführen von VIs), läuft die exe sehr "hakelig". Zumindest etliche Funktionen die übers cDAQ laufen werden verzögert oder gar nicht ausgeführt.
Natürlich kann die Ursache auch an ganz anderer Stelle liegen, aaaber:
Sobald ich einmal den "Automation-Explorer" (MAX) öffne und wieder schließe, funktioniert die exe wieder ordentlich. Solange bis die Enwicklungsumgebung mal wieder geöffnet wurde.

Mit diesem Würgaround kann ich zu LV2016-Testzwecken leben. Aber die Ursache würde ich dennoch gerne rausfinden und beheben.

=> Irgendwelche Ideen?


PS: (Projekt ist etwas größer und recht komplex. Sollte ich keine "allgemeine" Ursache finden, bleibt es erstmal bei LV2015.)
PPS: VISA, DAQ-Treiber sind ebenfalls kürzlich aktualisiert worden.

bis denne,
* mario *
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
Anzeige
28.09.2016, 06:23
Beitrag #2

Nordvestlys Offline
LVF-Gelegenheitsschreiber
**


Beiträge: 108
Registriert seit: Sep 2014

2015 (und testweise 2016)
2005
EN

07743
Deutschland
RE: Entwicklungsumgebung beeinflusst cDAQ in Runtime
kleines Update: Eine richtige Ursache oder Lösung habe ich noch nicht gefunden. Aber es scheint, dass der vermeintliche Zusammenhang mit Entwicklungsumgebung und Max nicht zwingend ist. Irgendeine Korrelation besteht da wohl, aber nicht 1:1. Der Fehler tritt auch unter anderen Bedingungen auf.

Meine Log-Files (wo leider nicht alle Fehlermeldungen landen) lassen vermuten, dass die Verbindung zum Chassis per Ethernet (einziges Gerät an der Netzwerkkarte) manchmal nicht korrekt aufgebaut wird.

Für Hinweise ob sich in diesem Bereich beim Versionswechsel 2016 was getan hat, bin ich weiter offen. Sonst werde ich wohl erstmal die DAQmx-Treiber nochmal neu installieren.

bis denne,
* mario *
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
12.10.2016, 13:06
Beitrag #3

Nordvestlys Offline
LVF-Gelegenheitsschreiber
**


Beiträge: 108
Registriert seit: Sep 2014

2015 (und testweise 2016)
2005
EN

07743
Deutschland
RE: Entwicklungsumgebung beeinflusst cDAQ in Runtime

Akzeptierte Lösung

sodele, echte Ursache ist immer noch unklar. Aber folgende Maßnahmen haben zum Erfolg geführt. Vielleicht hilft es ja in Zukunft irgendwem.

- Alle "NI-Altlasten" (alte LV-Versionen etc.) deinstalliert
- Bei den mutmaßlich relevanten NI-Paketen (DAQ, VISA, LV) eine Reparaturinstallation durchgeführt.
- Bei Windows die automatische Suche nach Updates für Hardwaretreibern abgeschaltet.

Der letzte Punkt ist mir dadurch aufgefallen, dass nach Neustart erstmal eine Treiber-Such-Meldung für alle cDAQ-Module aufgepoppt ist. Evtl. war das auch der Grund dass sporadisch die Komunikation mit diesen Geräten gehakelt hat.

Bis jetzt scheint alles zu funktionieren, egal in welcher Reihenfolge irgendwas gestartet und beendet wird. Hoffentlich bleibt das auch dauerhaft so :-)

bis denne,
* mario *
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
Antwort schreiben 


Möglicherweise verwandte Themen...
Themen Verfasser Antworten Views Letzter Beitrag
  Probleme NI cDAQ-9172 Vision_Michl 5 1.439 15.02.2020 13:48
Letzter Beitrag: BNT
  cDAQ und DAQ Gerätetemperatur auslesen. erzengelsamael 7 2.778 22.10.2018 10:42
Letzter Beitrag: erzengelsamael
  Automatische Erkennung von cDAQ Modulen zt300 4 2.580 09.01.2018 07:38
Letzter Beitrag: zt300
  Komplexes Programm mit cDAQ MR_Engineer 5 2.215 16.03.2017 08:15
Letzter Beitrag: jg
Question Herausfinden ob cDAQ in Benutzung achim @ FZK 2 2.348 21.02.2017 08:36
Letzter Beitrag: achim @ FZK
  Datenarry aus den cDaq-Messdaten abgreifen Majuler 15 4.451 27.09.2016 15:49
Letzter Beitrag: Majuler

Gehe zu: