Motor Overcurrent fehler obwohl keine Motoren laufen

[vogel0815]

Ja ich bastel hier immer noch weiter, doch irgendwie hat mir mein RP6 heute
die Fehlermeldung

##### EMERGENCY SHUTDOWN #####
##### ALL OPERATIONS STOPPED TO PREVENT ANY DAMAGE! #####


### MOTOR OVERCURRENT ###


(s. task_motorControl() function in RP6Lib!)
You need to check Motor assembly (or your software).

The Robot needs to be resetted now.

um die Ohren gehauen und wie angekündigt dann auch gestoppt.
Doch das komische ist das ich zu dem zeitpunkt gar keine Motoren laufen hatte. Das Grundprogramm soll vorerst gar nicht die Motoren nutzen.
Was auch noch komisch ist, irgendwie hat der heute ne komische Macke, mitten im Vorwärtsfahren fährt der auf einmal Rückwärts obwohl im programm nur vorwärts vorgesehen und eingetragen ist.
Die Akkus haben noch 7,4V das sollte also nicht das Problem sein.

[Roboman93]

kannst du mal dein programm hier posten?
vielleicht is da was zu erkennen.

mfg roboman

[vogel0815]

Das Programm ist eigentlich das I2CSlave Programm für die Basis nur das ich im Hauptteil ein paar Sachen zusätzlich eingebaut hab.
Deshalb poste ich mal nur diesen Hauptteil, da der rest unverändert ist.

int16_t main(void)
{
	initRobotBase();

	setLEDs(0b111111);
	mSleep(500);
	setLEDs(0b000000);

	I2CTWI_initSlave(RP6BASE_I2C_SLAVE_ADR);

	ACS_setStateChangedHandler(acsStateChanged);
	BUMPERS_setStateChangedHandler(bumpersStateChanged);
	IRCOMM_setRC5DataReadyHandler(receiveRC5Data);
	MOTIONCONTROL_setStateChangedHandler(motionControlStateChanged);

	powerON();

	startStopwatch1();

	disableACS();
	setACSPwrOff();

	status.byte = 0;
	interrupt_status.byte = 0;
	drive_status.byte = 0;

	status.watchDogTimer = false;
	status.wdtRequestEnable = false;

	startStopwatch3();
	startStopwatch4();

	uint8_t led_change=0;
	PORTA &= ~ADC0;

	while(true)
	{
		task_commandProcessor();
		task_update();
		task_updateRegisters();
		task_RP6System();
		task_MasterTimeout();

		if ( (remote_control == false) )
		{
            /*
		    writeString_P("Links: ");
            writeInteger(readADC(ADC_LS_L)-5, 10);
            writeString_P(" - ");
            writeString_P("Rechts: ");
            writeInteger(readADC(ADC_LS_R), 10);
            writeString_P("\n\r");
            */
            PORTA |= ADC0;

            changeDirection(FWD);

            if (readADC(ADC_LS_L)-5 > readADC(ADC_LS_R))
            /*
                Abfrage der Widerstandswerte der LDR
                groesserer Widerstand auf einer Seite bedeutet auf dieser
                Seite ist der dunkle Strich

                Ist der Widerstand links groesser als rechts
                dann setze LED-register auf 4 (00000100)
                und steuere Motoren rechts schneller als links
            */
            {
                setLEDs(0b000100);
                //moveAtSpeed(90,30);
            }
            /*
                Ist der Widerstand rechts groesser als links
                dann setze LED-register auf 32 (00100000)
                und steuere Motoren links schneller als rechts
            */
            else
            {
                setLEDs(0b100000);
                //moveAtSpeed(30,90);
            }

            //warte 200 ms bis zum nächsten Durchlauf
            mSleep(200);
		}
		else
		{
		    PORTA &= ~ADC0;

		    switch (led_change)
		    {
		        case 0:
                    setLEDs(0b000000);
                    break;
                case 2000:
                    setLEDs(0b001001);
                    break;
                case 400:
                    setLEDs(0b010010);
                    break;
                case 600:
                    setLEDs(0b100100);
                    break;
                case 799:
                    led_change=0;
                    break;
		    }
            led_change++;
        }
	}
	return 0;
}

im TaskCommander hab ich noch einen neuen case eingebaut, der die variable remote_control setzt

case CMD_REMOTE:
                remote_control_temp=param1;
                if ( (remote_control_temp == remote_control) )
                {
                }
                else
                {
                    remote_control=remote_control_temp;
                    writeString_P("remote geaendert (BASE) \n\r");
                }
                break;

