Hallo zusammen,
ich bin gerade dabei CAN-Daten zu erfassen. Jedoch scheitere ich an der Konfiguration der VIs. Ich möchte CAN Daten erfassen von einer bestimmten ID. Dazu habe ich die CAN Channel API gewählt. Die Beispiele von NI helfen mir leider nicht wirklich weiter, da die Einstellungen aus einer Konfigurationsdatei kommen. Hab auch schon versucht über den MAX Explorer diese Datei zu erzeugen jedoch hats nicht funktioniert. Letzt endlich gibt es ja die Möglichkeit die Messages auch programmatisch zu erstellen. Im Anhang habe ich ein ganz stupides VI. Vielleicht kann mir jemand helfen und sagen was falsch ist. Mittels der VIs aus der Palette Frame API funktioniert alles. Jedoch möchte ich die Channel API testen. Ich habe ein CAN Spy Gerät welches mit einer bestimmten ID zyklisch Daten sendet mit einer Baudrate von 250kB.
Hardware habe ich ein PXI 1042Q, CAN Karte 8464, Controller 8106 mit RT.
Das ganze läuft unter
Danke Gruß Johannes[
attachment=32541]
Ok hat sich denke ich erledigt. Ich musste noch die Baudrate einstellen. Die Einstellung hab ich zuerst nicht gefunden...
Ich weiß nicht was ein "CAN Spy Gerät" ist, aber prinzipiell machst du hier nichts falsch. Außer natürlich, dein Gerät wäre virtueller Natur, denn dann müsstest du Port 256 oder 257 wählen. Wenn meine Wahl auf die ChannelAPI fällt, dann erzeuge ich entweder Nachrichten im MAX oder importiere diese von einer dbc-Datei. Anschließend exportiere ich die Nachrichtenliste als *.ncd. Der ChannelAPI kann ich nun entweder sagen, welche Nachrichten aus der aktuellen MAX-Einstellung (CAN Channels) benutzen will, oder ich übergebe der API den Pfad auf eine ncd-Datei, in der ähnlich einer dbc-Datei die Nachrichten und Signal beschrieben sind. Der physikalische Kanal muss natürlich stimmen. Programmatisch habe ich noch nie Signalen erstellt. Warum auch, schließlich gibts dbc-Dateien.
Import einer dbc-Datei. Nach dem Kontextmenü öffnet sich ein Dialog, in dem die zu importierenden Nachrichten ausgewählt werden müssen.
[
attachment=32545]
Erzeugen einer Nachricht im MAX.
[
attachment=32546]
Erzeugen eines Signals (in LV-Sprech Kanal oder Channel).
[
attachment=32548]
Exportieren der Nachrichtenliste in eine ncd-Datei, welche von der Channel-API geöffnet werden kann.
[
attachment=32547]
Zwei Varianten, die Channel-API zu starten.
[
attachment=32549]
Erstmal Danke. Ich werde mir das Erstellen von Nachrichten nochmal anschauen. Nebenbei, ein CAN SPY ist ein Gerät mit dem man CAN Nachrichten erzgeugen / erfassen kann.
Ich versuch mal mein eigentliches Problem zu schildern.
Ich habe eine Art Datenlogger, der unter anderem AI und CAN Nachrichten erfasst. Jedoch soll auswählbar sein welche IDs betrachtet werden sollen; also dynamisch. Ich hab jedoch festgestellt, wenn ich die CAN Daten mittels Frame API Net erfasse, wandert der Zeitstempel. Ich schicke beispielsweise alle 50ms eine CAN Nachricht (via CAN SPY), dann müsste ich theoretisch einen Zeitstempel 0.050,0.100,0.150 usw haben. Jedoch wandert die letzte Stelle ca alle 5 Sekunden um 1ms hoch. Wird jetzt länger gemessen, so stimmt der Zeitstempel nicht mehr. Ich möchte also irgendwie synchron zu den AI meine CAN Daten lesen. Aber wie gesagt unterschiedliche IDs. Mittels der Channel API hab ich gesehen, dass man auch eine Abtastrate bei der CAN Erfassung einstellen kann. Ob ich jedoch so zu einem zufriedenstellenden Ergebnis komme weiß ich nicht.
Vielleicht hat jemand eine andere Lösung die mir weiterhilft.
Danke Gruß
Johannes
Du hast zwar mit deinem theoretischen Teil Recht, doch leider ist Welt keine Ideale. So kommt es, dass einerseits der Sender nicht alle 5 ms eine Nachricht sendet und auch, dass der Quarz des Empfängers nicht so genau schwingt, wie er sollte. Ich bin allerdings überzeugt, dass die NI-Karte genauer arbeitet als dein CAN Spy. Wenn du glaubst, die Verwendung der Channel-API löst dieses Problem, so muss ich dir sagen, dass es nur verschleiert wird. Die Channel-API nämlich spuckt in einem festen Raster Werte aus, meinetwegen 20 Hz. Wenn jetzt aber durchschnittlich die Frames nur mit 19,9 Hz eintreffen, dann wird die Channel-API bereits den zweiten Wert als Kopie des ersten ausgeben müssen, denn sie eilt sozusagen der Frequenz der eingehenden Nachrichten vorraus. Und ob die Channel-API wirklich mit der von dir geforderten Genauigkeit arbeitet müsstest du auch noch überprüfen. Am besten ist es, mit der Frame-API die Nachrichten samt Zeitstempel abzulegen. Du könntest natürlich auch den Fehlerausgang des CAN-Read abfragen. Gibt das VI einen Wert als Kopie aus, dann wird dort ein Warnung ausgegeben. Ist das der Fall, können die Daten verworfen werden. Vorraussetzung ist allerdings, dass die Frequenz fürs lesen höher ist als die höchste Sendefrequenz aller zu lesenden Nachrichten auf dem Bus, denn die API sagt dir nicht, welches Signal bzw. Nachricht als Kopie ausgegeben wurde.
Ja es ist sicherlich sinniger die Daten mit dem Zeitstempel zu erfassen.
Kann ich Daten überhaupt doppelt lesen? Am Lesen VI geb ich doch an wieviel ich lesen möchte. Wenn er das nicht lesen kann bzw wenn keine Daten da sind, gibt es doch sicherlich einen Timeout. Ich kann aber doch auch vorher schauen ob überhaupt Nachrichten da sind und wenn ja dann les ich die vorhanden.
Also dein Vorschlag wäre demnach alles mit Zeitstempel zu erfassen und an die Hostanwendung zu schicken. Die Channel API ist natürlich auch etwas "komplizierter" wenn ich dynamisch IDs lesen erfassen möchte. Die Frame API Net gibt mir ja prinzipiell erstmal alles was sie so auf dem Bus mitbekommt.
Kann man irgendwie die Zeitstempel der Analogkarte und den Zeitstempel der CAN Karte synchronisieren? Bzw kann man einen Takt für alle Karten zu Verfügung stellen und diesen als relativen Zeitstempel nutzen? So dass man praktisch einen "Mastertimestamp" hat?
Ist klar was ich meine
Gruß Johannes
Platt gesagt gibt dir die Channel-API immer den derzeit aktuellsten Wert. Wenn sie dir allerdings den aktuellsten Wert ein zweites, drittes ... Mal gibt, dann kommt auch eine Warnung, dass das nur Kopien sind. Zum Verständnis: Die Channel-API gibt dir keine Nachrichten weiter, sondern die aus den Daten der Nachricht extrahierten Channels (Normalerweise spricht man hier von Signals).
Die Frame-API kann übrigens so konfiguriert werden, dass sie nicht alles, was sich auf dem Bus so tummelt, in den Lesepuffer schiebt. Mit Masken kann dort, wie bei Karten vieler anderer Hersteller auch, der ID-Bereich und sogar Datenbereich begrenzt werden (Hilfe des VIs ncSetAttr.vi beachten. Gibt auch Beispiele hierfür).
Die Synchronisation der Zeitbasis geschieht über RTSI. Bei PCI-Karten ist hierfür ein Flachbandkabel notwendig.
Das mit dem RTSI hab ich mir schon ein bisschen angeschaut. Aber sorgt das nicht "nur" dafür, dass beide Tasks gleichzeitg gestartet werden? Oder wird dadurch wirklich ein Clock für die Berechnung des Timestamps genutzt?
Guck dir die Hilfe des VIs "ncConnectTerminals.vi" an. Es gibt einen Starttrigger, gemeinsame Master Timebase und Eventtrigger für Ein- als auch Ausgehende Nachrichten.