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!
ich habe schon einige LabView Erfahrung bin aber noch ziemlich neu in Sachen RT, FPGA, XNET, CAN...
Jetzt soll ich über über ein cRIO mit CAN-Modul (9862) Netzgeräte ansprechen, Sollwerte von Spannungen
setzen und die Istwerte (U, I) auslesen. Leider hat das Modul keine Ünterstützung der NI CANopen Library,
aber ich konnte schon erste kleine Erfolge erzielen und Frames rausschicken bzw. empfangen:
a) habe die Bootup Nachricht des Netzgeräts auslesen
b) konnte auf den Netzwerkmanagementdienst NMT des Knotes zugreifen und ihn starten, stoppen und resetten
Zu meinem Programm,
es wird (gemächlich) in einer Timed While Loop auf dem cRio RT ausgeführt . Wenn ich die Taste "Start Transciever" drücke wird eine Sequenz durchlaufen in der ich zuerst ein Frame auf den Bus schicke und anschließend ein Frame vom Bus lesen möchte. Das senden ist optional, d.h. es wird nur ein Frame gesendet wenn ich die Taste "auch senden" drücke. Das habe ich zum Beispiel benutzt um die Bootup Nachricht des Netzgeräts auszulesen.
Mein Problem nun ist, dass ich einen Time Out bekomme und ich kein Frame empfange wenn ich
ein SDO Objekt auffordere, mir seinen Wert zu senden. Hat jemand vielleicht eine Idee was in
meinem VI nicht stimmt?
Leider finde ich keine geeigneten Beispiele wie ein VI zur Kommunikation unter XNET und CANopen
aussehen sollte.
Du solltest die beiden Sessions fürs Senden und Empfangen öffnen und erst dann senden. Am besten wärs, du öffnest bei Sessions, gehst dann in deine timed loop, sendest und empfängst beliebig lang und viel, und schließt die Sessions erst nach verlassen der timed loop.
Evtl. ist die Antwort schon da, bevor du die Session zum lesen geöffnet hast. Der Frame wird in diesem Fall verworfen.
es ist genauso wie du sagt,
ich wusste nicht, dass man gleichzeitig eine Session zum schreiben und lesen erzeugen kann.
Ausserdem reicht es natürlich, die Sessions einmalig zu initialisieren. Jetzt klappts so
wie gewünscht!
ich habe auch die NI9862 CAN Hardware im Einsatz und möchte folgendes machen:
1.) CANopen Protokoll: Teilnehmer in den preoperational Zustand bekommen
2.) CANopen Protokoll: und danach die manufactory name auslesen (CANopen ID 0x1008)
habt ihr hierfür ein einfaches Beispiel zum starten?
CANopen libraries werden ja mit der 9862 nicht unterstützt, die CAN Frames müssen also händisch
nachgebildet werden.
ich habe ein ähnliches Problem wenn gleich etwas anders gelagert.. wir nutzten auch eine 9862 jedoch in einem cDAQ. Wir hatten bisher jedoch noch nicht das Glück auch nur irgendeine Nachricht mit unserem canOpen Gerät (Frequenzumrichter der Firma Stoeber, TYP MDS 5000) auszutauschen, geschweige den es in das Operational setzten zu können. Uns stellt sich nun die Frage, ob es überhaupt möglich ist. Die letzten Beiträge lassen jedoch vermuten das gfzk die Anwendung hat umsetzten können. Wir haben bereits eine Logik die uns unsere Frames zusammenstellt und die entsprechenden Daten unterbringt.. nur scheitern wir gerade an der NMT message und dem auslesen der Bootup Nachricht. Könnte jemand ggf kurz schildern wie sie die erste Kommunikation realisert haben? Also was gesendet wurde?
meine Anwendung läuft seit damals erfolgreich, sie steuert zehn Netzteile indem sie eine Sollspannung vorgibt und dann die Istwerte zusammen mit dem Statusregister ausliest. Du findest ein Beispielprogramm im Anhang, allerdings habe ich es auf einem cRio getestet. Grundsätzlich arbeitet das NI9862 mit einem cDAQ zusammen, allerdings gibt es auch hier Ausnahmen: Kompatibilität
Vielleicht ist dir hiermit schon geholfen, wenn nicht poste mal Deinen Code. Zwar haben die Wenigsten hier dieses Modul, aber vielleicht besteht ja ein grundsätzliches Problem bei der Implementierung.
vielen Dank erstmal für die Antwort. Es hilft mal einen Einblick zu bekommen und zeigt das wir mit unserer bisherigen Struktur garnicht so falsch liegen. Was ich diesem Project aber bisher nicht entnehmen konnte, wie wird die NMT Message für das Umschalten des Nodes in den Operational gesendet?
Grüße aus dem Ruhrgebiet,
Daniel
Als Anhang mal unseren Payload generator... weil bei uns noch nicht genau klar ist welche Parameter wir wann an welcher Stelle nocheinmal ändern wollen.
18.07.2014, 13:33 (Dieser Beitrag wurde zuletzt bearbeitet: 18.07.2014 13:34 von Krusevvp.)
Das Blockdiagram mit dem Wir senden sieht wie folgt aus: da haben wir auch versucht eine NMT in Form einer Konstante unter zu bringen. Leider haben wir noch nicht einen Muchs aus dem Bus gehört und bisher auch keine Reaktion der Busteilnehmer (status LED für Node Zustand) provozieren können.
(eigentlich wollte ich den vorangehenden Beitrag editieren, aber das ging leider nicht mehr)
habt ihr das Modul so verdrahtet wie in der Anleitung beschrieben, mit externer Spannungsquelle und Terminierung?
Wenn ich mich recht entsinne zeigt die linke LED an, ob das Modul Spannung hat, und die Rechte blinkt wenn Kommunikation auf dem Bus ist.
Da ich mir anfangs nicht sicher war, ob überhaupt etwas über den Bus geschickt wird, habe ich die Kommunikation mittels eines Speicheroszilloksop überwacht.
Leider kenne ich mich mit der OpenCan Materie nicht sehr aus, ich habe das Netzgerät zusammen mit dem freundlichen Support des Herstellers zum laufen gebracht. Der Zugriff erfolgt ausschließlich über den SDO Dienst, d.h. Sollwert vorgeben, Output aktivieren, Istwerte lesen. Standardmäßig ist das Gerät nach dem Einschalten im Pre-Operational Modus laut Handbuch Seite 57, in diesem ist NMT ebenfalls möglich.
Wie gesagt, NMT bzw. PDO Modus habe ich nie benutzt da alles super auch mit SDO funktioniert hat.
Interessant wäre weiterhin ob der Eigenschaftsknoten (XNET Session - ###Baudrate) vielleicht noch einen Fehler anzeigt.
Gruß,
Georg
21.07.2014, 09:46 (Dieser Beitrag wurde zuletzt bearbeitet: 21.07.2014 09:51 von Krusevvp.)
die Verdrahtung haben wir überprüft, mittlerweile haben wir vom NI Service aber auch die Bestätigung, dass das 9862 für CANopen nicht Masterfähig ist. Ich werde jedoch mal mit dem Hersteller unsere endgerätes klären ob wir auch eine SDO Kommunikation realisieren können.
Fehler werden in diesem Betriebsmodus auch nicht angezeigt, durch einstellen auf Single Point Frames kann man dann Fehler provozieren.. aber das ist ja nicht Sinn der Sache. :-)
vielen Dank für die bisherigen Hinweise, es hat sehr geholfen die Situation nun besser zu verstehen. Wir werden ggf. auch mal mit einem Osziloskop einen Blick auf den Bus werfen, zwar liefert NI auch einen BUS Monitor mit, dieser sagt in unserem Fall jedoch auch keinen Mucks.