An der Base selber habe ich ein paar Änderungen vorgenommen, ADC0 ist nun als Ausgang geschaltet und steuert ein FET an. Über das FET schalte ich eine LED Beleuchtung die etwa 170 mA Strom zieht. Und die zwei Photozellen hab ich aus der Platine ausgelötet und über jeweils 2 Kabel wo anders befestigt.

Was ich grad festgestellt habe, sobald die Beleuchtung an ist spielen die 2 Photozellen verrückt. Egal wie ich die dann beleuchte. Hängen ADC0 und die eventuell irgendwie zusammen?

In der definition von PORTA hab ich lediglich ADC0 auf Ausgang gestellt.

// PORTA

#define UBAT 			(1 << PINA7) // ADC7 (Input)
#define MCURRENT_L 		(1 << PINA6) // ADC6 (Input)
#define MCURRENT_R 		(1 << PINA5) // ADC5 (Input)
#define E_INT1 			(1 << PINA4) // INT1 (input per default... can be output)
#define LS_L 			(1 << PINA3) // ADC3 (Input)
#define LS_R 			(1 << PINA2) // ADC2 (Input)
#define ADC1 			(1 << PINA1) // ADC1 (Input)
#define ADC0 			(1 << PINA0) // ADC0 (Input)

// Initial value of port and direction registers.
#define INIT_DDRA 0b00000001
#define INIT_PRTA 0b00000000

EDIT: Hab mal weiter rumprobiert. Mir scheint das es da irgendein Problem mit der rechten Seite gibt. Sobald ich irgendeine der Photozellen dort anschließe geht der RP6 in diese Störung.
Mal weiterschaun was das sein könnte.

[Dirk]

Hallo vogel0815,

die 170 mA für die LEDs sind schon eine ganz schöne Hausnummer für den RP6.

Wo genau nimmst du denn die Stromversorgung für die LEDs ab?

Versuch evtl., eine getrennte Stromversorgung für die LEDs anzuschließen.

Gruß Dirk

[SlyD]

Hallo,

nun die 170mA müssten schon klappen (getestet habe ich das bis ca. 1200mA Dauerlast - keine Probleme gehabt bis auf das der Regler ziemlich warm wurde), aber man sollte da ggf. einen LC Tiefpass davorsetzen - also z.B. ne 10µH Spule (in Serie) gefolgt von einem Elko mit 220µF (parallel) gefolgt von der eigentlichen Last (inklusive MOSFET! also nicht den LC Filter schalten... ).

Wenn die Spannung vom Controller kurz einbricht, kann das schon ein Überstrom Event auslösen, da der ADC Wandler in dem Moment evtl. nicht korrekt arbeitet und zu hohe Werte ausgibt.

Was sagt denn das Selftest Programm?
Also wenn Du ganz normal Test #8 ausführst?

Die Akkus sind nicht zu alt und waren beim Test frisch geladen?

MfG,
SlyD

[Dirk]

Aaalsooo,

ich muss mich da doch etwas "verteidigen":

Ich habs probiert:
Wie: Ein 27 Ohm-Widerstand (~185 mA) über einen Taster an +5V des RP6. Auf dem RP6 läuft nur ein Lauflicht.
Ergebnis: Es lassen sich bei meinem RP6 durchaus Störungen nachweisen. Auch einen Shutdown konnte ich nach mehreren raschen Tastendrucken erleben.
Meine Schlußfolgerung: 185 mA sind, wenn sie z.B. häufiger geschaltet werden und an 5V entnommen werden (keine Ahnung, ob vogel0815 das gemacht hat!), schon eine "schöne Hausnummer" für den RP6. Dabei ist gar nicht der max. beim RP6 zu entnehmende Strom relevant, sondern das Schalten (hat vogel0815 vielleicht sogar noch einen größeren Elko an den LEDs?)

@SlyD: Du kennst den RP6 natürlich am besten! Aber: So gaanz falsch lag ich m.E. doch nicht! Oder?

Gruß Dirk

[SlyD]

Hallo Dirk,

man muss zwischen konstanter Last (kein Problem) und hohen Stromspitzen bzw. hohen Laständerungen unterscheiden. Wenn die Änderungen zu schnell sind, muss man diese eben künstlich verlangsamen...

Dazu kann man wie ich oben schon gesagt habe einen LC Tiefpass Filter vorschalten damit das klappen kann ohne den Controller evtl. aus dem Tritt zu bringen!

Es kommt auch darauf an, wo genau die Last angeschlossen wurde. Wenn das direkt am Regler geschehen ist (z.B. XBUS2 Stecker) wird es besser funktionieren als wenn man die Last am XBUS1 Stecker am anderen Ende der Platine angeschlossen hat.

