Das wäre in der Tat nicht im Sinne des Erfinders
Kannst du das "Email senden.vi" hochladen bitte? Dann probiere ich auch mal etwas aus. Es könnte doch gehen, dass man zuerst die eigenen Angaben eingeben muss.
Grüsse
Das wäre in der Tat nicht im Sinne des Erfinders
Kannst du das "Email senden.vi" hochladen bitte? Dann probiere ich auch mal etwas aus. Es könnte doch gehen, dass man zuerst die eigenen Angaben eingeben muss.
Grüsse
Jo, ist HIER
Ich schnall's einfach nicht![]()
So!
Es gibt - ENDLICH - was Neues
Ich habe mich natürlich an die M256 gemacht und das Beispiel 12 (eine Wifi-Remote für ein Terminal) so umgeschrieben, dass es für meine Zwecke funktioniert.
Und ich habe auch gleich die Chance genutzt, und das LabVIEW-Programm grundlegend erneuert:
Die Ansicht ist nun deutlich kleiner, was jedem nutzt, der nicht grade dieselbe Bildschirmgröße und -Auflösung hat wie ich.
Außerdem ists (hoffe ich) übersichtlicher geworden. Ich habe die gesamte Ansicht in verschiedene Registrierkarten gesteckt, so sieht man immer nur, was man braucht. Links ist eine Menüleiste zum einstellen der COM- oder eben WLAN-Adressen (je nachdem, welche Hardware man nutzt), zum Starten und anhalten des RP6, zum Programmstoppen, Hardware Auswählen, für eine Anleitung und einen Support.
Anhang 23092 Anhang 23093 Anhang 23094 Anhang 23095 Anhang 23096
Im Hauptfenster sind die wichtigsten Anzeigen dargestellt sowie das Schalten der LEDs, der Beeper und die Auswahl für eine Routine (oben links).
Unten rechts kann man gewisse Befehle direkt eingeben (siehe dazu Example12: Avoid, Cruise, Command-Mode etc). Die Tastatursteuerung ist (wenn der RP6 im Command-Modus ist) aktiv.
In der Registrierkarte "Einstellungen" sind weitere, weniger wichtige Sensordaten dargestellt und man kann alles möglich einstellen/schalten.
Dann kommen vorerst weniger wichtige Registrierkarten: Gesendete und empfangene Daten, Kamera-Live-Bild und das nach 2-Euro-Münzen suchende Kamerabild. Jedoch musste ich (bin auf LabVIEW 2011 umgestiegen) sämtliche Kamera-Sachen erst mal ruhen lassen. Steht auf der ToDo-Liste, jedoch eher etwas abseits momentan.
Ansonsten ist alles relativ ähnlich, nur dass nun zu sendende Befehle nicht mehr verloren gehen (sollten).
Nur ein Problem ist noch nicht gelöst: Das Speichern der COM- oder IP&Port-DatenDas muss man VOR dem ersten Programmstart in der beigefügten "Config.ini" reinsetzen. Wer nur eines von beidem nutzt, braucht auch nur das zu verändern. Ist nicht schön und wird bestimmt(!) bald geändert...
Herunterladen kann man das ganze HIER!
Über Kritik oder Ideen würde ich mich freuen!
Ich konnte das Ganze bisher auch nur mit M256 und Base zusammen testen, die M32 sollte aber ebenfalls funktionieren (8 Servos, die LEDs und der Beeper). Wenn jemand etwas anderes feststellen sollte, dann gerne immer her damit
Grüße,
Fabian
EDIT: Nach zwei Stunden des Rumprobierens funktioniert es jetzt endlich, dass die IP-, Port- und COMport-Daten gespeichert bleiben. Die Lösung war wieder einmal SEHR SIMPEL. -> Brett vorm Kopf
Wird in der nächsten "Version" drinnen sein.
Geändert von fabqu (24.08.2012 um 17:01 Uhr) Grund: Was Neues
Hallo fabqu,
Ich habegerade dein Lab-View Programm ausprobiert; sehr schick! =)
Ein paar Probleme gibt es aber noch:
- Obwohl ich eine M32 Erweiterung habe, tut sich dort nichts! Möglicherweise liegt es am TWI-Bus, denn von der Base und der M128 erhalte ich Daten.
- In der Software bleibt der Teil mit dem Beeper inaktiv.
- Wenn ich unten Recht den ACS-Modus auswähle, komme ich automatisch ins Einstellungen-Fenster aber danach nicht mehr heraus. (ist nur einmal passiert?!)
- LED 16 der Base lässt sich (wenn ACS auf Auto) nur Toggeln, bleit auf dem RP6 eingeschaltet.
Es wäre sicher super, eine Log-Datei auf die SD-Karte zu speicher, dann könnte man schauen, wann welche Ports ein- / ausgeschaltet wurden.
Hoffe, du kannst mit meiner Rückmeldung etwas anfangen und dann wird alles noch besser!
Grüsse,
Filou
[Edit] Der TWI-Bus funktioniert mit anderen Beispielprogrammen einwandfrei.
Geändert von Filou89 (24.08.2012 um 20:42 Uhr)
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!
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
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!
Lesezeichen