+- LabVIEWForum.de (https://www.labviewforum.de)
+-- Forum: LabVIEW (/Forum-LabVIEW)
+--- Forum: LabVIEW Allgemein (/Forum-LabVIEW-Allgemein)
+--- Thema: Performance beim Betrieb über WLAN (/Thread-Performance-beim-Betrieb-ueber-WLAN)
Performance beim Betrieb über WLAN - Heber - 15.08.2017 09:03
Hallo Forum,
ich betreibe mein NI-Controller über ein eigenes WLAN (LTE-Stick), da ich mit einer virtuellen Maschine arbeite und mir sonst die Firewall keinen Zugriff gewährt. Der Laptop empfängt das WLAN direkt und der Controller bekommt LAN welches ein Repeater aus dem WLAN erzeugt.
Kann sich dieser Umstand auf die Performance der VI's auf dem Controller auswirken?
Gruß Heber
RE: Performance beim Betrieb über WLAN - GerdW - 15.08.2017 09:17
Hallo Heber,
jein…
Der Controller bzw. dessen CPU (meinst du ein cRIO?) wird genauso schnell arbeiten wie sonst auch.
Wenn du aber in deinen VIs auf Daten wartest, kommt hier natürlich die Zeit für die Netzwerkkommunikation hinzu. Ob die sich jetzt von einem normalen LAN (mit evtl. mehreren Switches mittendrin) unterscheidet, müsstest du selbst prüfen…
RE: Performance beim Betrieb über WLAN - Heber - 15.08.2017 09:25
(15.08.2017 09:17 )GerdW schrieb: Hallo Heber,
jein…
Der Controller bzw. dessen CPU (meinst du ein cRIO?) wird genauso schnell arbeiten wie sonst auch.
Wenn du aber in deinen VIs auf Daten wartest, kommt hier natürlich die Zeit für die Netzwerkkommunikation hinzu. Ob die sich jetzt von einem normalen LAN (mit evtl. mehreren Switches mittendrin) unterscheidet, müsstest du selbst prüfen…
Ich meine kein cRIO sondern ein sbRio mit eigenem RT-Processor.
Und meine VIs laufen auf dem sbRIO, wo ist dann eine Netzwerkkommunikation nötig?
Ich lasse mir ja meine VI visualisieren, das heißt es muss ja eine Kommunikation zwischen Rechner und Controller stattfinden. Wie sieht diese aus?
Ich möchte bzw muss ja eine FPGA-Referenz nutzen. Wenn ich einen Timer in die FPGA Referenz setze von 20 µs, dann könnte ich doch in der RT VI alle 20µs einen Zyklus abarbeiten?!
Aber was hat das mit der Netzwerkkonfiguration zu tun, denn es ist ja eig. eine Kommunikation auf dem sbRIO...
RE: Performance beim Betrieb über WLAN - GerdW - 15.08.2017 09:34
Hallo Heber,
Zitat:Ich meine kein cRIO sondern ein sbRio mit eigenem RT-Processor.Ein sbRIO ist quasi ein cRIO ohne Gehäuse drumherum - die sind ziemlich ähnlich!
Zitat:Und meine VIs laufen auf dem sbRIO, wo ist dann eine Netzwerkkommunikation nötig?Warum fragst du dann nach dem Einfluss einer WLAN-Verbindung?
Ja, die VIs laufen auf dem sbRIO.
Zitat:Ich lasse mir ja meine VI visualisieren, das heißt es muss ja eine Kommunikation zwischen Rechner und Controller stattfinden. Wie sieht diese aus?Wie "visualisierst" du etwas auf einem sbRIO, wenn da überhaupt kein Monitor dran steckt???
Ich nehme an, du arbeitest in der Entwicklungsumgebung und debuggst damit deine VIs. Dann wird natürlich eine Netzwerkverbindung benötigt, damit LabVIEW (bzw. die IDE) schön Daten hin- und herschaufeln kann. Was hat das jetzt mit einem ordnungsgemäßen (!) Einsatz deines sbRIO zu tun?
Zitat:Ich möchte bzw muss ja eine FPGA-Referenz nutzen. Wenn ich einen Timer in die FPGA Referenz setze von 20 µs, dann könnte ich doch in der RT VI alle 20µs einen Zyklus abarbeiten?!Wie setzt man einen "Timer in die FPGA-Referenz"???
Wo genau soll diese Schleife mit 20µs-Takt laufen?
Du musst mal etwas klarer formulieren!
Zitat:Aber was hat das mit der Netzwerkkonfiguration zu tun, denn es ist ja eig. eine Kommunikation auf dem sbRIO...Das kann ich aus deinen spärlichen Informationen heraus nicht beantworten…
RE: Performance beim Betrieb über WLAN - Heber - 17.08.2017 15:15
(15.08.2017 09:34 )GerdW schrieb: Hallo Heber,
Zitat:Ich meine kein cRIO sondern ein sbRio mit eigenem RT-Processor.Ein sbRIO ist quasi ein cRIO ohne Gehäuse drumherum - die sind ziemlich ähnlich!
Zitat:Und meine VIs laufen auf dem sbRIO, wo ist dann eine Netzwerkkommunikation nötig?Warum fragst du dann nach dem Einfluss einer WLAN-Verbindung?
Ja, die VIs laufen auf dem sbRIO.
Zitat:Ich lasse mir ja meine VI visualisieren, das heißt es muss ja eine Kommunikation zwischen Rechner und Controller stattfinden. Wie sieht diese aus?Wie "visualisierst" du etwas auf einem sbRIO, wenn da überhaupt kein Monitor dran steckt???
Ich nehme an, du arbeitest in der Entwicklungsumgebung und debuggst damit deine VIs. Dann wird natürlich eine Netzwerkverbindung benötigt, damit LabVIEW (bzw. die IDE) schön Daten hin- und herschaufeln kann. Was hat das jetzt mit einem ordnungsgemäßen (!) Einsatz deines sbRIO zu tun?
Zitat:Ich möchte bzw muss ja eine FPGA-Referenz nutzen. Wenn ich einen Timer in die FPGA Referenz setze von 20 µs, dann könnte ich doch in der RT VI alle 20µs einen Zyklus abarbeiten?!Wie setzt man einen "Timer in die FPGA-Referenz"???
Wo genau soll diese Schleife mit 20µs-Takt laufen?
Du musst mal etwas klarer formulieren!
Zitat:Aber was hat das mit der Netzwerkkonfiguration zu tun, denn es ist ja eig. eine Kommunikation auf dem sbRIO...Das kann ich aus deinen spärlichen Informationen heraus nicht beantworten…
zu 1: Naja. Ich habe heute Vergelichmessungen mit einem CRIO 9076 und dem sbRIO gemacht, der CRIO hat wesentlich besser gearbeitet. Vor allem was die Messung und die Ausgabe von Analogspannungen angeht. Die Ausgänge des sbRIO waren sehr verrauscht.
allg:
Ich möchte die Maximale Leistung aus dem Board ausnutzen. Bekannter Maßen muss ich den FPGA benutzen. zunächst möchte ich lediglich ein Signal messen, welches vorab gefiltert ist. Der ADU des sbRIO hat eine Abtastrate von 200kS/s, was bedeutet, dass ich alle 5 µs einen Wert verarbeiten kann. Wenn ich nun aber eine Regel- und Simulationschleife benutze, in dieser auf den Analogeingang des Boards zugreife, eine Berechnung durchführe und einen Wert wieder ausgebe, dann werde ich ja eine bestimmte (wie bestimmbar?) Zeit dafür benötigen. Dies hängt sicherlich mit der Komplexität zusammen. Wie schnell kann ich also Werte ausgeben? Ich benutze eine Step-Size von 0,0025s und als Integrationsverfahren Runge-Kutta2 (fixed StepSize).
Zum Ausgang habe ich mal eine Skizze vom Ozsibild angehängt. Beim CRIO war zwar auch ein überlagertes Rauschen zu sehen, aber es war im Rahmen des hinnehmbaren. Beim sbRIO sah es fast eher nach einem quantisierten Signal aus. Wie ist das zu erklären?
RE: Performance beim Betrieb über WLAN - jg - 17.08.2017 15:25
Um welches sbRIO geht es eigentlich?
Gruß, Jens
RE: Performance beim Betrieb über WLAN - Heber - 17.08.2017 15:45
(17.08.2017 15:25 )jg schrieb: Um welches sbRIO geht es eigentlich?
Gruß, Jens
sbRIO:
http://sine.ni.com/nips/cds/view/p/lang/de/nid/205721
CRIO:
http://sine.ni.com/nips/cds/view/p/lang/de/nid/209758
RE: Performance beim Betrieb über WLAN - jg - 17.08.2017 16:28
Kannst du beim sbRIO etwas genauer sein. Das meldet sich doch mit einer bestimmten Bezeichnung im NI-MAX. Ich weiß, dass das früher ein sbRIO-96xx (also mit Power-CPU & VxWorks) eingebaut wurde. Aber ob das immer noch gemacht wird, das geht aus deinem Link nicht hervor. Vielleicht war NI ja so nett und ist auf die neue ARM-Linux Plattform umgestiegen...
Gruß, Jens
(17.08.2017 15:15 )Heber schrieb: Wenn ich nun aber eine Regel- und Simulationschleife benutze, in dieser auf den Analogeingang des Boards zugreife, eine Berechnung durchführe und einen Wert wieder ausgebe, dann werde ich ja eine bestimmte (wie bestimmbar?) Zeit dafür benötigen. Dies hängt sicherlich mit der Komplexität zusammen. Wie schnell kann ich also Werte ausgeben? Ich benutze eine Step-Size von 0,0025s und als Integrationsverfahren Runge-Kutta2 (fixed StepSize).
Das hängt von vielen Punkten ab:
- Wo führst du die Regelung durch? FPGA oder RT. Auf dem FPGA bist du natürlich um Längen schneller, da die Übertragung FPGA->RT->FPGA wegfällt.
- Wie schnell sind die AI und AO?
- Lässt sich deine Regelung für den FPGA kompilieren?
Gruß, Jens
RE: Performance beim Betrieb über WLAN - Heber - 18.08.2017 11:12
(17.08.2017 16:28 )jg schrieb: Kannst du beim sbRIO etwas genauer sein. Das meldet sich doch mit einer bestimmten Bezeichnung im NI-MAX. Ich weiß, dass das früher ein sbRIO-96xx (also mit Power-CPU & VxWorks) eingebaut wurde. Aber ob das immer noch gemacht wird, das geht aus deinem Link nicht hervor. Vielleicht war NI ja so nett und ist auf die neue ARM-Linux Plattform umgestiegen...
Gruß, Jens
(17.08.2017 15:15 )Heber schrieb: Wenn ich nun aber eine Regel- und Simulationschleife benutze, in dieser auf den Analogeingang des Boards zugreife, eine Berechnung durchführe und einen Wert wieder ausgebe, dann werde ich ja eine bestimmte (wie bestimmbar?) Zeit dafür benötigen. Dies hängt sicherlich mit der Komplexität zusammen. Wie schnell kann ich also Werte ausgeben? Ich benutze eine Step-Size von 0,0025s und als Integrationsverfahren Runge-Kutta2 (fixed StepSize).
Das hängt von vielen Punkten ab:
- Wo führst du die Regelung durch? FPGA oder RT. Auf dem FPGA bist du natürlich um Längen schneller, da die Übertragung FPGA->RT->FPGA wegfällt.
- Wie schnell sind die AI und AO?
- Lässt sich deine Regelung für den FPGA kompilieren?
Gruß, Jens
Hallo Jens,
Es ist ein sbRIO-9637. Bei dem Eval-Kit ist halt noch ne zweite Platine fürn Signalgenerator usw enthalten. sbRIO-9637 wird auch im NI-MAX angezeigt.
http://sine.ni.com/nips/cds/view/p/lang/de/nid/213225
Zu den Fragen:
Zur Zeit läuft die Regelung auf dem RT (Regel- und Simulationschleife nur dort nutzbar). Einfache Regelungen können natürlich auch leicht in einer FPGA-VI implementiert werden, Bei komplexeren (Matrizen oder Nichtlinearitäten im nötig) finde zumindest ich es sehr kompliziert (weil die schönen vorgefertigten "Blöcke" wegfallen).
Die AI können mit 200kS/s arbeiten. 16Bit. jeweils +-1, 2, 5 oder 10V einstellbar. Eingangsimpendanz: > 1GOhm mit 100pF parallel wenn powered on ansonsten bei powered off 2,3 kOhm als Minimum.
AO auch 16 Bit Auflösung mit max 336kS/s. Ausgangsimpendanz 0,4 Ohm.
"- Lässt sich deine Regelung für den FPGA kompilieren?"
Was meinst du damit? Kompilieren kann ich sie sofern ich sie wie gewünscht in einer FPGA-VI aufbauen kann.
Gruß Heber
RE: Performance beim Betrieb über WLAN - Heber - 22.08.2017 14:28
Also in den IO Modulen eines cRIO ist schon eine Signalkonditionierung erhalten. Dies könnte der Grund für die Unterschiede sein.