LabVIEWForum.de

Hallo Jenni,

Zitat:Ich habe gedacht, dass ich eine Kommunikationsschnittstelle von PC zu SMU habe und anschließend über TSP-Link via "daisy chain" einfacher erweitern kann.
Ich hätte dann nur 1 Visa Resource Name und verbinde anschließend in LabVIEW alle nötigen Treiber einfach "in Reihenschaltung", ohne das ich ein Node oder ähnlichen angeben müsste. (Ich hoffe das ist verständlich was ich meine)

Ich will dich nicht ärgern, aber es gibt einen Unterschied zwischen "denken" und "nachdenken"…
Nur mal so ein Beispiel: du willst also an alle deine DaisyChain-verbundenen Geräte z.B. einen QueryID-Befehl schicken, dabei keine NodeID angeben - und trotzdem von genau einem richtigen Gerät die passende Antwort erhalten? Und du willst weiterhin Befehle dafür verwenden, die für die direkte Kommunikation (per VCP, GPIB, LAN) im SCPI-Standard ausgelegt sind???

Ja, der DaisyChain-Gedanke ist schön, erfordert aber eben auch eine andere Programmierung - so wie es im Manual beschrieben wird!

Zitat:Wenn ich beispielsweise LAN nutze als Kommunikationsschnittstelle (ich entschuldige mich jetzt schon für diese Frage) verstehe ich es richtig, dass ich für jedes Gerät einzeln von meinem PC zum Device ein eigenes Kabel benötige ?

Ich habe jetzt nicht nachgelesen, ob darüber genauso SCPI-Kommandos unterstützt werden: musst du mal das Manual lesen.
Ansonsten bekommt natürlich jedes Gerät im LAN-Netzwerk sein eigenes Kabel - die dann aber alle über einen Switch (sternförmig) verbunden sind. Ich empfehle ein lokales Netzwerk nur für die Messgeräte im Prüfstandsaufbau. Der SteuerPC darf gern über einen zweiten LAN-Port mit dem Firmennetzwerk verbunden werden…

Bisherige allgemeine Antwort auf alle deine Fragen:

(06.05.2020 09:29 )GerdW schrieb: [ -> ]Hallo Jenni,


Ich will dich nicht ärgern, aber es gibt einen Unterschied zwischen "denken" und "nachdenken"…

lol..

Zitat:Nur mal so ein Beispiel: du willst also an alle deine DaisyChain-verbundenen Geräte z.B. einen QueryID-Befehl schicken, dabei keine NodeID angeben - und trotzdem von genau einem richtigen Gerät die passende Antwort erhalten? Und du willst weiterhin Befehle dafür verwenden, die für die direkte Kommunikation (per VCP, GPIB, LAN) im SCPI-Standard ausgelegt sind???

Ja, der DaisyChain-Gedanke ist schön, erfordert aber eben auch eine andere Programmierung - so wie es im Manual beschrieben wird!

Ja genau, mir ist bewusst das ich dann auch mehr Adressen bzw Nodes brauche um auch mitzuteilen für wen der Befehl ist. Allerdings bestand auch die Annahme, dass das SMU einen Befehl einliest -> sieht es ist nicht die richtige Adresse und einfach an den nächsten Teilnehmer gibt. Ich finde das ist eine berechtigte Annahme, wenn man schon Treiber anbietet.
Wo im Manuel finde ich diese Programmierung für meinen Anwendungsfall? (LabVIEW!!!)

Zitat:Ich habe jetzt nicht nachgelesen, ob darüber genauso SCPI-Kommandos unterstützt werden: musst du mal das Manual lesen.
Ansonsten bekommt natürlich jedes Gerät im LAN-Netzwerk sein eigenes Kabel - die dann aber alle über einen Switch (sternförmig) verbunden sind. Ich empfehle ein lokales Netzwerk nur für die Messgeräte im Prüfstandsaufbau. Der SteuerPC darf gern über einen zweiten LAN-Port mit dem Firmennetzwerk verbunden werden…

Danke für deine Empfehlungen. Aufgrund deiner Erfahrung nehme ich das sehr gerne an

Zitat:Bisherige allgemeine Antwort auf alle deine Fragen:

Auf die Idee das die Treiber zu alt sind und kein TSP-Link unterstützen wäre ich nicht gekommen. Und auch das Manual nicht
Hätte ich das Manuel verstanden, hätte ich nicht gefragt
Sorry, ich bin neu auf dem Gebiet.

Hallo Jenni,

Zitat:Allerdings bestand auch die Annahme, dass das SMU einen Befehl einliest -> sieht es ist nicht die richtige Adresse und einfach an den nächsten Teilnehmer gibt.

Wieso sollte ein Gerät so etwas machen?
Üblicherweise funktioniert das so, das alle Geräte einen Befehl empfangen und gucken, ob sie angesprochen werden. Wenn nicht, dann eben nicht auf den Befehl reagieren und auf den nächsten warten. Kenne ich so von CAN, CANopen, Modbus, GPIB - eben wo viele Geräte an einem Bus hängen…

Zitat:Ich finde das ist eine berechtigte Annahme, wenn man schon Treiber anbietet.

Ich finde diese Annahme unberechtigt: die Treiber sind für SCPI-Kommunikation mit einem einzelnen Gerätetyp ausgelegt - und haben überhaupt nichts mit TSP-Link am Hut!

Zitat:Auf die Idee das die Treiber zu alt sind und kein TSP-Link unterstützen wäre ich nicht gekommen.

Ich habe gerade mal im IDNet (http://www.ni.com/idnet) nachgeschaut: Es gibt dort Treiber für Keithley2400-2440. Der für das K2440 datiert von ursprünglich 2006: wie kommst du darauf, dass der nicht alt wäre?

Zitat:Wo im Manuel finde ich diese Programmierung für meinen Anwendungsfall? (LabVIEW!!!)

Ich habe im Keithley2450-Manual ein ganzes Kapitel zu TSP gesehen, musst du mal lesen.
Wenn du mit dem vorhanden Treiber unzufrieden bist, müsstest du den Anbieter (Keithley!) fragen. Keithley wiederum ist eine Firma, die nichts mit NI direkt zu tun hat - und für ihre TSP-Geschichte eben nicht LabVIEW verwendet, sondern LUA (Manual lesen!). Welchen Anreiz hätte Keithley, quasi nur für dich einen LabVIEW-Treiber zur Nutzung von TSP(-Link) zu erstellen (Kosten!!!), wenn sie jetzt schon ihre eigene Programmierumgebung (TSB, siehe Manual!) anbieten!?

Also:
Option 1: Sich beim Hersteller beschweren und ewig auf Support warten.
Option 2: Sich für TSP-Link alles selbst in LabVIEW programmieren, dazu Manuals lesen und evtl. den Keithley-Support nerven (mit wenig Aussicht auf viel Hilfe).
Option 3: Auf TSP-Link verzichten, jedes Gerät direkt mit dem PC verbinden und die fertigen Gerätetreiber verwenden. (Evtl. etwas Aufwand, um diese auf den von dir gewünschten Qualitätsstandard zu bringen.)

Such dir was aus!

Zitat:Ich habe gerade mal im IDNet (http://www.ni.com/idnet) nachgeschaut: Es gibt dort Treiber für Keithley2400-2440. Der für das K2440 datiert von ursprünglich 2006: wie kommst du darauf, dass der nicht alt wäre?

Ich interagiere mit dem 2450. Diese Treiber sind von 2015. Klar immer noch alt ,aber zu alt?

Zitat:Option 1: Sich beim Hersteller beschweren und ewig auf Support warten.
Option 2: Sich für TSP-Link alles selbst in LabVIEW programmieren, dazu Manuals lesen und evtl. den Keithley-Support nerven (mit wenig Aussicht auf viel Hilfe).
Option 3: Auf TSP-Link verzichten, jedes Gerät direkt mit dem PC verbinden und die fertigen Gerätetreiber verwenden. (Evtl. etwas Aufwand, um diese auf den von dir gewünschten Qualitätsstandard zu bringen.)

Such dir was aus!

Ich habe jetzt eine State-Machine entworfen und nutze zwei separate USB-Ports.
Auf Antworten von Keithley wartet man leider vergebens. Bis da eine qualitative Antwort kommt bin ich alt und grau.

Danke in jedem Fall nochmal für deine hilfreichen Antworten und vor allem für die Zeit die du dir genommen hast.