State-Machine mit 2 Queues

Hallo zusammen,

ich habe mal wieder eine Frage bezüglich der "Ansehnlichkeit" meines VIs bzw vielleicht ist es besser wenn ich frage, ob man das einfacher programmieren kann als ich. Ich sollte vielleicht dazu sagen, dass ich mit Queues, Meldern & Co noch nie vorher gearbeitet habe...

Problemstellung:

Ich kommuniziere über eine NI-CAN PCMCIA-Karte mit externer Hardware. Über ein Interface schicke ich Befehle, über das Andere bekomme ich die Antworten. Jetzt will ich meinen CAN-Traffic mitloggen können. Also nach einem Tastendruck soll ich gefragt werden in welche Datei ich den Traffic schreiben will, und dann soll er so lange mitschreiben, bis ich wieder anhalte. Wenn ich nach 5Minuten wieder weiterloggen möchte, ohne dass das VI beendet ist, soll einfach am Ende der Datei weitergeschrieben werden.


Ich habe das jetzt folgendermaßen gelöst:

- eine Schleife die auf den CAN Befehle schreibt (soll hier nur die echte Schleife simulieren)
- eine Schleife die die Antworten der angeschlossenen Teilnehmer vom CAN liest (soll hier nur die echte Schleife simulieren)
- eine Event-Schleife, die abhängig von meinen Tastendrucks Befehle in Queue1 schreibt
- eine Schleife die Queue2 liest und evtl in eine txt schreibt
- eine Schleife nach Drücken der Stop-Taste oder im Fehlerfall die Queues schließt

Die Lesen/Schreiben-Schleifen sollen wie gesagt mit dem CAN kommunizieren (hier "simuliert" über den Schleifeniterator) und dann die CAN-Daten als Strings in Queue2 schreiben.
Queue 2 wird von der Write txt-Schleife gelesen und die Elemente entfernt.
Queue 1 ist dafür da, allen Schleifen zu sagen, was gerade zu tun ist. Sie wird über eine FGV gepuffert.

Das Ganze funktioniert jetzt endlich so wies soll (nach 2 Tagen Arbeit), aber was mir überhaupt nicht gefällt sind meine 1000000 lokalen Variablen, die ich trotz den Queues noch verwendet habe.
Geht das was ich hier realisieren will auch irgendwie einfacher?
Oder habt ihr sonst Tips für mich?

Vielen Dank schon mal!

Gruß
Dommas

Anzeige

hm, hatte so ein Problem noch niemand?

Hallo Dommas,

ich habe mal in der Statemachine die FileRefNums weggelöscht und durch ein SR ersetzt. Wozu überhaupt zwei RefNums für die gleiche Datei?

Für die ganzen Flags würde ich eine FGV einsetzen (so sie überhaupt nötig sind: im Fall der FileRefnum signalisiert z.B. "NoRefNum", dass die Datei noch nicht geöffnet wurde!)...

Hi!

Ich denke du machst alles viel zu kompliziert. Also erstens solltest du lieber pro (Verbraucher-)Schleife eigene Queue benutzen. Z.Z. hast du zwei Queues die du in unterschiedlichen Schleifen liest und schreibst. Zweitens reichen für deine Aufgabe insgesammt nur zwei Schleifen:
1. Für die User Events
2. Für CAN Lesen/Schreiben und Daten Loggen

Deine FGV und die ganzen Flags (Variablen) sind überflüssig.

' schrieb:Hi!

Ich denke du machst alles viel zu kompliziert.

Das hatte ich schon befürchtet oder gehofft. Das weiß ich selber nicht so genau. Glücklich war ich mit der Lösung jedenfalls nicht.

' schrieb:Also erstens solltest du lieber pro (Verbraucher-)Schleife eigene Queue benutzen. Z.Z. hast du zwei Queues die du in unterschiedlichen Schleifen liest und schreibst.

Ok, dazu dann später. Was mich jetzt erstmal interessiert ist das:

' schrieb:Zweitens reichen für deine Aufgabe insgesammt nur zwei Schleifen:
1. Für die User Events
2. Für CAN Lesen/Schreiben und Daten Loggen

Reicht das sicher? Ich habe die Aufgabe, mit der GUI über den CAN mit Geräten zu kommunizieren. Und zwar so, dass ich im 25ms Takt Commands rausschicke (möglichst Back-To-Back) und dann auf die Antworten warte.
Das Ganze muss in einer Tab-Struktur angezeigt werden, und je nachdem in welchem Tab der User ist, werden andere Commands verschickt.
Wenn neue Infos in der Tabstruktur eingestellt werden, sollen diese sofort in die Commands mit übernommen werden.
Die Responses kommen nach ca 200-250ms zurück (in einem Tab schon ab ca 50ms nach dem Command möglich).
Die müssen dann natürlich sofort gelesen werden, aber die Aktualisierung der entsprechenden GUI-Felder reicht alle 500ms.
Parallel dazu muss die Möglichkeit bestehen, die Logdatei zu schreiben.

