Nein leider nicht meine Frage war ja wie das auf der Multiio mit der Beschaltung für die snake vorgesehen war.
Thorben
Druckbare Version
Nein leider nicht meine Frage war ja wie das auf der Multiio mit der Beschaltung für die snake vorgesehen war.
Thorben
Hi Thorben,
im RN-Wissen schon den Abschnitt von fabqu's Hardware-Artikel zur MultiIO gelesen?
Hi Thorben,
da gibts mehrere Möglichkeiten, findest du auch HIER. Entweder, du veränderst das SnakeVision-Modul, wie HIER beschrieben (Überbrücken des Reglers) oder du schließt sie direkt an und benutzt den Transistor zum Pulsen des Moduls, wie es bei diesem Modul eigentlich vorgesehen wäre.
Viele Grüße
hallo,
habe nun die bumperplatine angeschlossen...
- beim betätigen des linken hinteren bumpers leuchtet die entsprende LED, beim rechten hinteren nicht
- beim ausführen der demo 3 erscheint die anzeige "0 <BUMPER> 0" auf dem LCD display, ansonsten keine reaktion. Ich nehme an, die "0" sollte sich beim betätigen des jeweiligen bumpers in eine "1" (?) verändern...
- auch beim kurzschliessen der entsprechenden lötpinns des rechten hinteren bumpers erfolgt keine reaktion
wie finde ich den fehler?
ein anderes kabel habe ich bereits probiert, die SMD bauteile vorsichtig nachgelötet...
danke...
Diesen Abschnitt http://www.rn-wissen.de/index.php/RP...jekt_Library_3
... im RN-Wissen gut gelesen?
Insbesondere die Verbindungen unter der Überschrift "Bumper anschliessen"?
nein, natürlich nicht!
der wahljumperblock stimmt, ich muss aber noch die zwei einzelne verbindungen wie sie in dem bild dargestellt sind herstellen...
ändert sich dann noch etwas an den libs, oder demos?
btw: den touchstone incl. netzteil habe ich heute weggeschickt, die coils wurden bei ebay als verschickt gekennzeichnet...
edit:
beide verbindungen sind jetzt dran. Ich muss noch die position der bumper genauer definieren:
in fahrtrichtung gesehen:
- beim linken hinteren bumper glimmt die entspr. LED dauernd, beim betätigen leuchtet sie
- beim rechten hinteren passiert nach wie vor nichts
- beim ablauf der demo_3 blinkt die linke hintere LED, rechte blinkt nicht.
- die anzeige im LCD bleibt beim betätigen beider bumper (einzeln) "0 <BUMPER> 0" unverändert, die linke hintere LED glimmt nicht, beim betätigen des linken hinteren bumpers leuchtet sie, rechts passiert nichts...
Hi inka,
Nein, die Libs/Demos gehen davon aus, dass diese Verbindungen hergestellt sind.Zitat:
ändert sich dann noch etwas an den libs, oder demos?
(Würde man sie nicht herstellen, wären die Bumper eh ohne Funktion.)
Rechts könnte es noch ein Hardware-Problem geben.Zitat:
beim ablauf der demo_3 blinkt die linke hintere LED, rechte blinkt nicht.
Dazu müßte fabqu etwas sagen.
@Dirk:
gibt es eigentlich eine erklärung für das dauerglimmen der LED (nur die eine, die geht, links hinten)? Beim ausführen der demo_03 ist das glimmen weg, kommt erst wieder beim programmabbruch / ende...
edit:
ich habe jetzt auf der rechten seite, (also der, wo der bumper nicht geht) einfach parallel zu der eingelöteten SMD-LED eine andere low-current-LED drangehalten - die leuchtet, wenn der bumper betätigt wird. Kann ich daraus schliessen, dass die SMD-LED falsch herum eingelötet ist?
Hi inka,
Ohne Ansteuerung der Platine (IO-Pins hochohmig) reicht es gerade für ein schwaches Glimmen der low-current LEDs.Zitat:
gibt es eigentlich eine erklärung für das dauerglimmen der LED (nur die eine, die geht, links hinten)?
Wird mit eindeutigen Pegeln (high/low) angesteuert, sind die LEDs dann deutlich an/aus.
Ja, wäre möglich.Zitat:
ich habe jetzt auf der rechten seite ... parallel zu der eingelöteten SMD-LED eine andere low-current-LED drangehalten - die leuchtet, wenn der bumper betätigt wird. Kann ich daraus schliessen, dass die SMD-LED falsch herum eingelötet ist?
Hi Inka,
wie Dirk schon gesagt hat ist das Dauer-Glimmen ein effekt des uC's und der tatsache geschuldet, dass wir Low-Current-LEDs genommen haben.
Dass die rechte LED gar nichts tut und auch keine Signale weitergegeben werden deutet darauf hin, dass hier noch ein Kontakt-Problem herrscht. Ich würde das mal am Bumper vermuten, aber auch an der LED würde ich nochmal nachlöten. Ebenso an den Pin-Stiften am Bumper-Board sowie an der MultiIO, die das Signal tragen.
Grüße,
Fabian
ich habe die LEDs beim nachlöten natürlich geschrottet, habe sie also durch zwei normale, 3mm low-current ausgetauscht, beide leuchten beim betätigen des jeweligen bumpers. Beim ablauf der demo_3 blinken die LEDs abwechelnd , wenn dann im LCD display die anzeige "0 <BUMPER> 0" erscheint leuchten sie zwar immer noch beim betätigen des bumpers auf, in den LCD-anzeige selbts gibt es aber keine reaktion, auf beiden seiten keine.Zitat:
Zitat von fabqu
Soll es dort eine geben?
ja natürlich sollte es da eine Reaktion auf dem Display geben. Aus 0 wir 1 beim Drücken. Prüfe doch so wie fabqu schon schrieb, Vorsichtig alle Kontakte, Kabel und Lötstellen.
habe ich eigentlich schon:
- lötstellen bumperboard
- lötstellen multi-IO
- kabel durch ein anderes ersetzt
welche von den kontakten/signalen am kabel auf der multi-IO seite sollten beim betätigten bumper schliessen?
Die Signale gehen "durch die LED".
Das geht also genauso wie bei den vorderen LEDs/Bumpern:
Die LEDs können vom uC angesteuert, also an/aus geschaltet werden.
Wird ein Bumper gedrückt, erhalten die LEDs nun ihren Strom durch den Bumper, nicht mehr durch den uC -> sie leuchten.
Der uC schaltet nun (siehe Dirks Libs) immer wieder für eine sehr kurze Zeit die LED aus (sollte sie an gewesen sein), schaut ob dennoch eine Spannung anliegt (eben wenn der Bumper gedrückt wurde) und schaltet sie wieder an (wenn sie vorher an war).
So kann die LED als ein- und als Ausgang dienen.
Wenn also deine LED bei Bumper-Betätigung funktioniert, aber im uC kein Signal ankommt, dann teste mal die Verbindungen ab der LED bis zur MultiIO:
Das Signal geht vom Bumper (der ja funktioniert) über den mittleren Bumper-Kontakt zur LED sowie zu einem Widerstand, R23 und R24 (je einer pro Bumper) auf der Rückseite, mittig, der Bumperplatine. Von dort aus geht das Signal zu den Pins 2 und 3 der Pinreihe, gezählt "von links" wenn man aufs Bumperboard schaut.
Von dort geht ja das 7polige Kabel zur MultiIO, dort gehen die Signale weiter zu den Pins mit der Bezeichnung "ON-R" und "ON-L" über dem ADC-Mxxx-Stecker. Die jumper müssen von diesen beiden Pins auf die Pins mit Nummern "8" und "4" gehen, dort geht das Signal dann auf den 10poligen ADC-Mxxx-Stecker und von dort dann zur jeweiligen RP6-Platine (M32, M128 oder M256).
Du kannst auch an all diesen Punkten das Signal mit einem Oszi, Multimeter oder sonst was nachmessen. Als Referenz nimmst du eben GND, ist ja auf der MultiIO genügend vorhanden.
Ich hoffe das hilft!
Grüße
Danke Fabqu!
das war eine beschreibung des weges für die fehlersuche wie sie nicht besser sein kann :-)
ich habe an allen genannten punkten gegen GND eine spannung von ca. 1,6V und bei gedrücktem bumper von ca. 5V gemessen. Also wie gesagt: letzte messung am Pin 4 bzw. 8. , am ADC Mxx konnte ich nichts mehr messen (wusste nicht wo), habe dann das 10polige kabel durch ein anderes ersetzt - die meldung vom bumper kommt am LCD nicht an!
der wahljumper soll auch jetzt so aussehen, nehme ich an:
Anhang 26414
Hi!
Alse ... ne :D
Dieser Wahljumper regelr, wo die Signale der Sharps/SRF02 am Bumperboard gehen UND ob ich die LFS-Platine (orange Jumper in deinem Bild) oder die Touch/3V3-Messung nehmen möchte.
Was du brauchst ist folgendes:
Anhang 26416
Dort siehst du den Pin-Jumper-Block direkt oberhalb des ADC-Mxxx Wannensteckers.
Die beiden Orange eingezeichneten Linien legen die Signale der Bumper ( "ON-R" und "ON-L" ) auf die Pins 4 und 8 des ADC-Mxxx-Wannensteckers.
Diese jumper kannst du immer drauf lassen, man muss sie eigentlich nie ändern (außer, man will hier wirklich was komplett anderes anbringen). Du könntest diese beiden Pins auch (auf der Board-Unterseite) miteinander verlöten, dann brauchst du keine Jumper verschwenden. (aber wirklich nur den Pin "ON-L" auf Pin "4" und "ON-R" auf "8" !!!!! )
Grüße
Hi Fabqu,Zitat:
Zitat von fabqu
und was ist mit den anderen verbindungen zwischen ON-L und 8 bzw. ON-R und 6? Entweder jumper zwischen ON-L und 4 /ON-R und 8 oder diese jumper, beides geht nicht...
Anhang 26417
abgesehen von den || strichen zwischen eben diesen kontakten die du mit den jumpern verbinden willst?
bei der verbindung wie im bild M32 dargestellt blinken die LEDs beim ablauf der demo_03 abwechselnd, bei deiner version nicht...
Ah, moment...
du hast ja die M32. Da bin ich grade überfragt, ob es da sinn macht, die Bumper-IO's mit dem IO-Mxxx-Wannenstecker zu messen, oder mit dem ADC-Mxxx-Wannenstecker.
Dirk? Wie ist das in deinen Libs?
Bei der M32-Lib sind die Bumper an PC4 und PD6, also an IO-Mxxx.
Dazu müssen die Verbindungen so hergestellt werden, wie im M32 Kapitel des RN-Wissen-Artikels unter "Bumper anschliessen" beschrieben ist.
Hat man diese Verbindungen (noch) nicht hergestellt, müßte man zum Testen der Bumper an ON_L und ON_R messen.
ich habe jetzt die verbindungen durchgemessen: beide pins (PC4 und PD6) des atmega32 auf der M32 haben kontakt zu den bumpern, 1,6V (bumper nicht betätigt) und ca. 5V bei geschlossenem/betätigten bumper, gemessen gegen GND auf dem EXT steckpin der BASE. Die LEDs blinken beim start der demo_03, reaktion auf dem LCD auf das drücken der bumper erfolgt nicht...
Was und wo kann ich noch messen/testen?
edit: schon seltsam die rp6-welt: ich habe jetzt die unveränderte RP6Control_MultiIO_03.c neu kompiliert und die meldung der bumper erscheint auf dem LCD-display. Hat jemand dafür eine erklärung?
Ein kleiner Reminder:
Die Multi-IO ist quasi "ausverkauft". Ein letztes freies Exemplar gibt es noch :)
Interessenten können sich gern bei Dirk oder bei mir melden!!!
Viele Grüße,
Fabian
hallo allerseits,
ich hinke etwas hinterher, ich weiss...
in letzter zeit habe ich mich mit den freien I/Os der m32 beschäftigt, die auf der multiIO (JP_IO 1 & 2) herausgeführt sind...
Durch den aufbau und die vielen kabel die bei mir über die multiIO führen, waren die jumper sehr eingeschränkt zugänglich, außerdem hat mir eine möglichkeit mal testweise an einen der IOs eine leitung dranzuhängen ohne den jumper zu entfernen gefehlt. Jetzt, wo die ArduIO noch dazu kommt - habe ich mir überlegt - wirds nicht besser :-(
die provisorische lösung für "testleitungen" am geschlossenem jumper
Anhang 29424
hat mich nicht überzeugt...
Der zustand über der multiIO vorher:
Anhang 29425
der adapter, dessen kabel sich bei bedarf beliebig verlängern lassen:
Anhang 29426
verwendet habe ich 20polige pfostenverbinder (mussten mit der feile etwas angepasst werden), 18polige gibts leiter nicht:-(...
und so sitzen die jumper jetzt:
Anhang 29427
vor der pin-doppelreihe für die jumper auf der neuen platine ist noch eine reihe pins, die auf der "m32-seite", also mit den anschlüssen 1 bis 9 verbunden sind...
Wow, super Idee! Sieht sehr gut aus! :)
Hi Inka,
wieso hinkst Du hinterher ? Die MultiIO ist immer aktuell :)
Die Zwischenlösung fand ich zuerst interessant. Doch beim nachdenken ist es quatsch, ich habe zwar jetzt zugriff auf den Port aber es besteht ja trotzdem die Verbindung vom eigentlich Jumper. Der Port wäre ja dann 2x belegt, also quatsch. Zudem hätte ich Sorge das beim abziehen des Kabels vom oberen Pin den Jumper gleich mit abziehe. Also keine Lösung. Wobei ICH auch eigentlich kein Problem sehe. Alle Port die von IO-Mxxx und von ADC-Mxxx kommen sind am darüberliegenden Jumperfeld erreichbar. Baugruppen die nicht angeschlossen sind brauchen auch keinen zuweisenden Jumper. Also wenn z.B keine DCF angeschlossen ist brauch auch der Jumper am J-IO Pin 1 nicht stecken und ich weiß PC_7 ist frei. Ist die DCF angeschlossen, ist PC_7 belegt, was nützt mir da Dein Zusatz Pin ?
Dirk ist begeistert, also irgendwas muß ich ja denn nicht verstanden haben. Denn ich versteh den Sinn Deiner Platine nicht. Aber egal Du bist zufrieden und nur das zählt.
Hi TrainMen,
ja, ich bin zufrieden...
- die zwischenlösung hat mir deshalb nicht so gut gefallen, weil sie das hauptproblem - die schlechte zugänglichkeit der jumper - nicht gelöst hat. Ansonsten gab es keine probleme mit leitung abziehen, der jumper blieb gesteckt (doppelte kraft, da zwei stifte). Da war eher das anlöten des stifts an den jumper schwierig...
- ist die jumperleiste bei dir besser zugänglich? Bei mir ging es nur mit pinsette. Schade, dass es keine fotos von deinem RP6 gibt :-( - wäre super interessant, wie und was du drauf hast...
- zu der doppelten belegung der I/Os habe ich so meine eigene theorie entwickelt, hauptsächlich der Inputs: Wenn ich z.b. am pin 8 des JP_IO die bumper der multiIO hab und gleichzeitig den input meines HC-SR04, erkenne ich doch an der art des signals woher der kommt - jumper nur einmal, SR04 immer wieder. Und das gleichzeitig mit dem empfang des US- signals die eine LED an der bumperplatine blinkt? Stört mich wenig...
Auf meinen Jumperleisten, stecken lange Jumper, da ist es kein Problem.
Mit den Bildern ist es sone Sache. Meine Kamera ist nicht so dolle bei Nahaufnahmen, so kann man sowieso keine Details erkennen.
Ich habe schon soviel an und umgebaut. Das ändert sich fast wöchentlich. Wenn ich jetzt ein Foto machen würde, wär nur der Bot mit der Basis Platine zu sehen. Da ich gerade die freien Lötplätze belege und das entfernen der vorderen Platine in Angriffe nehme. Letzteres hast Du ja schon hinter Dir.
Das mit der doppelt Belegung versteh ich immer noch nicht. Bleiben wir mal bei Deinem Beispiel und abgesehen von den blinken der LED der Bumperplatine. Du kannst doch ein Bumpersignal garnicht mehr auswerten. Der Port weiß doch garnicht ob ein Bumper oder ein HC-SR-04 ausgelösst hat. Oder doch ?
Hi TrainMen,
ich bin mir da auch nicht absolut sicher.Zitat:
Zitat von TrainMen
- beim messen mit dem HC-ER04 über pin8 kommen am port regeläßige signale, bei mir jetzt - schätze ich mal - alle 600ms. Im gleichen rhythmus blinkt auch die LED am bumper und auch die ausgabe im terminal kommt so (entfernung)
- drücke ich währen der messung mit dem HS-SR den den bumper, brennt die LED dauernd, die gemessene entfernung kommt aber im terminal nach wie vor alle 600ms
wie sich das ganze am port selbst darstellt weiss ich nicht, ich müsste mir überlegen wie das zu messen wäre...
Da man die einzelnen impulse messen/zählen kann, wird der port immer wieder auf "null" gestellt, sage ich jetzt mal. Beim gedrückten bumper wäre das aber ein dauersignal, wenn er denn gedrückt bleibt - was man beim hindernis ja annehmen kann, zumindest länger als ein paar milisekunden...
es ist doch egal ob ein Signal nur Millisekunden dauert oder ob es ein Dauersignal ist. Ein Signal kommt und die Bumper lösen aus, was ja an den LED leuchten zu erkennen ist. Nimm doch einfach mal die Bumperfunktion und schreibe den Code so das bei jedem auslösen ein Beep ertönt. Ich wette mit Dir das du ständig ein Beep hörst, obwohl Du die Bumper nicht bedienst. Das Signal bekommt der Pin 8 von den HS-SR04. Somit läßt sich der Bumper nicht mehr auswerten und die Doppelbelegung wäre falsch.
Hi inka,
Da du ja mit der M32 arbeitest, wurde im RN-Wissen Artikel empfohlen, den linken Bumper an Pin 8 von J_IO zu legen. Damit wäre der Bumper über PD6 auszulesen.Zitat:
zu der doppelten belegung der I/Os habe ich so meine eigene theorie entwickelt, hauptsächlich der Inputs: Wenn ich z.b. am pin 8 des JP_IO die bumper der multiIO hab und gleichzeitig den input meines HC-SR04, erkenne ich doch an der art des signals woher der kommt - jumper nur einmal, SR04 immer wieder. Und das gleichzeitig mit dem empfang des US- signals die eine LED an der bumperplatine blinkt? Stört mich wenig...
Da du den ICP-Pin (= PD6) ja jetzt wohl für deinen Ultraschall-Entfernungssensor brauchst, würde ich den linken Bumper auf einen anderen IO der M32 legen.
Je nachdem was du sonst noch nutzt, würde ich empfehlen:
a) PC7 (= Pin 1 von J_IO), wenn du DCF77 nicht nutzt
b) PC6 (= Pin 4 von J_IO), wenn du das Snake-Modul nicht nutzt
c) PC3 (= Pin 5 von J_IO), wenn du den Buzzer nicht nutzt
In der RP6Control_MultiIO.h must du dann den Portpin für den linken Bumper:
... anpassen.Code:#define IO_MULTIIO_BUMPER_L_IN IO_PD6 // IO-Mxxx: I/O
#define IO_MULTIIO_BUMPER_L_DDR DDRD
#define IO_MULTIIO_BUMPER_L_PIN PIND
#define IO_MULTIIO_BUMPER_L_PORT PORTD
..._L_IN wird dann IO_PCx und die anderen 3 Definitionen bekommen als letzten Buchstaben ein "C" anstelle von "D".
Warum sollte man nicht ZWEI Ausgänge (Ultraschallsensor + Bumper) zusammen an einen Input führen?
--> Es könnte passieren, dass die beiden Ausgänge gegeneinander arbeiten und zerstört werden!!!
(Dass das hier nicht passiert, liegt an der Verschaltung der Bumper: Dank fabqu Glück gehabt!)
Hi Dirk,
es geht hier nicht um die Suche nach freien Ports und deren Zuweisung. Es geht darum das die Platine die inka gebaut hat aus meiner sicht keinen Sinn ergibt. Du meintest ja WOW, was ist daran WOW ? Die Doppelbelegung die diskutiert wurde kann nicht funktionieren, Du meinest sogar das es nur Glück (Verschaltung) war ist das kein Schaden entstanden ist. Also welchen Sinn macht die Platine ? Lassen wir mal aussen vor das der Zugang leichter ist.
Hi TrainMen,
in diesem Thread geht es um Hardwarefragen zur MultiIO.
Einen Zusammenhang zwischen der Doppelbelegung eines Pins und dem "Höherlegen" der Anschluss-Pins der MultiIO durch eine Hardware-Konstruktion sehe ich nicht. Ich habe aktuell auf das Thema "Doppelbelegung eines Pins" geantwortet.
Mein Punkt:
1. Die Lösung von inka, eine bessere Erreichbarkeit der MultiIO-Anschlüsse zu konstruieren, finde ich GUT.
2. Eine Zusammenführung von 2 digitalen Ausgängen an einem Eingang finde ich SCHLECHT.
Ok?
manchmal lässt sich das aber schlecht trennen.Zitat:
in diesem Thread geht es um Hardwarefragen zur MultiIO.
und Inka hat das komplette Paket vorgestellt, Doppelbelegung und Höherlegen und Du hast WOW gebrüllt zum Paket. Aber egal ich habe mich eben nur gewundert warum gerade DU WOW sagst obwohl das Paket eben so Müll ist. Ich dachte ich habe irgendwas schon wieder nicht verstanden. Deine Punkte sind natürlich OK
ich ersetze mal Müll gegen so als Paket nicht anwendbar, die bessere Erreichbarkeit ist ja gegeben.
Hi Dirk,
habe es jetzt auf PC7 geändert...Zitat:
Zitat von Dirk
vielen dank für die änderungsvorschläge, es würde mich noch in diesem konkreten fall interessieren in welcher richtung der schaden gegangen wäre wenn fabqu nicht gut und gründlich gearbeitet hätte:Zitat:
Zitat von Dirk
a) HC-SR04
oder
b) m32?
zum schluss möchte ich hier noch ein paar worte in eigener sache verlieren:
ich gehöre sicher zu denen, die hier im forum mehr fragen stellen als sie antworten geben können. Auch aus diesem grund habe ich mir vorgenommen, wenn es mir gelingt ein problem - entweder gegeben, oder selbstgestellte aufgabe - einigermassen für mich befriedigend zu lösen, es hier zur verfügung zu stellen. Das vermisse ich immer noch im allgemeinem im forum, dass tut - ausser ausnahmen - kaum jemand hier....
Eigene lösungen zu presentieren ist aber immer mit dem risiko verbunden fehler zu machen.
Das gehe ich gerne ein weil dadurch evtl. ein anderer vor gleichen fehlern evtl. bewahrt wird. Ich bin immer bereit über meine fehler zu diskutieren (naja, mal mehr, mal weniger) um zu einer guten lösung zu kommen. Auch auch bin bereit kritik für fehler einzustecken, sie darf aber m.e. nach nicht den bereich des konstruktiven verlassen und unsachlich werden.
Aber - so oder so - ich bin von meinem vorsatz überzeugt und werde auch in zukunft hier nicht nur fragen stellen, sondern von zeit zu zeit - davon ausgehend, dass es anderen evtl. ähnlich geht - auf meine probleme und ideen mit meinem RP6 und damit verbundene lösungen (und fehler) eingehen. Ein paar haben sicher schon davon profitiert und das sollte sich nicht ändern...
weiterhin viel spass mit dem Rp6 - denn das soll es ja machen...
Hi inka,
Wenn die Bumper ohne Reihenwiderstand (R23/24) auf der Bumper-Platine nach VCC oder GND durchschalten würden, wäre der Ausgang des HC-SR04 u.U. zerstört worden. Die M32 hätte keinen Schaden genommen, weil sie ja an diesem "flotten Dreier" nur mit einem Eingang beteiligt war und der geht nicht so schnell kaputt.Zitat:
es würde mich noch in diesem konkreten fall interessieren in welcher richtung der schaden gegangen wäre wenn fabqu nicht gut und gründlich gearbeitet hätte:
a) HC-SR04
oder
b) m32?
In der RP6Control_MultiIO.h habe ich nun den Portpin für den linken Bumper so geändert:Zitat:
Zitat von Dirk
und mich zunächst gewundert, dass mit der selftest 3 der multiIO nur den rechten bumper beim betätigen im display anzeigt. nach dem kompilieren war der schreck wieder vorbei - alles lief...Code:#define IO_MULTIIO_BUMPER_L_IN IO_PC7 // IO-Mxxx: I/O
#define IO_MULTIIO_BUMPER_L_DDR DDRC
#define IO_MULTIIO_BUMPER_L_PIN PINC
#define IO_MULTIIO_BUMPER_L_PORT PORTC
in der konsequenz müsste ich jetzt - nach der änderung - aber ALLE programme, in denen die RP6Control_MultiIO.h inkludiert ist neu kompileren, oder?
Hi inka,
Ja genau, leider ... :(Zitat:
in der konsequenz müsste ich jetzt - nach der änderung - aber ALLE programme, in denen die RP6Control_MultiIO.h inkludiert ist neu kompileren, oder?
Hi inka,
ist es dir wirklich noch möglich nur eine Lib zu haben ?
Bei mir geht das gar nicht mehr, bei den vielen Änderungen. Ich habe die Libs der MIO alle direkt in meinen Projektverzeichnis. Die der Base und M32 sind in den Verzeichnissen des RP6. Wenn das Projekt fertig ist bekommt es neben dem Namen noch eine Nummer, die Nummer bekommt auch die geänderte Lib. Im Programm selbst ist Beschrieben welche Änderungen gegenüber dem Original gemacht wurden. So lässt sich schnell der entsprechende Zustand herstellen.
hi TrainMen,
ja, es geht. Wir verfolgen aber offensichtlich bei den um- und ausbauten des RP6 einen unterschiedlichen ansatz. Ich habe nicht so viele änderungen, versuche nur einen optimal ausgestatteten roboter zu bauen. Und die versuche, die dazu erforderlich sind beschränken sich auf die multiIO, eine EXP und ein paar steckbretter. Vieles spielt sich aber auch "außerhalb" des RP6, wie z.b. die IR-bake oder die ladestation...Zitat:
Zitat von TrainMen
Tja - ich wiederhole mich - schade, dass so keiner von den projekten was mitbekommt...Zitat:
Zitat von TrainMen
Hi Inka,
wenn ich mal ein Projekt habe was es hier noch nicht gab werde ich es vielleicht hier veröffentlichen. Übrigens wie Du, ich kenne von dir auch keine Projekte ausser die von dir oben genannten und die sind Neu und gab es hier noch nicht. Auch sonst sehe ich hier keine Projekte von anderen ( ausser vom Guru ) nur Codeschnipsel und die sind für mich meist ausreichend um was eigenes daraus zu machen.
Meine Projekte steuern Servos, LEDs, es werden Signal von irgendwelchen Baugruppen ausgewertet, Ein und Ausgeschaltet. Der RP6 bewegt sich wenig. Alles gab es hier schon. Mein letztes Projekt schaltet 48 LED. Ich glaube jeder weiß hier wie mal eine LED einschaltet, es ist nichts was man veröffentlicht, neben bei war es auch noch totaler blödsinn, mir hat es aber Spass gemacht.
Ich werde dieses Thema hier beenden.
Es geht hier um die Hardware der MIO.
So, die Platinen sollten heute wohl alle abgeschickt werden. Habe gestern noch das meiste fertig bekommen, Rest wird heute gemacht. Dann natürlich noch mit Dirks Testprogrammen Durchgetestet und dann ab damit ;)
Ich habe es euch schon per eMail gesagt, aber hier noch einmal:
Bitte Vorsicht mit dem hinteren rechten Distanzbolzen / Schraube / Muttern. Der kann leider Kontakt mit der Spule oder den Spulenkontakten machen! Daher hier am besten nichts befestigen oder wenn doch, dann die Kontakte / Pads der Spule erst mit Tape abkleben.
Sorry dafür!
Grüße