Hallo zusammen,
ich möchte CAN-Messages loggen. Als Grundgerüst verwende ich das Example
von PCAN-Basic API in Visual Studio 2008. Die ReadMessages-Prozedur will
ich so verändern, dass die Messwerte nicht nur gelesen, sondern auch in
einer csv-Datei gespeichert werden:
Allerdings funktioniert dieser Code nicht. Es liegt wohl (in erster
Linie) an den ^strings (Fehlermeldung: error C2440: '=':
'std::basic_string<_Elem,_Traits,_Ax>' kann nicht in 'System::String ^'
konvertiert werden).
Kann mir da jemand helfen? Wenn es eine andere funktionstüchtige
Log-Prozedur für dieses Beispiel gibt, nur her damit. Ich konnte leider
nichts Passendes finden...
Danke im Voraus!
convertiere doch erst einmal die empfangen Daten von ihrem jeweiligen
Format in das format string!
Die CANmsg ist eine structur die verschiedene Datentypen beinhaltet,
also z.b. CANmsg.ID ist ein int, CANmsg.Data[0] bis CANmsg.Data[7] sind
chars.
Das alles kann man nicht in einen string schreiben, du musst jeden Typ
explizit und einzeln nach sting wandeln!
Habe damals auch das example als Grundgerüst für meine Software
hergenommen, allerdings habe ich meine routinen damals in C#
geschrieben, kann dir also leider kein Beispiel in C geben!
Danke für den Hinweis. Allerdings haben sich jetzt die Fehlermeldungen
erhöht. Das Problem liegt wohl im Unterschied zwischen C# und C++ (und
meinem mangelnden Wissen bzgl. der Übersetzung zwischen den Sprachen).
Ich habe folgende Konvertierung versucht:
CANorNotCAN schrieb:> das Problem liegt wohl im Unterschied zwischen C# und C++
Was Du da nutzt, ist kein C++, sondern eine Microsoft-Perversion
namens "Managed C++" bzw. "C++/CLI". Sieht zwar so ähnlich aus, heißt
auch so ähnlich, ist aber kein C++, sondern eine Mutation für den
.Net-Unterbau.
Das hast Du bei Deinen Projekteinstellungen berücksichtigt?
@ auch PCAN-user:
an welcher Stelle (Prozedur) hast du denn geloggt?
@...:
... schrieb:> Macht nichts, das was der TO da macht ist ja auch kein C++.
"der TO"?!
CANorNotCAN schrieb:> ... schrieb:>> Macht nichts, das was der TO da macht ist ja auch kein C++.>> "der TO"?!
TO = Threadopener
Genau Du warst damit gemeint :)
Das example für C# hat die Funktion tmrRead_Tick welche eben zyklisch
den PCAN-Dongel auf empfangene Zeichen prüft, dort wird die Funktion
"ProcessMessage(TCLightMsg MyMsg)" aufgerufen.
Hier wird bereits die Struktur TCLightMsg (Deine TPCANMsg) übergeben,
und hier habe ich dann die CAN-Telegramme weiter verwendet und in ein
.csv gespeichert.
1
privatevoidtmrRead_Tick(objectsender,EventArgse)
2
{
3
TCLightMsgMyMsg;
4
CANResultRes;
5
6
// We read at least one time the queue looking for messages.
7
// If a message is found, we look again trying to find more.
8
// If the queue is empty or an error occurr, we get out from
Danke PCAN-User!
Mal etwas anderes: bzgl. stringcat_s kommt die Fehlermeldung:
"error C2660: 'strcat_s': Funktion akzeptiert keine 2 Argumente"
Was soll das?! Das "muss" mit den komischen ^ bei der Initialisierung
des Strings <head> zusammenhängen. Jetzt verstehe ich, inwiefern diese
Sprache > eine Microsoft-Perversion ist, wobei ich vermute, dass das
etwas CAN-spezifisches sein muss, da man im Internet nichts Gescheits
dazu findet :(.
achso ja,
das eigentlich speichern der Datei mache ich natürlich nicht im
tmrRead_Tick, in der Unterfunktion InsertMsgEntry befülle ich ein
array und in die Datei schreibe ich dann wenn ich mal Zeit habe, z.B.
wenn meine Messung beendet ist oder aber wenn ich den close-button
anklicke!!!
Das sollte aber klar sein!?
>Was soll das?! Das "muss" mit den komischen ^ bei der Initialisierung>des Strings <head> zusammenhängen. Jetzt verstehe ich, inwiefern diese>Sprache > eine Microsoft-Perversion ist, wobei ich vermute, dass das>etwas CAN-spezifisches sein muss, da man im Internet nichts Gescheits>dazu findet :(.
Ne sorry, hab leider keine Ahnung was das soll, die komischen "Häckchen"
sind mir gestern schon in Deinem code aufgefallen, keine Ahung was die
bedeuten!
Wobei 'strcat_s' noch ne weitere Eigenheit ist, die bei M$ auch in C++
(ja, richtiges C++ geht mit VisualStudio auch) auftaucht. Das normale
'strcat' gibt es zwar noch, schmeißt aber eine Warning (es sei denn man
stellt sie via #define wieder ab). Das 'strcat_s' will als zusätzlichen
Parameter noch die Puffergröße haben.
CANorNotCAN schrieb:> Ne sorry, hab leider keine Ahnung was das soll, die komischen "Häckchen"> sind mir gestern schon in Deinem code aufgefallen, keine Ahung was die> bedeuten!
Diese Häkchen (mit nur einem 'c') sind ein klares Zeichen dafür, daß es
sich hierbei nicht um C++ handelt, sondern um die .Net-Sprache
"C++/CLI". Sieht aus wie C++, riecht auch so ähnlich, ist aber kein C++.
Das ist ein Objektzeiger, bei dem Objekte mit gcnew statt new
angefordert werden müssen, und deren Speicher nicht von delete,
sondern vom garbage collector abgeräumt wird.
Wie gesagt, C++ ist das nicht.
Rufus Τ. Firefly schrieb:> Sieht aus wie C++
Aber nur auf den ersten Blick.
> riecht auch so ähnlich
Nö, riecht eher nach Müllkippe, 'garbage collector' halt :)
Ok, nachdem ich mich ein bissl orientiert habe (MC++-Syntax etc.) gab es
einige Fortschritte, aber jetzt hängt es wieder. Es ist ähnlich wie bei
Schrödingers Katze, sobald ich meinen Code wieder (teilweise)
einkommentiere, gibt es Fehlermeldungen, obwohl (!) das Programm
eigentlich bis zu dieser Stelle ordnungsgemäß laufen sollte. Habe mich
an dem msdn-Beispiel zu FileStream orientiert (poste es als C-Code, auch
wenn es das nicht ist ;) ):
1
private:voidReadMessages()
2
{
3
TPCANMsg^CANMsg;
4
TPCANTimestamp^CANTimeStamp;
5
TPCANStatus^stsResult;
6
7
String^head,^path;
8
FileStream^logfile;
9
StreamWriter^streamWriter;
10
11
// Initializes Variables
12
//
13
CANTimeStamp=gcnewTPCANTimestamp();
14
CANMsg=gcnewTPCANMsg();
15
16
17
path="C:...\\test.txt";// In dem richtigen Programmcode ist hier der richtige Pfad angegeben. Da der aber niemanden was angeht, habe ich ihn "zensiert" ;). Hier ist aber sicherlich kein Fehler!
18
head="string1,string 2,string3;";// auch hier habe ich zensiert
Die Funktion "ProcessMessageLog" ist eine Kopie von der bestehenden
ProcessMessage, welche ich um die Byte-konvertierung erweitert habe und
diese dann in die datei schreibe:
Typische Fehlermeldung (wird bei "streamWriter->Close();" am Ende der
ReadMessages-Prozedur angezeigt, wobei ich vermute, dass das eher
irrelevant ist):
"Eine nicht behandelte Ausnahme des Typs "System.NullReferenceException"
ist in PCANBasicExample.exe aufgetreten.
Zusätzliche Informationen: Der Objektverweis wurde nicht auf eine
Objektinstanz festgelegt."
das problem war, dass es mehrfach nacheinander aufgerufen wurde. habe es
bissl umgestellt (bspw. wird der filestream jetzt zu beginn bei der
globalen objekt-initialisierung angelegt, sodass ich diesen weiter unten
in ProcessMessages mehrfach aufrufen kann). es klappt jetzt erstmal
hinreichend gut, sodass ich erste tests machen kann. dem realen
härtetests wird der code wohl nicht standhalten können, da bin ich mir
jetzt schon zimelich sicher ;).
danke für die hilfe...