CAN MultipleRead Size Notification

Hallo slevin,

Zitat:Das passende Signal wüsst ich spontan nicht wie ich simulieren soll

Indem du an der Stelle, die ich im Bild gestern mit einem Pfeil gekennzeichnet habe, einen Indicator erstellst. Diesen dann im laufenden Betrieb befüllen und die dann "aktuellen Werte als Standard" hinterlegen. Dann das VI speichern und hier anhängen…

Anzeige

Hey Gerd,

das mache ich sobald ich den Sensor wieder habe, ein Kollege braucht den gerade für seine Masterarbeit.

Zitat:Indem du an der Stelle, die ich im Bild gestern mit einem Pfeil gekennzeichnet habe, einen Indicator erstellst. Diesen dann im laufenden Betrieb befüllen und die dann "aktuellen Werte als Standard" hinterlegen. Dann das VI speichern und hier anhängen…

Übrigens sehr schöne Methode, werde ich mir auf jedenfall merken!

Gruß
Slev1n

Hey Leute,

die Eingangsdaten werde ich vor Anfang nächster Woche nicht erzeugen können. Hab aber noch kurz eine andere Frage zum CAN Bus bzw. der Read Queue.

Folgende Situation:
   

Ich schaue also zuerst, wieviele Frames in der Read Queue sind. Dann lese ich aber nur einen Teil davon aus.
Beispiel: 20 Frames sind in der Queue, ich habe 8 verschiedene IDs (#IDs = 8). Deshalb werden nur 16 Frames ausgelesen. Ich wollte fragen, ob beim nächsten Durchlauf, die 4 "nicht gelesenen" Frames überschrieben werden, oder diese noch in der Read Queue sind und nun ausgelsen werden?
So wie ich es verstanden hab, werden die Frames erst überschrieben, wenn die Queue überläuft oder?
Was ist der Unterschied zwischen Buffer und Read Queue?

Viele Grüße und schönes Wochenende

Slev1n

Die 4 nicht gelesenen Frames sollten in der Read Queue verbleiben. Wenn du gelesen hast, dass bei Überlauf der Read Queue die ältesten Elemente überschrieben werden wird dies wohl so sein. Für eine solche API auch sinnvolles Verhalten.
Was meinst du mit diesen beiden Begrifflichkeiten bzw. in welchem Kontext werden diese genannt? Im allgemeinen wird dein CAN-Interface eingehende Nachrichten puffern und die bereitgestellte API stellt dir diesen Puffer in Form einer Warteschlange (Read Queue) zur Verfügung. Ziel ist die möglicherweisende eingehende Nachrichtenflut zu puffern, da deine softwareseitige Behandlung nicht immer zwingend Schritt halten kann und entsprechend die Chance bekommen muss aufzuholen. Da dein Windowsrechner auch noch andere zeitliche Einflüsse auf deine Ausführung nimmt ist dies entsprechend auch ein sehr sinnvolles Verhalten.