Das heißt, ich habe lauter verschiedene Zeiten. Geht das dann echt in einer Schleife?
Wie stelle ich das dann an?

Danke und Gruß

' schrieb:Das heißt, ich habe lauter verschiedene Zeiten. geht das dann echt in einer Schleife?

Der Eugen müsste mehr über deine Anwendung wissen ...deine "missbrauchten" CAN-Botschaften kennt er ja noch gar nicht...

Anzeige

' schrieb:Der Eugen müsste mehr über deine Anwendung wissen ...deine "missbrauchten" CAN-Botschaften kennt er ja noch gar nicht...

Welche missbrauchten CAN-Botschaften? Meinst du meine Interpretation einer ID? Dass man in sowas mehr als nur eine Gerätenummer verpacken kann?

Ich weiß zwar nicht ob das hier jetzt was hilft, aber ich arbeite mit den Extended IDs, obwohl ich nur 6 der 29 bits als "Gerätenummer" verwende. Zum einen sind mir laut Norm schon 15 bits "geklaut", da die fest vergeben sind, zum anderen haben meine verschiedenen Commands/Responses eigene IDs, die mit in der ID drin stecken, die über den CAN läuft. Ich weiß völlig unverständlich. Aber eigentlich ganz einfach:
Bit 0-1 ist fest laut Norm
Bit 2-8 ist die Message ID (Sagt aus, wie die Daten zu interpretieren sind)
Bit 9-14 ist die Geräte ID
Bit 15 ist ein Flag, ob Command/Response (stellt gleichzeitig sicher, dass Commands höhere Priorität haben)
Bit 16-29 ist fix laut Norm

Na gut, wenn du im festen Takt die Commandos rausschicken musst, dann trenne die Lese- und Schreibe- Schleifen voneinander.

Aber, hast du schon mal mein CAN-Terminal angeschaut? Ich glaube er macht alles was du brauchst. Er schreibt Nachrichten (auch mit Takt), er liesst die Daten und zeigt und loggt sie. Ich sage jetzt nicht, dass du dein Prog mit meinem Terminal ersetzen musst, aber da kannst du bestimmt abgucken, wie es gemacht ist.

Gruß

Hi eg

' schrieb:Aber, hast du schon mal mein CAN-Terminal angeschaut? Ich glaube er macht alles was du brauchst.

Ja, ich kenne das Terminal. Hier hab ich mir schon die Idee mit der State-Machine geklaut
Aber ich wusste, und weiß bis heute nicht so recht, wie ich das Terminal so umbauen könnte, dass es genau das macht was ich brauche.
Das SubVI zum schreiben ist mir eher im Weg. Aus dem habe ich einfach eine weitere While-Schleife gemacht.
Außerdem muss ich nicht nur das Loggen, was vom ncRead kommt, sondern auch das was ans ncWrite geht.
Jetzt habe ich im Prinzip 5 verschiedene "Fälle"
1. "Normalfall": schreibe 8 verschiedene Nachrichten im 25ms Takt (pro Takt eine)
2. schreibe 4 verschiedene Nachrichten im 100ms Takt
3. schreibe 8 verschiedene Nachrichten (andere als "normal") im 25ms Takt
4. Button gedrückt, schreibe gar nichts, bis Popup geschlossen
wenn mit ok beendet, übernimm die Infos aus dem Popup in Fall 2
wenn mit Cancel beendet, mach wie gehabt mit Fall2 weiter
5. sende einmalig eine Nachricht

Die Fälle werden über eine Tabstruktur gesteuert, in der gleichzeitig die Antworten Grafisch angezeigt werden, und die Commands eingegeben werden können.
Die Tab hat 8 Reiter. Die ersten 5 sind für Fall1, in einem Reiter gibt es den Button für das Popup.
Hier mal ein Screen:


Und wegen diesen Problemen hätte ich jetzt wie gesagt eine Whileschleife pro Aufgabe genommen. Schreiben, lesen, loggen anzeigen, Eventstruktur. Und da wieder überall die Daten von einander abhängen dazwischen Queues gezogen.
Wenn jemand einen besseren Vorschlag hat, nehme ich den sehr gerne an! Diese Lösung gefällt mir nämlich überhaupt nicht, aber ich weiß auch nichts besseres...

Gruß
Dommas

Noch eine Nachfrage zu dem Terminal:

Du wandelst hier ja mit dem Typecast einfach alles in Strings um, und dann kannst du jeden Spaß als Cluster übertragen (die Idee ist übrigens echt cool!) weil es immer aus String und Enum besteht.
Aber der Typecast findet es ja nciht so toll, wenn er ein Cluster das aus Arrays oder gar noch mehr Clustern besteht umwandeln soll. Gibts hier auch einen Trick, wie man kompliziertere / größere Strukturen in den gleichen Datentyp wandeln und zurückwandeln kann?