Hallo zusammen,
ich habe letzte Woche in c't Lab Forum auf der Heise Seite mal angeregt, Wünsche und Anregungen zu einer EDL (elektronische Last EL) abzugeben. Die Rückmeldungen hielten sich in Grenzen.
Ich fasse mal kurz zusammen:
MarcusP (27.11.2007)
-> Frequenzgang 0 bis ganz viel, triggerbar von aussen
-> von aussen modulierbar
Schimmi (28.11.2007)
-> Leistung <= 20 W ausreichend
-> Auflösung Spannungsmessung 'ziemlich genau'
-> Hauptzweck Akkupflege
Meine eigenen Überlegungen im Folgenden:
D/A Wandler
-> 12 Bit PWM (aus ATMEGA32)
-> 12 Bit DA
-> 16 Bit DA
A/D Wandler
-> 10 Bit (intern ATMEGA)
-> 12 Bit
-> 16 Bit
Referenzspannung
-> LT1019
-> LM385
-> LM4040
Endstufe
-> IRF 3205 (MOSFET)
-> TIP 142 (Darlington)
Maximale Leistung
-> 100W (Kühlkörper wie auf DCG)
-> ???W mit Lüfteraggregat (z.B. Reichelt LAM 4150 12V)
Regler
-> Auswahl OPs
Lüfter
-> Steuerung in abhängigkeit von Temperatur
Temperaturmessung
-> LM75 (unter Kühlkörper)
Bereichsumschaltung
-> 10A
-> 1A
-> 100mA
-> 10mA
Betriebsarten
-> R-/I-Betrieb (Software-/Hardwarekontrolle?)
-> Rampe
-> Puls
Abgleich
-> komplett in Software (bzw. soviel wie möglich)
Im Lauf der letzten beiden Wochen habe ich mal einen Versuchsaufbau gemacht. Schaltplan dazu im Anhang (noch nicht aufgebaut: Bereichsumschaltung, AD Wandler noch nicht in Betrieb). Eine Firmware für den ATMEGA gibts auch schon (nur rudimentäre Funktionen verfügbar). Die Firmware war schon fertig, bevor amd-65 seine DCG Firmware bereit gestellt hatte.
Ich lege mal den Schaltplan in den Anhang. Der Regler bedarf sicher noch einiger Überarbeitung (da denke ich mal am MarcusP), das ist nicht so ganz mein Fall.
Vielleicht kann ja CM auch seine Gedanken mit einfliessen lassen. Dieses Projekt wurde schon mal als Idee in der Roadmap erwähnt.
MfG
Siegi.
EDL
-
siegiathome
- kann c't-Lab-Module umbauen
- Beiträge: 62
- Registriert: 30.11.2007, 11:43
EDL
- Dateianhänge
-
- edl_01.pdf
- Diskussionsgrundlage für eine EL
- (21.38 KiB) 841-mal heruntergeladen
Hallo Siegi,
sieht ja schon mal nicht ganz so schlecht aus...
Eine Sache ist mir im Schaltplan noch aufgefallen: Die beiden Widerstände R19/20 sind eigentlich nur nötig, wenn für Q5/6 die TIP142 verwendet werden. Bei den MOSFET's würde ich diese weglassen.
Für schnellere Pulse sollten vor den MOSFET's Q5/6 noch eine Bipolartreiberstufe geschaltet sein, sonst erreichst Du die Flankensteilheit bei den Parasitärkapazitäten der MOSFET's nicht. Für eine Akku-Innen-Widerstandsmessung wären Pulslängen von 1µs durchaus notwendig... Bei gleichzeitiger Messung des Impulsstromes natürlich.
Im Prinzip sollte nicht nur die Ist-Spannung der EL erfasst werden, sondern auch der Ist-Strom.
Wünschenswert wäre auch im R-Betrieb die Möglichkeit zwischen zwei oder mehrere Widerstandswerten umschalten zu können um beispielsweise das Last verhalten von Netzteilen testen zu können.
Das JTAG Debug Interface finde ich klasse, dass das endlich mal einer gleich vorsieht!
Du solltest jedoch R21-24 und R27 weglassen, da Atmel das so nicht vorsieht und die Widerstände durchaus Probleme beim Debuggen verursachen können.
Vorsicht ist beim Debuggen auch geboten, da die PC-Masse über das JTAGICE mit dem PC verbunden ist.
So, das waren jetzt einfach mal ein paar Gedanken von meiner Seite...
Grüsse,
Schimmi
sieht ja schon mal nicht ganz so schlecht aus...
Eine Sache ist mir im Schaltplan noch aufgefallen: Die beiden Widerstände R19/20 sind eigentlich nur nötig, wenn für Q5/6 die TIP142 verwendet werden. Bei den MOSFET's würde ich diese weglassen.
Für schnellere Pulse sollten vor den MOSFET's Q5/6 noch eine Bipolartreiberstufe geschaltet sein, sonst erreichst Du die Flankensteilheit bei den Parasitärkapazitäten der MOSFET's nicht. Für eine Akku-Innen-Widerstandsmessung wären Pulslängen von 1µs durchaus notwendig... Bei gleichzeitiger Messung des Impulsstromes natürlich.
Im Prinzip sollte nicht nur die Ist-Spannung der EL erfasst werden, sondern auch der Ist-Strom.
Wünschenswert wäre auch im R-Betrieb die Möglichkeit zwischen zwei oder mehrere Widerstandswerten umschalten zu können um beispielsweise das Last verhalten von Netzteilen testen zu können.
Das JTAG Debug Interface finde ich klasse, dass das endlich mal einer gleich vorsieht!
Du solltest jedoch R21-24 und R27 weglassen, da Atmel das so nicht vorsieht und die Widerstände durchaus Probleme beim Debuggen verursachen können.
Vorsicht ist beim Debuggen auch geboten, da die PC-Masse über das JTAGICE mit dem PC verbunden ist.
So, das waren jetzt einfach mal ein paar Gedanken von meiner Seite...
Grüsse,
Schimmi
-
siegiathome
- kann c't-Lab-Module umbauen
- Beiträge: 62
- Registriert: 30.11.2007, 11:43
Hallo Schimmi,
schön, dass sich doch wer dafür interessiert
Widerstände:
R19/R20 wollte ich nur als alternative drauflassen, falls jemand höhere Spannungen als 60V benutzen möchte (TIP 142 bis 100V). Werde ich sicher nicht brauchen, bei mir hört es i.A. bei 12V auf....
Schnelle Pulse:
bipolare Endstufe vor den MOSFETS klar, aber wer soll den Impulsstrom mit einer Auflösung von <1µs messen?
Ist Strom:
sollte eigentlich an V1 (Label über R35/Q7) gemessen werden können (oder nicht?)
R-Betrieb:
wer kann mir da weiterhelfen, hab bisher keine Idee dazu (Software- oder Hardware Lösung?)
Vorwiderstände für JTAG Interface:
benutzt ich eigentlich fast immer. Hab nur mittlerweile festgestellt, dass der JTAG Ice mkII damit ab und zu Probleme hat. Beim DRAGON hatte ich bisher keine Probleme. Bietet halt ein bisschen Schutz, wenn Debugger und Schaltung in eingeschaltetem Zustand verbunden werden.
MfG
Siegi
schön, dass sich doch wer dafür interessiert
Widerstände:
R19/R20 wollte ich nur als alternative drauflassen, falls jemand höhere Spannungen als 60V benutzen möchte (TIP 142 bis 100V). Werde ich sicher nicht brauchen, bei mir hört es i.A. bei 12V auf....
Schnelle Pulse:
bipolare Endstufe vor den MOSFETS klar, aber wer soll den Impulsstrom mit einer Auflösung von <1µs messen?
Ist Strom:
sollte eigentlich an V1 (Label über R35/Q7) gemessen werden können (oder nicht?)
R-Betrieb:
wer kann mir da weiterhelfen, hab bisher keine Idee dazu (Software- oder Hardware Lösung?)
Vorwiderstände für JTAG Interface:
benutzt ich eigentlich fast immer. Hab nur mittlerweile festgestellt, dass der JTAG Ice mkII damit ab und zu Probleme hat. Beim DRAGON hatte ich bisher keine Probleme. Bietet halt ein bisschen Schutz, wenn Debugger und Schaltung in eingeschaltetem Zustand verbunden werden.
MfG
Siegi
Re: EDL
Das wäre ein kleiner Traum von mir: Akku mit Labview (oder besser JLab) überwachen und mit EDL und DCG Entlade- und Ladezyklen fahren, dabei Akku-Kennlinien beachten (je nach Akkutyp), Kapazität ermitteln, ...siegiathome hat geschrieben:-> Hauptzweck Akkupflege
So könnte man auch ein Refresh-Programm schreiben, welches die Akkus durch mehrere Zyklen Entladung (bis kurz vor Tiefentladung) und optimale Ladung wieder ein bißchen in Form bringt. Sowas könnte ja automatisch ein, zwei Tage nebenher laufen und als Ergebnis die Akkukapazität vorher/nachher präsentieren. Das wäre mit einer EDL überhaupt erst machbar.
Thoralt
There are 10 kinds of people in this world: Those who understand binary and those who don't.
Halo Siegi,
sorry
, hatte mich mit den schnellen Pulsen vertan, sollten eigentlich 100µs sein. Das wird üblicher weise zur Aktivierung von Blei-Akkus verwendet und gleichzeitig der Innenwiderstand bestimmt.
V1 hatte ich leider auch übersehen. Ist wohl nicht ganz mein Tag heute.
Klar, damit bekommst Du die Rückmeldung über den Ist-Strom.
JTAG Interface:
Also bislang hatte ich mir noch kein JTAGICE MKII beim hotplug zerstört, ich habe aber schon gehört, das das MKII da etwas empfindlich ist. Den DRAGON verwende ich hauptsächlich für Fire-Wire, so dass ich jetzt zum JTAG dazu nicht viel sagen kann. R27 sollte natürlich auch drin bleiben... Ich habe wohl auch R44 und C21 übersehen... 
R-Betrieb:
Von ELV gibt es zwei EL. Von der computerisierten Version habe ich jetzt leider keine Unterlage gefunden, aber die nicht computerisierte Version kann auch den R-Betrieb. Siehe hier:
http://www.elv-downloads.de/service/man ... 040920.pdf
Der R-Betrieb lässt sich vielleicht über ein R/2R-Netzwerk hardwaremässig, oder per Rückkoppelung der Ist-Spannung per Software realisieren...
Grüsse,
Schimmi
sorry
, hatte mich mit den schnellen Pulsen vertan, sollten eigentlich 100µs sein. Das wird üblicher weise zur Aktivierung von Blei-Akkus verwendet und gleichzeitig der Innenwiderstand bestimmt. V1 hatte ich leider auch übersehen. Ist wohl nicht ganz mein Tag heute.
Klar, damit bekommst Du die Rückmeldung über den Ist-Strom. JTAG Interface:
Also bislang hatte ich mir noch kein JTAGICE MKII beim hotplug zerstört, ich habe aber schon gehört, das das MKII da etwas empfindlich ist. Den DRAGON verwende ich hauptsächlich für Fire-Wire, so dass ich jetzt zum JTAG dazu nicht viel sagen kann.
R27 sollte natürlich auch drin bleiben... Ich habe wohl auch R44 und C21 übersehen... R-Betrieb:
Von ELV gibt es zwei EL. Von der computerisierten Version habe ich jetzt leider keine Unterlage gefunden, aber die nicht computerisierte Version kann auch den R-Betrieb. Siehe hier:
http://www.elv-downloads.de/service/man ... 040920.pdf
Der R-Betrieb lässt sich vielleicht über ein R/2R-Netzwerk hardwaremässig, oder per Rückkoppelung der Ist-Spannung per Software realisieren...
Grüsse,
Schimmi
-
siegiathome
- kann c't-Lab-Module umbauen
- Beiträge: 62
- Registriert: 30.11.2007, 11:43
Hallo zusammen,
hier mal ein Bild von meinem Prototypen. Läuft aktuell an 24V mit 3A, macht also zusammen ca. 75W, Kühlkörpertemperatur bei ca. 70°C...
Den dunklen Fleck auf dem 5W Widerstand unten links hat ein Tastkopf hinterlassen, dem wurde es darauf zu warm...
Wenn Interesse besteht, dann kann ich auch mal ein HEX und EEP File mit der aktuellen FW bereitstellen. Die Kommandos sollten c't Lab konform sein, die Antworten nicht (ist mir jetzt zu viel Aufwand, nachdem amd-65 seine DCG Software veröffentlicht hat).
Was in welcher Form implementiert ist, folgt dann bei Bedarf.
MfG
siegiathome
hier mal ein Bild von meinem Prototypen. Läuft aktuell an 24V mit 3A, macht also zusammen ca. 75W, Kühlkörpertemperatur bei ca. 70°C...
Den dunklen Fleck auf dem 5W Widerstand unten links hat ein Tastkopf hinterlassen, dem wurde es darauf zu warm...
Wenn Interesse besteht, dann kann ich auch mal ein HEX und EEP File mit der aktuellen FW bereitstellen. Die Kommandos sollten c't Lab konform sein, die Antworten nicht (ist mir jetzt zu viel Aufwand, nachdem amd-65 seine DCG Software veröffentlicht hat).
Was in welcher Form implementiert ist, folgt dann bei Bedarf.
MfG
siegiathome
- Dateianhänge
-
- Bild erster Prototyp
- bild_edl_r01.jpg (24.38 KiB) 29300 mal betrachtet
Meine elektronische Last von ELV ist noch einiges simpler als die EL2010. Obwohl die Version schon in einer Ausgabe von 1993 war, hat sie grundsätzlich auch alles drin. Ich könnte bei Bedarf die Schaltung die Tage mal abzeichnen und online stellen.
Es wird der Widerstandsmode sowie konstante Stromsenke und Impulsbetrieb unterstützt.
Interessanterweise ist auf der ELV Homepage auch im Archiv bei der Ausgabe 3/93 kein Hinweis auf die EL mehr zu finden.
Ciao,
Rainer
PS: Ich würde ja den Schaltplan einscannen, aber das könnte leider rechtliche Probleme nach sich ziehen.
Es wird der Widerstandsmode sowie konstante Stromsenke und Impulsbetrieb unterstützt.
Interessanterweise ist auf der ELV Homepage auch im Archiv bei der Ausgabe 3/93 kein Hinweis auf die EL mehr zu finden.
Ciao,
Rainer
PS: Ich würde ja den Schaltplan einscannen, aber das könnte leider rechtliche Probleme nach sich ziehen.
-
siegiathome
- kann c't-Lab-Module umbauen
- Beiträge: 62
- Registriert: 30.11.2007, 11:43
Ich würde es vorziehen, bereits bestehenden Lösungen aus anderen Zeitschriften nicht zu verwenden. Mein Bauch sagt da eher nö. Vielleicht fällt uns ja noch was anderers ein.
Konstante Stromsenke und Impulsbetrieb sollten ja eher das geringere Problem sein. Was mir eher kopfzerbrechen macht, ist der Widerstandsmode. Am einfachsten wäre es natürlich per Software, kann aber dazu aus dem Kopf nicht abschätzen, ob die AD-/DA Wandler Genauigkeiten dazu entsprechende Reserven bieten (in der Billigvariante mit PWM als DA und internem AD sicher nicht). Was da im Schaltplan von ELV so einfach aussieht (Spannung am oberen Ende des Poti an die Eingangsspannung der zu belastenden Quelle) dürfte sich in digitaler Form als Problem erweisen. Es liegt hier ja die volle Spannung an. Das einfachst wäre ja dann noch, die Referenz für den DA Wandler in Abhängigkeit von der Eingangsspannung nachzuführen.
MfG
siegiathome
Konstante Stromsenke und Impulsbetrieb sollten ja eher das geringere Problem sein. Was mir eher kopfzerbrechen macht, ist der Widerstandsmode. Am einfachsten wäre es natürlich per Software, kann aber dazu aus dem Kopf nicht abschätzen, ob die AD-/DA Wandler Genauigkeiten dazu entsprechende Reserven bieten (in der Billigvariante mit PWM als DA und internem AD sicher nicht). Was da im Schaltplan von ELV so einfach aussieht (Spannung am oberen Ende des Poti an die Eingangsspannung der zu belastenden Quelle) dürfte sich in digitaler Form als Problem erweisen. Es liegt hier ja die volle Spannung an. Das einfachst wäre ja dann noch, die Referenz für den DA Wandler in Abhängigkeit von der Eingangsspannung nachzuführen.
MfG
siegiathome
Hallo Siegi,
im Prinzip ist eine R-Last ja nur eine spannungsgesteuerte Stromquelle. Das Problem, wenn wir das softwaretechnisch lösen wollen, ist die Reaktionszeit. Ich müsste mal genauer schauen, wie schnell der mega32 eine analogwert wandeln kann, aber wenn wir mal 30-100 µs annehmen, so ist das für die meisten Anwendungen (z.B. Akkupflege, Netzteile) sicherlich ausreichend.
In Punkto Genauigkeit, wenn ich einmal annehme wir hätten 40V maximale Spannung am Eingang. 40V mit 10 Bit aufgelöst ergeben etwa 40mV pro LSB. Der A/D Wandler im mega32 hat einen Fehler von +-2LSB oder +-80mV. Nehmen wir mal an der D/A Wandler hätte 12 Bit mittels PWM und wier wären im 1A Bereich. Das ergibt eine Auflösung von 250µA pro LSB bei einem Fehler von ebenfalls +-2LSB kämen wir dann auf einen Fehler von +-500µA. Gegebenen falls der Sollwert betrüge 40 Ohm, so haben wir einen Spannungsfehler von 80mv/40V = 0,2% und einen Stromfehler von 500µA/1A= 0,05%. Damit ergibt sich ein absoluter Fehler von +-0,25%@40Ohm.
Nehmen wir mal an, wir sind im gleichen Bereich, geben aber eine R von 1 Ohm vor, so ist der absolute Fehler 0,1 Ohm und damit der relative Fehler 0,1Ohm/1Ohm=10%, was allerdings dann IMHO keinen Sinn mehr macht bei 1V und 1A an Strom die Last zu betreiben. Auch die Parasitärwiderstande bewegen sich in dieser Fall in derselben Grössenordnung.
Wenn man die Genauigkeit noch erhöhen möchte, dann könnte man ja mehrere, schaltbare Spannungsmessbereiche für den A/D-Wandler vorsehen.
Also ich sehe jetzt da kein Problem, die konstant R-Funktion in Software zu implementieren, oder habe ich da etwas übersehen?
Grüsse,
Schimmi
im Prinzip ist eine R-Last ja nur eine spannungsgesteuerte Stromquelle. Das Problem, wenn wir das softwaretechnisch lösen wollen, ist die Reaktionszeit. Ich müsste mal genauer schauen, wie schnell der mega32 eine analogwert wandeln kann, aber wenn wir mal 30-100 µs annehmen, so ist das für die meisten Anwendungen (z.B. Akkupflege, Netzteile) sicherlich ausreichend.
In Punkto Genauigkeit, wenn ich einmal annehme wir hätten 40V maximale Spannung am Eingang. 40V mit 10 Bit aufgelöst ergeben etwa 40mV pro LSB. Der A/D Wandler im mega32 hat einen Fehler von +-2LSB oder +-80mV. Nehmen wir mal an der D/A Wandler hätte 12 Bit mittels PWM und wier wären im 1A Bereich. Das ergibt eine Auflösung von 250µA pro LSB bei einem Fehler von ebenfalls +-2LSB kämen wir dann auf einen Fehler von +-500µA. Gegebenen falls der Sollwert betrüge 40 Ohm, so haben wir einen Spannungsfehler von 80mv/40V = 0,2% und einen Stromfehler von 500µA/1A= 0,05%. Damit ergibt sich ein absoluter Fehler von +-0,25%@40Ohm.
Nehmen wir mal an, wir sind im gleichen Bereich, geben aber eine R von 1 Ohm vor, so ist der absolute Fehler 0,1 Ohm und damit der relative Fehler 0,1Ohm/1Ohm=10%, was allerdings dann IMHO keinen Sinn mehr macht bei 1V und 1A an Strom die Last zu betreiben. Auch die Parasitärwiderstande bewegen sich in dieser Fall in derselben Grössenordnung.
Wenn man die Genauigkeit noch erhöhen möchte, dann könnte man ja mehrere, schaltbare Spannungsmessbereiche für den A/D-Wandler vorsehen.
Also ich sehe jetzt da kein Problem, die konstant R-Funktion in Software zu implementieren, oder habe ich da etwas übersehen?
Grüsse,
Schimmi
Also in der reinen analog Variante ist der Unterschied zwischen konstant-R und konstant-I Mode ja nur eine etwas andere Beschaltung der OpAmps. In der Version die ich habe ist es durch einen einfachen Umschalter gelöst.
Wie wäre es denn, wenn man die Regelung zur Stromentnahme in Hardware realisiert und nur vom Atmega umschalten lassen würde?
Der Atmega würde dann per DA-Wandler die Referenzspannung vorgeben für die Höhe des Stroms respektive Widerstandswertes und per AD-Wandler die Ist-Werte messen. Die eigentliche Regelung würde dann unabhängig vom Atmega rein durch die OpAmps laufen, aber vom Atmega konfiguriert werden.
Ich denke mir eben nur, daß man das Rad nicht neu erfinden muß. Und da die Regelung per Hardware sehr einfach zu realisieren ist und stabil läuft, würde ich eben per Atmega nur die Referenzen für diese Regelung vorgeben lassen und diese Regelung nicht extra in Software versuchen nachzubauen.
Ciao,
Rainer
Wie wäre es denn, wenn man die Regelung zur Stromentnahme in Hardware realisiert und nur vom Atmega umschalten lassen würde?
Der Atmega würde dann per DA-Wandler die Referenzspannung vorgeben für die Höhe des Stroms respektive Widerstandswertes und per AD-Wandler die Ist-Werte messen. Die eigentliche Regelung würde dann unabhängig vom Atmega rein durch die OpAmps laufen, aber vom Atmega konfiguriert werden.
Ich denke mir eben nur, daß man das Rad nicht neu erfinden muß. Und da die Regelung per Hardware sehr einfach zu realisieren ist und stabil läuft, würde ich eben per Atmega nur die Referenzen für diese Regelung vorgeben lassen und diese Regelung nicht extra in Software versuchen nachzubauen.
Ciao,
Rainer
Ich bin unbedingt dafür. Das DCG ist aus gutem Grund auch nicht als digitaler Regler aufgebaut.Rainer hat geschrieben:Und da die Regelung per Hardware sehr einfach zu realisieren ist und stabil läuft, würde ich eben per Atmega nur die Referenzen für diese Regelung vorgeben lassen und diese Regelung nicht extra in Software versuchen nachzubauen.
Thoralt
There are 10 kinds of people in this world: Those who understand binary and those who don't.
Das Problem eines digitalen Reglers für den R-Betrieb ist hier sicherlich bei schnellen Wechseln der Laststpannung/-stromes zu sehen, da ist die analoge Variante klar von Vorteil.
Welche Widerstandsbereich ergeben sich dann?
6 Ohm
60 Ohm
600 Ohm
6000 Ohm
Bei 60Vp und 10Ap/1Ap/100mAp/10mAp?
@Rainer: das mit dem ATmega war ja nur eine Idee...
Grüsse,
Schimmi
Welche Widerstandsbereich ergeben sich dann?
6 Ohm
60 Ohm
600 Ohm
6000 Ohm
Bei 60Vp und 10Ap/1Ap/100mAp/10mAp?
@Rainer: das mit dem ATmega war ja nur eine Idee...
Grüsse,
Schimmi
-
siegiathome
- kann c't-Lab-Module umbauen
- Beiträge: 62
- Registriert: 30.11.2007, 11:43
Klar habe ich etwas übersehen...schimmi hat geschrieben:Also ich sehe jetzt da kein Problem, die konstant R-Funktion in Software zu implementieren, oder habe ich da etwas übersehen?
Eine Regelung, die nur alle 100µs einen neuen Istwert bekommt, braucht erheblich länger >mehrer ms um einen Spannungssprung auszuregeln... Dabei könnte die daran angeschlossene Quelle schaden nehmen, wenn die Regelung der EL zu langsam ist... Das wäre dann der gleich Effekt, wie im DCG beim Umschalten von Strombetrieb in den Spannungsbetrieb.Daher wäre ich auch für die analoge Variante.
Grüsse,
Schimmi