Entstörung ist bei geschalteten Lasten aber in jedem Fall notwendig!

Mindestens ein großer Elko möglichst nahe an der Last sollte es schon sein, wenn man gerade keine Induktivität zur Hand hat.

MfG,
SlyD

[vogel0815]

Der Roboter steht nun leider 200 km von hier weg, da ich das Wochenende über bei meinen Eltern bin.

Aber hier mal noch ein paar Infos. Also die LEDs hab ich vorne an der Stelle angebracht wo die Bumper-Platine hängt, die ist derzeit demontiert und liegt aufm Schreibtisch rum. Den Strom entnehme ich vorne am linken Ende der Platine von einem der VDD Pins (5V). GND habe ich dort ebenfalls abgegriffen und geht dann an den FET (BS170). Den schalte ich mit dem ADC0, den ich als Ausgang definiert habe. Die VDD und GND Pins von ADC0 sind nicht angeschlossen. Die LEDs mit ihren Vorwiderständen hängen dann an VDD eben aus der Ecke der Platine da.
Im Programm wird ja der Ausgang ADC0 bei jedem Durchgang erneut auf 1 gesetzt, das aber nur damit der FET konstannt auf 1 bleibt und die LEDs ständig an sind. Sonst würde dich der FET mit der Zeit wieder "entladen" und die LEDs wären wieder aus. Das Umschalten der Last selber erfolgt im fertigen Betrieb später nur recht selten. Während das Ding ferngesteuert wird sollen die LEDs aus sein, und während es der Linie folgen soll sind die an.

Habe aber inzwischen noch etwas anderes herausgefunden. Ich hab ja wie oben schon geschrieben die Fotozellen aus der Platine vorne rausgelötet und durch etwa 10 cm lange Kabel woanders angebaut.
Der linke Anschluss der Fotozellen macht keine Probleme egal ob die LEDs an sind oder nicht und egal welche Fotozelle ich da anschließe. Aber sobald ich eine der beiden Fotozellen an die rechten Anschlüsse anhänge dauert es noch 5-10 sec und die Störung kommt.
Leider hatte ich dann keine Zeit mehr um das weiter zu untersuchen.

Ich hab mal in den Schematics geschaut, sind Light_L und Light_R aus dem PDF für die Sensoren die selben Anschlüsse die im PDF für die Base mit LS_L und LS_R angegeben sind? Aber selbst wenn ich versehentlich bei der rechten Fotozelle einen Kurzschluss "gelötet" hätte, dann würde da am Eingang des uC direkt 5V anliegen, das wäre ja auch keine Erklärung für das Problem oder?

Diesen LC Tiefpass den du meintest, sollte ich den dann eher zw. GND und FET einbauen oder zw. FET und Last?

EDIT: ah ok hab eben nochmal deinen Beitrag gelesen mit dem LC Tiefpass. Also den dann vor den FET und die Last.

[radbruch]

Im Programm wird ja der Ausgang ADC0 bei jedem Durchgang erneut auf 1 gesetzt, das aber nur damit der FET konstannt auf 1 bleibt und die LEDs ständig an sind. Sonst würde dich der FET mit der Zeit wieder "entladen" und die LEDs wären wieder aus.

Ähm, mit FETs kenne ich mich nicht aus, aber was zieht der denn so auf der Steuerleitung? Der Ausgang ADC0 bleibt solange High bis du ihn wieder ausschaltest, er benötigt keinen "refresh". Was passiert wenn du den FET direkt mit einem Drähtchen nach VDD ansteuerst?

[vogel0815]

was der FET genau zieht kann ich dir grad leider nich sagen. Muss ich mal messen wenn ich wieder bei meinem RP6 bin.
Wie oben schon geschrieben, wenn ich das Gate fes FET direkt auf VDD ziehe, und an den Pins der rechten Fotozelle nichts hängt, sind die Lampen an und es gibt keine Fehlermeldung. Ich kann also ohne diese betreffende Fotozelle die LEDs locker 10 min leuchten lassen ohne das irgendwas passiert. Aber sobald ich an die Pins der rechten Fotozelle eine der zwei Fotozellen anschließe dauert es 5-10 sec und ich hab die Fehlermeldung.
Demnach vermute ich, dass das Problem vom Anschluss der Fotozelle her kommt und nicht von den LEDs.
Die Fehlermeldung bekomme ich ja sobald ich eben an die Pins der rechten Fotozelle eine anhänge, unabhängig davon ob die Beleuchtung an ist oder nicht.
Ist die Fehlermeldung MOTOR OVERCURRENT eigentlich allgemein für jegliche Art von Überstrom und nicht wie der name sagt nur auf die Motoren begrenzt?