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!
' schrieb:Hänge einfach ein CANopen Close HINTER deine State-Machine, so dass es immer am Ende ausgeführt wird
Naja das ist ja genau das Problem! Wenn irgendein "ungeplanter" (?!) Fehler auftritt, hat man schnell mal "Stop" anstatt "continue" gedrückt, und dann läuft die state machine eben nicht bis zum Ende...
Aber gut...wenn nicht mal die von NI da was wussten...muss ich doch beim Product suggestion center mal posten!
Gruß
Achim
"Is there some mightier sage, of whom we have yet to learn?"
"Opportunity is missed by most people because it is dressed in overalls and looks like work." (Thomas Edison)
Jep, wäre ne gute Sache. Wir haben versucht, die erzeugte Referenz zu speichern und später wieder zu verwenden, um das Close-VI zu füttern, aber das ging nicht... Oder wir waren zu blöd - eins von beiden
Im MAX gibt's dazu auch nix.
Ich habe nur den Vorteil, dass mein Prog auf einem PXI läuft. Muss also nur das neu booten (ca. 20s), nicht den PC. Deswegen hab ich mch dann nicht mehr sooo dran gestört.
Auch wenn ich die CANopen-Kommunikation ordentlich starte und beende kommt es hin und wieder vor, das sich bei der Übergabe von neuen Parametern (hier: neue Drehzahl) die Kommunikation aufhängt. Ich habe den Verdacht, das geschieht wenn die Kommunikation eine Weile inaktiv war, d.h. wenn eine Zeit lang keine Änderung kommt, der Motor/Regler also längere Zeit mit der gleichen Drehzahl läuft, weil keine neuen Einstellungen übergeben werden.
Kann das sein? Muss evtl. ein kontinuierliches "dummy-übergeben" (= pollen) stattfinden, damit da nix schlimmes passiert? Mir ist auch noch nicht so richtig klar, was diese Guard- bzw. Heartbeat-Objekte eigentlich treiben. Benötigt man die, damit die Kommunikation stabil läuft? Was ich in der Hilfe gelesen habe, ist nicht so richtig aussagekräftig. Da steht nur was von Überwachung und Fehlerdetktierung. Was passiert aber, wenn ein Fehler auftritt? Wird dann neu gestartet? Oder übernimmt diese Überwachung evtl. sogar ein evtl. notwendiges "pollen"? Ich hatte das so interpretiert, dass das Synch-Objekt die Kommunikation aufrecht erhält, trotzdem steigt mein Programm desöfteren aus...und das kann auf nem Prüfstand natürlich überhaupt nicht sein...
Gruß
Achim
"Is there some mightier sage, of whom we have yet to learn?"
"Opportunity is missed by most people because it is dressed in overalls and looks like work." (Thomas Edison)
Also zur Klärung der Verwendung der Objekte: Das Heartbeat- bzw. Nodeguard-Objekt (sind nahezu gleich, zumindest in ihrer Verwendung und Nutzung) pingt deinen Controller regelmäßig an. Damit überwachst du die Kommunikationfähigkeit. Wenn z.B. eins dieser Signale nicht mehr am Controller ankommt, sollte dieser den Motor deaktivieren (zumindest tut das meiner). Es könnte ja sein, dein Rechner ist abgestürzt oder das Kabel kaputt und dann hättest du keine Möglichkeit mehr, den Motor zu stoppen. Andererseits kannst du einen Heartbeat-Fehler abfangen und in deinem Programm weiterverarbeiten. Zum Beispiel die Kommunikations abbrechen (CANopen Close), weil du sowieso keine Verbindung mehr hast.
Dieses ganze Verhalten kann man auch abschalten. Dazu sollte es Objekte im Objektverzeichnis deines Controllers geben, mit denen du das Aktivieren oder Deaktivieren kannst. Dann läuft der Controller auch ohne Heartbeats bzw. Nodeguards, allerdings hast du die Sicherheit wesentlich reduziert.
Sync-Objekte machen was anderes. Sie werden ebenfalls in regelmäßigen Abständen geschickt und dienen der Synchronisation des Controllers mit deinem PC. Wenn z.B. eine Nachricht vom Controller eintrifft, dann weißt du, dass sie zum Sync-Puls losgeschickt wurde. Egal, wann sie dann letztendlich eintrifft. Wenn z.B. 5 Controller am Bus hängen und alle gleichzeitig Nachrichten losschicken, kommt die mit der höchsten Priorität (kleinste ID) zuerst an, danach die zweite usw. Und obwohl sie nacheinander ankommen, weißt du, dass sie alle zur gleichen Zeit losgeschickt wurden. Damit kannst du Abläufe mit verschiedenen Motoren synchronisieren. Du kannst zeitgenaue Verläufe plotten. Du kannst...
Aber auch hier wieder: Deine Kommunikation läuft prinzipiell auch ohne Sync-Objekte.
Ein ständiges Pollen ist meiner Meinung nach nicht nötig. Außer natürlich das Pollen mit Heartbeats oder Nodeguards, wenn diese aktiviert sind.
Leider fange ich heute erst an, mein CANopen-Programm zu schreiben, habe also diesbezüglich nur theoretisches Wissen. Aber vielleicht kannst du mal dein VI posten und ich schaue mal drüber, ob mir was auffällt...
' schrieb:Aber vielleicht kannst du mal dein VI posten und ich schaue mal drüber, ob mir was auffällt...
Naja da ist nix anderes drin als auf den Screenshots oben zu sehen ist!
Ich hab mir die Fehlermeldung, die am "häufigsten" kommt, nochmal genauer angesehen, siehe unten:
Ich weiß nicht, wie ich daran was ändern kann?!
Ab und zu krieg ich beim beenden auch Fehlermeldungen, dass das Heartbeat-Objekt nicht existiert...kein Wunder, ich hab auch keins erzeugt! Aber ich versuche ja auch nicht, das Heartbeat-Objekt zu killen, sondern nur Synch, PDO und Interface...
Hast du evtl. noch irgendwelche Tips? Auch ganz allgemeiner Art zum Thema CAN-Karte?
Gruß
Achim
"Is there some mightier sage, of whom we have yet to learn?"
"Opportunity is missed by most people because it is dressed in overalls and looks like work." (Thomas Edison)
14.12.2007, 09:06 (Dieser Beitrag wurde zuletzt bearbeitet: 14.12.2007 09:11 von monoceros84.)
Mmhh, ich hatte diesen Fehler noch nie, arbeite aber auch wie gesagt auf einem PXI und nicht in Windows. Abhilfe könnte vielleicht ein selteneres Senden der PDO's schaffen?! Sync erhöhen?
Ok, was mir an deinenm Bild 1 aufgefallen ist:
Die Zuweisung von NodeID+COB macht LV automatisch, wenn du dort 0 übergibst. Hier können sich also nur Fehler einschleichen... Am besten hier 0 angeben und gut.
Und was ist mit Buffer-Size? Dein Fehler deutet ja auch einen zu kleinen Buffer hin. Schonmal versucht, das hochzusetzen? Nur so eine Idee...
Wenn das nicht hilft: Kann es sein, dein Antrieb die PDOs gar nicht akzeptiert und damit dein Buffer überhaupt nicht leer wird?
Generell: Ich würde den Error als Shift-Register in die äußere Schleife geben... Mit normalen Tunnels liegt sonst am Schleifenbeginn immer "Kein Fehler" an, egal, ob der letzte Status der State-Machine einen Error produziert hat, oder nicht. Vielleicht gehen dir damit schon wichtige Informationen verloren, die jetzt beim Debugging helfen könnten.
Mal noch was ganz anderes: Wenn ich mir anschaue, was ich gestern produziert habe, dann wirkt deine Befehlsübergabe wahnsinnig einfach. Musst du denn den Antrieb gar nicht konfigurieren? Wenn ich z.B. eine Geschwindigkeit fahren will, muss ich erst den Motor in den Velocity-Mode wechseln, dann die Ziel-Geschwindigkeit übergeben, dann den Antrieb freischalten. Für ein Wechseln in den Positionsmodus müsste ich zumindest die Operation disablen, Modus wechseln, neue Ziel-Position übergeben und dann wieder freischalten. Du machst das alles in einem Schritt mit einem einzigen PDO... Wundert mich etwas.
EDIT: Was mir gerade noch auffällt: Versuche mal, alles mit Sync rauszuhauen. Da du sowieso nur einen Antrieb hast und nur Daten in eine Richtung schaufelst, bruachst du ja nichts zu synchronisieren. Vielleicht hilft das ja - Sende-PDOs scheinen nämlich mit Sync nix zu tun zu haben, wie ich gerade entdeckt habe. Dein Sync-Puls ist also völlig nutzlos...
Zitat:Mmhh, ich hatte diesen Fehler noch nie, arbeite aber auch wie gesagt auf einem PXI und nicht in Windows. Abhilfe könnte vielleicht ein selteneres Senden der PDO's schaffen?! Sync erhöhen?
Das PDO wird nur auf Knopfdruck gesendet...ich will ja nur den Modus wechseln (an/aus/positionieren/neue Drehzahl/Drehrichtung). Der Synch wird alle 100ms gesendet, das sollte ja wohl ausreichen, oder?
Zitat:Ok, was mir an deinenm Bild 1 aufgefallen ist:
Die Zuweisung von NodeID+COB macht LV automatisch, wenn du dort 0 übergibst. Hier können sich also nur Fehler einschleichen... Am besten hier 0 angeben und gut.
Und was ist mit Buffer-Size? Dein Fehler deutet ja auch einen zu kleinen Buffer hin. Schonmal versucht, das hochzusetzen? Nur so eine Idee...
Wenn das nicht hilft: Kann es sein, dein Antrieb die PDOs gar nicht akzeptiert und damit dein Buffer überhaupt nicht leer wird?
Ja, das mit der automatischen Zuweisung ist mir klar, irgendwie klappt das aber nicht immer...mit der direkten Angabe funzt es aber! Wenn ich nen BufferSize > 0 angebe hängt sich die LV-Anwendung auf, bzw. dann lässt sich das PDO gar nicht erzeugen.
Zitat:Mal noch was ganz anderes: Wenn ich mir anschaue, was ich gestern produziert habe, dann wirkt deine Befehlsübergabe wahnsinnig einfach. Musst du denn den Antrieb gar nicht konfigurieren? Wenn ich z.B. eine Geschwindigkeit fahren will, muss ich erst den Motor in den Velocity-Mode wechseln, dann die Ziel-Geschwindigkeit übergeben, dann den Antrieb freischalten. Für ein Wechseln in den Positionsmodus müsste ich zumindest die Operation disablen, Modus wechseln, neue Ziel-Position übergeben und dann wieder freischalten. Du machst das alles in einem Schritt mit einem einzigen PDO... Wundert mich etwas.
Die Einfachheit liegt darin begründet, dass die ganze Sache auf dem Regler selber bearbeitet wird. Ich schiebe nur nen Datenblock rüber, in dem der Modus + zugehörige Daten stehen (An/Aus + Rechts/Links + Drehzahl bzw. An/Aus + Positionierung + Winkelangabe). Das wird in einem sogenannten "IPOS"- Programm, das man sich selber stricken kann, ausgewertet! Das ist ne tolle Sache von SEW und funktioniert einwandfrei...das Problem ist der LV-CANopen-Master...
Zitat:EDIT: Was mir gerade noch auffällt: Versuche mal, alles mit Sync rauszuhauen. Da du sowieso nur einen Antrieb hast und nur Daten in eine Richtung schaufelst, bruachst du ja nichts zu synchronisieren. Vielleicht hilft das ja - Sende-PDOs scheinen nämlich mit Sync nix zu tun zu haben, wie ich gerade entdeckt habe. Dein Sync-Puls ist also völlig nutzlos...
Prinzipiell hast du wohl recht, aber da ich dieses IPOS-Programm im Regler anspreche, muss ich doch nen Synch senden, weil das Programm sonst nicht mehr läuft. Das ist hier wohl so ne Art "Watchdog-Funktion"...
Ich suche weiter...
Danke aber schon mal für deine Hilfe!
Gruß
Achim
"Is there some mightier sage, of whom we have yet to learn?"
"Opportunity is missed by most people because it is dressed in overalls and looks like work." (Thomas Edison)
Sync als Watchdog? Würde mich sher wunder, bist du sicher? Genau dafür gibt es nämlich Hartbeat und Nodeguard... Wenn allerdings doch, dann gehen mir auch die Ideen aus, sorry.
Allerdings bin ich auch an einer Lösung interessiert, wenn du was gefunden hast...
' schrieb:Sync als Watchdog? Würde mich sher wunder, bist du sicher? Genau dafür gibt es nämlich Hartbeat und Nodeguard... Wenn allerdings doch, dann gehen mir auch die Ideen aus, sorry.
Allerdings bin ich auch an einer Lösung interessiert, wenn du was gefunden hast...
Sicher bin ich nur darin, dass das IPOS-Reglerprogramm diesen Synch zyklisch erwartet, sonst nimmt es keine neuen Parameter mehr an!
Der Ausdruck "Watchdog" ist in diesem Zusammenhang auf meinem Mist gewachsen!
Und "Guard" und "Heartbeat" sind ja Signale, die vom "Remote Device" kommen, d.h. damit überprüft der CANopen-Master (hier: meine LV-Applikation), ob die angeschlossenen Knoten noch da sind. Das hab ich mir jetzt aber gespart...
A.
"Is there some mightier sage, of whom we have yet to learn?"
"Opportunity is missed by most people because it is dressed in overalls and looks like work." (Thomas Edison)
' schrieb:Und "Guard" und "Heartbeat" sind ja Signale, die vom "Remote Device" kommen, d.h. damit überprüft der CANopen-Master (hier: meine LV-Applikation), ob die angeschlossenen Knoten noch da sind. Das hab ich mir jetzt aber gespart...
Nicht unbedingt. Dein Master sendet ebenso diese Signale aus. Damit schaut sich der Antrieb (meiner zumindest) immer den Status des Masters an. Wenn dieser nix mehr sendet, geht der Antrieb in den QuickStop.
