Frage

Auf der Oberfläche LabView und Microsoft Robotics Studio erscheinen mir ein sehr ähnliches Programmierparadigma und Umwelt zu haben.

Ist es fair, diese beiden Produkte miteinander zu vergleichen, oder sind sie in verschiedenen Ligen?

Ich bin die Hoffnung, jemand, der beiden Produkte verwendet hat, wird dazu beitragen, vergleichen und sie damit ich verstehen kann, wenn es angebracht ist, das eine oder andere zu verwenden.

War es hilfreich?

Lösung

Disclaimer. Ich habe nicht mit Microsoft Robotics Studio gearbeitet. Ich sah nur die Tatsache Blatt und einen Teil der Dokumentation. Allerdings habe ich viel Wissen von LabVIEW. Also diese Antwort könnte sein (und wahrscheinlich ist) vorgespannt ist.

Die Geschichte weise LabVIEW ist seit 20 Jahren schon und hat folgende Eigenschaften, die MSRS haben nicht (auf den ersten Blick).

  • Plattformunabhängig (LV compiliert auf Windows, Linux, Mac und verschiedene Embedded-Plattformen), aber Hardware-Support variiert je
  • Ein Compiler, direkt in Maschinencode
  • LabVIEW ist eine Programmiersprache nicht in der Robotik targetted sondern ihren Ursprung in Test- und Mess
  • Umfangreiche Mess- und Datenanalyse Unterstützung

Der VPL (MSRS) sieht sehr ungeschickt im Vergleich zu LabVIEW-Code, es sieht aus wie MS wirklich nicht den Schalter auf visuelle Programmierung macht (oder durch Patente von Dritten nicht erlaubt).

Preis wiese, MSRS ist viel freundlicher mit einem kostenlosen ‚Bastler‘ -Version, während eine LabVIEW-Basis um 1300 $ beginnt.

Weitere MSRS nicht auf dem Roboter laufen, steuert nur den Roboter über den Roboter API (Bluetooth oder Kabel), während LabVIEW (und spezifischere NXT-G) auf dem processer innerhalb des Roboters stand-alone laufen.

Was könnte sein, wichtig ist die LabVIEW ist das Hauptsoftwareprodukt von NI während MSRS eines von vielen Produkten von MS ist, so dass die Unterstützung und Entwicklung sollten eine höhere Priorität haben.

Ton

Andere Tipps

Ich habe ausführlich mit MSRDS und in geringerem Maße auch mit LabVIEW programmiert und hier ist meine Meinung. Zuvor hat die meisten unsere Software entwickelt mit LabVIEW, aber in die letzten Jahre haben wir einen großen Teil davon zu C # bewegt worden, weil es viel einfacher zu tun objektorientierte Programmierung unter Verwendung eine Sprache wie C # ist. Ich fühle mich persönlich MSRDS und insbesondere die Concurrency Coordination Runtime (CCR) wird so unterschätzt zum Teil wegen der nicht so detaillierten Dokumentation. Obwohl die MSDN-Foren sind ausgezeichnet, sind wir durch sie erforderlich ist, um die Suche einige der Dinge, um herauszufinden, dass ich ein Teil der Dokumentation haben fühlen. Eine weitere hervorragende Quelle für Informationen zu beziehen ist das Buch "Professional Microsoft Robotics Developer Studio" von Kyle Johns und Trevor Taylor.

Zum Vergleich Kommen wir zurück, ich fühle mich sowohl LabVIEW und MSRDS (obwohl ich bin mir nicht sicher über LabVIEW Robotics) verschiedene Programmiermethoden folgen. Obwohl es in der Robotik gezielt wurde, wird MSRDS zu Gurtzeug asynchronem Verhalten in jeder Anwendung verwendet. CCR hat einige ausgezeichnete Koordination Primitive (wie Verbindungen und Zwischenblätter), und es macht die asynchrone Programmierung viel einfacher. DSS verwendet serviceorientierte Anwendungen zu entwickeln, die in der gleichen Maschine oder auf verschiedenen Maschinen über mehrere Knoten verteilt sind, befinden. Wir entwickelten einen Rahmen für die Entwicklung von Laborautomationssysteme mit MSRDS. Der Rahmen wird verwendet, um verteilte komponentenbasierte Software zu entwickeln, die sowohl Thread-sicher und reaktionsschnell ist.

Es ist auch erwähnenswert, dass Task Parallel Library-Daten in .NET-Flow 4.5 ist auf die CCR-Konzepte basieren und auch die Konzepte von .NET RX. Ich schlage vor, Sie bei ihnen betrachten suchen auch.

Danke,

Venkat

Ich denke, Ton traf es auf die Nase, aber es gibt ein paar wichtige Punkte Ich bin nicht einverstanden auf.

Unabhängig von Preis LabView ist ein weit überlegenes System für Automatisierungs- und Embedded-Programmierung. die Bank ein paar Mal brechen über Allerdings gibt es die Klinke dass LabView ohne Lizenz. Je nach Ihrer Zielplattform, könnte man leicht verbringen mehrere tausend Dollar für eine Entwicklungsumgebung.

Beide Systeme haben einen Compiler. Für eine Weile LabView auf nur wenige Embedded-Umgebungen beschränkt war, aber mit dem Zusatz eines ARM-Compiler gibt es nun eine große Anzahl der unterstützten Hardware-Systeme. LabView wird in Echtzeit, wie Sie Programm kompiliert wird SDB auf Anfrage zusammengestellt (soweit ich weiß).

LabView ist absolut Robotik ausgerichtet. NI hat eine Menge von Werkzeugen für Roboteranwendungen hervorbringen und viele der von der Automatisierung genommen Ideen Einstellung rechts in die Robotertechnik fallen gelassen werden. Als interessante Notiz verwendet der FIRST Robotics Competition ausschließlich NI-Hardware (die cRIO) und LabView ist eine beliebte Programmieroption.

Die RDS visuelle Programmierung und visuelle Programmierung des LabView ist nicht wirklich vergleichbar. Sie arbeiten nicht mit den gleichen Paradigmen.

RDS schafft Maschinencode und der Code kann auf einem Roboter ohne Eingriff läuft.

Wenn Sie schauen, um ein komplettes Robotersystem für die Entwicklung mit LabView kaufen Diese Seite finden Sie unter: http://www.ni.com/robotics/how_to_buy.htm

So wie ein wenig Hintergrund, bin ich ein zertifizierter LabView-Entwickler und habe RDS mit dem lego NXT-System als Ausbilder eingesetzt.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top