LabView-Fernsteuerungs-Tool mit diversen Routinen

[fabqu]

Hi! Danke dir für diese Punkte!!!
Zu deinen Anmerkungen:
1.) M32 wurde von mir bisher nur im Code einprogrammiert, aber nie getestet. Wird aber auf jeden Fall kommen, sobald die Kommunikation M256<->Base einwandfrei funzt. Und du empfängst Daten von der M128 (über die M256) auf LabView??? Das sollte absolut nicht möglich sein, eigentlich
2.) Beeper wurde gerichtet. War nur ne Variable falsch gesetzt, sorry.
3.) Ist es nur ein einziges Mal passiert? in LabVIEW, oder als .exe? Bei mir klappts komplett. Nur die Abstands-LEDs werden nicht ganz korrekt dargestellt, wird aber repariert.
4.) Bei mir gehen alle 6 LEDs einwandfrei, einzeln sowie zusammen. Wieder die Frage: LabVIEW, oder .exe? Evtl Hardware-Fehler? Funzt sie ansonsten?
EDIT: Wegen der LED hatte ich überlesen, dass du "ACS Automatik" aktiviert hattest. Stimmt, da muss ich was ändern. Im Auto-Modus werden ACS vorne (das Board-eigene) und hinten (zwei Sharp-Sensoren, die mit einem Transistor über eben diese LED geschaltet werden) automatisch erst dann aktiviert, wenn der RP6 eben vor- oder rückwärts fährt.
Schalte mal ACS auf Auto und fahre rückwärts, dann müsste sie nach 200ms angehen und 200ms nach dem Stop/Richtungswechsel wieder ausgehen.

Das mit dem SD-Log steht bei mir auf der ToDo, ich will genau das unbedingt mit rein nehmen. Nicht nur ein Befehls-Log, sondern auch ein Daten-Log. Etwa 1-10 mal pro Sekunde, hatte ich mir überlegt.
Leider blicke ich beim SD-Programmieren noch zu wenig durch, daher könnte es noch etwas dauern, bis das umgesetzt wurde.

Grüße und danke Dir!

[Filou89]

Ooops, sorry
wollte eigentlich M256 schreiben. Eine M128 Habe ich garnicht!
Mit dem Datenlogging bin ich auch noch ein wenig am üben. Wenn ich den durchbruch schaffen würde, sag ichs dir als erster =)

Ich habe alles mit der .exe gemacht.
Die Labview-Runtime hatte sowieso an diesem Abend ein paar Hänger. Ich werde es noch ein paar mal durchspielen.

Grüsse
Filou

[fabqu]

Nun, da ich nicht weiß, wie die Runtime funktioniert, noch wie die Umwandlung in eine .exe klappt, kann ich dazu nix sagen (vielleicht jemand anderes hier im Forum? )
Ich bin ohnehin momentan dabei, die gesamte Architektur umzukrempeln. Bisher habe ich einfach parallel verschiedene Funktionen laufen gehabt (siehe dein LED-Problem: die Funktion "ACS-Automatik" hat dir die ganze zeit parallel in die Funktion "setze LEDs" gepfuscht).
das soll nun mit Queues und einer "Queued State Machine - Producer Consumer" -Architektur anders werden. Dann wird nur noch auf Ereignisse reagiert (wie das Rückwärtsfahren mit ACS-Automatik oder eben das LED-Einschalten), anstatt dass dauernd in Funktionen Variablen gesetzt werden müssten. Somit sollten Datenverluste vermieden werden, und das Gesamtprogramm flüssiger laufen.
-> Viiieeeel Arbeit

Grüße!

[Filou89]

Hallo Fabqu,
Wie steuerst du eigentlich die M32 per I2C an? In der RP6M256_I2CMasterLib.c / .h sind nämlich noch gar keine Funktionen für die M32 vorhanden. Die müssen zuerst noch alle implementiert werden.
Hat das schon jemand gemacht? Dann könnte man sich ein ziemliches Bischen Arbeit sparen.
Grüsse
Filou

[fabqu]

Hi! Nein, es ist noch nix drinnen, um die Daten der M32 abzurufen. Kommt bald
Zum Steuern kann man ja einfach den "I2CTWI_transmit3Bytes" oder ähnliche nehmen... ODER? Die Adresse der M32 ist 20, die der Base ist 10.

Grüße

[fabqu]

Ich hätte einmal eine Frage an euch, da ich die LabVIEW-Remote ja nicht für mich alleine schreibe.

Zum Stand der Dinge: Die M256 läuft stabil mit dem momentanen Programm zusammen mit der Base. Die Datenübertragung zum PC klappt fehlerfrei und in einer Geschwindigkeit, die einfach Spass macht. Das LabVIEW-Programm macht hier und da noch Zicken, aber das sollte (zumindest für base und M256) bald halbwegs problemfrei sein.
Jetzt ginge es eben darum, die M32 für Servos etc einzubinden und die I/Os und ADCs auf der M256 zu nutzen. Daher an dieser Stelle meine Frage an Euch:
Man könnte die M32 einbinden. hat Vorteile: 4 LEDs, Mikro, Lautsprecher, weiteres LCD, 8 Servos, ADCs. Nachteil ist einfach nur, dass man ein weiteres Modul hat, das programmiert, geflasht, angeschlossen und versorgt werden muss.
Oder aber, man benutzt NUR die M256 (und eben die Base). Hat den Vorteil, dass man auf der Base das Slave-Programm laufen hat - das bleibt ja mehr oder weniger unverändert, da man ja "nur" 6 I/Os und 2 ADCs zur Verfügung hat. Daher ist die Variationenvielfalt für eine Remote eher eingeschränkt und man wird auf Dauer nicht viel am Slave-Programm verändern müssen.
Die Servo-Lib der M32 könnte man ja sicher auch in der M256 einbinden. Ein Beeper ist sicherlich auch relativ schnell umzusetzen und ein Mikro - ganz ehrlich, wer braucht das unbedingt??? Und I/Os und ADCs sind auf der M256 ja genug (?) vorhanden.

Ich plane ohnehin eine neue Platine als Beiwerk für die M256 mit eigener Spannungsquelle, Servoverteiler, Beeper, Transistoren zum Schalten und einem Temp-Fühler mit I2C. Evtl auch Kompass und/oder GPS.

Würde mich freuen, die ein oder andere Meinung dazu zu hören.

Grüße,
Fabian

[Filou89]

Hallo Fabian,
da ich an der M256 ein GLCD und an der M32 ein normales lcd habe, brauche ich beide Platinen.
Wie ich aber im M256-Forum-Thread gelesen habe, sollte sowieso bald eine offizielle I2C Master-Slave kombination auch für M256 - M32 erscheinen.
Den Nachteil, dass ein weiteres Modul angeschlossen & geflasht werden muss, empfinde ich nicht als tragisch.

Übrigens: GPS wurde hier schon öfters thematisiert. In Innenräumen wird das niemals genügend Genauigkeit erreichen.

Grüsse
Filou