c't-Lab

Hallo Paul,

psclab38 hat geschrieben:[Bezüglich des Arbitrary-Mode: Für die Standardhardware hab ich die Änderungen eingecheckt. Das ist leider ein wenig wie Blindflug, ich kann's nicht testen. Quasi Programmieren durch Nachdenken. (und das, nach DEM Arbeitstag den ich heute hatte. ). Der Fix ist nicht hundertprozentig ideal. Weil die Samples der ISR während dem vollen Lauf (ja, schon atomar) ausgetauscht werden, weiß diese zur Laufzeit (also mitten in der Sequenz) nicht, wo sie exakt steht. Sie macht also weiter bis zum Ende, und wird jetzt hart resetet (auf Index 0, auch wenn der eigentlich bei 1 hätte weitermachen wollen. Aber ungerade gibt's halt bei Standard-HW nicht.
Paul

Funktioniert nicht, Graetz ist jetzt dauerhaft falsch und die 3Peaks sind nicht mehr da.

Gerhard

Hi Gerhard,

gewo hat geschrieben:Funktioniert nicht, Graetz ist jetzt dauerhaft falsch und die 3Peaks sind nicht mehr da.

Doch, es funktioniert! Das sieht vielleicht nicht so aus, aber es funktioniert jetzt besser als vorher. Vorher war da +/-1ms. Das Problem ist halt die gemeinsame Sampletabelle für beide Hardwareoptionen.

Das Blöde ist nur, jetzt greift die Routine immer genau neben die gewünschten Werte. Wir arbeiten hier an der Auflösungsgrenze mit handverlesenen Samples. Wenn man jetzt eine modifizierte Sampletabelle für die Standardhardware laden würde, die nur 2ms-Schritte macht, dann sollte das Ergebnis für Graetz und 3Peaks wieder passen.

Mal überlegen...

Hallo Paul,

oft aber nicht immer "hängt" das DCG wenn ich gleich nach dem Einschalten folgendes mache.
ArbMode->OFF -> Encoder "Enter" -> Mode auswählen und merken das Arbitrary Mode nicht eingeschaltet ist also wieder zurück mit back-> Encoder drehen -> Resultat Panel "hängt", LED leuchtet, Optobus blockiert.

Gerhard

Hallo Gerhard,

gewo hat geschrieben:oft aber nicht immer "hängt" das DCG wenn ich gleich nach dem Einschalten folgendes mache.
ArbMode->OFF -> Encoder "Enter" -> Mode auswählen und merken das Arbitrary Mode nicht eingeschaltet ist also wieder zurück mit back-> Encoder drehen -> Resultat Panel "hängt", LED leuchtet, Optobus blockiert.

Und jetzt hab ich gehofft, Du würdest es nicht merken...
Ich habe mir die Routine, die ich bislang blind codieren mußte, jetzt so umgestrickt, daß ich's auch auf meiner Hardware weitgehend nachstellen kann.

Zu dem Hänger: Es gab da einen Fall, bei dem der Code in einer while-Schleife hängenbleiben konnte, da gibt's jetzt einen Standardausgang mit break. Das war ein Timing-Problem, weil ich die Samples der ISR on-the-fly unterschiebe. Und wenn das erste Sample mal den Zeitwert Null hatte, dann hing's.

Zu den Samples hab ich jetzt folgende Lösung: es gibt für die Standardhardware und die Dual-DAC-Hardware getrennte ROM-Vorlagen. Bei den mit 1ms aufgelösten Samples gibt es immer den Fall, daß "ungerade" Samples übergangen werden. Die Interruptroutine ist auf's korrekte Timing ausgelegt und springt. Wenn ich jedes Sample berücksichtigen würde, dann wäre das Timing daneben.

Für die Standardhardware sollte man bei der Definition eigener Sequenzen nur in 2ms-Schritten vorgehen. Ein 1ms-Raster wird zwar akzeptiert, kann aber unter "Auslassungen" leiden.

Nachtrag:Frage zu den Displayanzeigen im Ripple-Mode: Bist Du Dir sicher, daß die Pascal-FW für`s DCG schön abwechselt für high und low? Einen passenden Code hab ich nur in der Pascal-FW für EDL gefunden aber bei DCG nicht. Ich seh aber wahrscheinlich schon den Wald vor lauter Bäumen nicht...

Viele Grüße
Paul

PS: Ich werde nachher einen neuen Versuch einchecken... damit Du wieder Graetz sehen kannst. Aber mit der DualDAC_Hardware sieht's echt besser aus.

psclab38 hat geschrieben:
Nachtrag:Frage zu den Displayanzeigen im Ripple-Mode: Bist Du Dir sicher, daß die Pascal-FW für`s DCG schön abwechselt für high und low? Einen passenden Code hab ich nur in der Pascal-FW für EDL gefunden aber bei DCG nicht. Ich seh aber wahrscheinlich schon den Wald vor lauter Bäumen nicht...

Ja, zumindest solange bist die Strombegrenzung aktiv wird. Siehe auch hier
-----
DC-Generator, c't-Version mit LTC1257 oder LTC1655
(c) by c't magazin und Carsten Meyer, cm@ctmagazin.de

16.09.2008 #2.91 Relais-Umschaltung ber¸cksichtigt Ripple,
kein Flattern mehr im Grenzbereich
Im Ripple-Betrieb alternierende Sollwert-Anzeige der Spannung,
Umschaltung auf Istwert im ConstCurrent-Mode
-----

PS: Ich werde nachher einen neuen Versuch einchecken... damit Du wieder Graetz sehen kannst. Aber mit der DualDAC_Hardware sieht's echt besser aus.

Der zusätzliche DAC steht steht schon auf der Liste .

Gerhard

gewo hat geschrieben:Ja, zumindest solange bist die Strombegrenzung aktiv wird. Siehe auch hier
-----
DC-Generator, c't-Version mit LTC1257 oder LTC1655
(c) by c't magazin und Carsten Meyer, cm@ctmagazin.de

16.09.2008 #2.91 Relais-Umschaltung ber¸cksichtigt Ripple,
kein Flattern mehr im Grenzbereich
Im Ripple-Betrieb alternierende Sollwert-Anzeige der Spannung,
Umschaltung auf Istwert im ConstCurrent-Mode
-----

JETZT ist bei mir der Groschen endlich gefallen: Bei Pascal-DCG toggeln im Ripplemode die SOLLwerte, nur wenn die Strombegrenzung eingreift, gibt's den ISTwert. Ich hab mir vorhin einen Wolf gesucht, wo denn die Meßwerte paßgenau eingefangen werden, aber DEN Code gibt's ja auch gar nicht.

Ich wollte eigentlich bei DCG2-C schon immer Istwerte anzeigen...
In der Pascal-EDL sind's tatsächlich die ISTwerte für Strom und Spannung, also insgesamt 4. Könnte eng werden: EDL2-C ist fast randvoll.

Der zusätzliche DAC steht steht schon auf der Liste .

Sehr schön!

Hallo Paul,

psclab38 hat geschrieben: Zu dem Hänger: Es gab da einen Fall, bei dem der Code in einer while-Schleife hängenbleiben konnte, da gibt's jetzt einen Standardausgang mit break. Das war ein Timing-Problem, weil ich die Samples der ISR on-the-fly unterschiebe. Und wenn das erste Sample mal den Zeitwert Null hatte, dann hing's.

Gerade die neue Version ge"flasht", klappt jetzt ohne Hänger

Zu den Samples hab ich jetzt folgende Lösung: es gibt für die Standardhardware und die Dual-DAC-Hardware getrennte ROM-Vorlagen. Bei den mit 1ms aufgelösten Samples gibt es immer den Fall, daß "ungerade" Samples übergangen werden. Die Interruptroutine ist auf's korrekte Timing ausgelegt und springt. Wenn ich jedes Sample berücksichtigen würde, dann wäre das Timing daneben.

Für die Standardhardware sollte man bei der Definition eigener Sequenzen nur in 2ms-Schritten vorgehen. Ein 1ms-Raster wird zwar akzeptiert, kann aber unter "Auslassungen" leiden.

Funktioniert jetzt auch.

Gerhard

Hi Gerhard,

gewo hat geschrieben:Gerade die neue Version ge"flasht", klappt jetzt ohne Hänger

Puuuh! Dank´Dir für´s Testen!

psclab38 hat geschrieben:Ich wollte eigentlich bei DCG2-C schon immer Istwerte anzeigen...

Dazu habe ich nochmal meditiert und bin jetzt auf eine recht elegante Lösung gekommen, die für den Ripple-Mode eigentlich immer brav die Istwerte nach einer gewissen settle time für die Ausgangsspannung mißt und anzeigt. Dafür gibt's jetzt auch konsequenterweise eine Weiterentwicklung der R-Symbole, mal mit Strich unten und oben, damit man weiß, was da angezeigt wird.

Nur für die RippleOn- und -Off-Zeiten nahe Null wird's meßtechnisch eng. Und das insbesondere, weil ein RC-Glied die Messung verfälscht: die Widerstände rund um Q1 und inclusive des Kondensators C11 mit 100nF. Sicher gut gemeint und hält auch schön die Störungen von den DACs ab, aber mit ca. 3ms Zeitkonstante kann ich da die Genauigkeit begraben. Das Ausgangssignal ist da (zumindest bei Dual-DAC) nach 3ms schon längst bei mehr als 98% angekommen, da hängt der Meßeingang noch mitten in der Kurve.

Ich könnt mir vorstellen, daß der C11 auch mit 10nF auskommen könnte. Aber wie gesagt, das ist nur die Messung bei kleiner 10ms und da sieht's bei der Standardhardware eh signaltechnisch nicht so schön aus.

Viele Grüße
Paul

Frage am Rande: Gibt's da Interessenten mit 12-Bit-DCG-Hardware für diese Ripple-Spannungsanzeige? Ich hab heute gesehen, daß der beschriebene Aufwand derzeit nur für die 16-bit Variante getrieben wird. Bei Interesse müßte ich da wohl nochmal nachlegen...

UPDATE:Die Änderung hab ich heute, 25.02. 23:30 erst eingecheckt. Hing an ein paar Kleinigkeiten...

Ohne mir jetzt alles durchgelesen zu haben.

Das c't Lab hat doch auch einen Signalgenerator ( gehe ich mal von aus )
Wie wäre es wenn man einen "externen-Referenzeingang" einbaut -
Mit einen Analogschalter oder Relais + kleiner Schutzbeschaltung schalten man
die Sollvorgabe von U/I auf Extern um und koppelt den Signalgenerator ein.

Liebe Grüße
TrippleX

TrippleX hat geschrieben:Ohne mir jetzt alles durchgelesen zu haben.

Das c't Lab hat doch auch einen Signalgenerator ( gehe ich mal von aus )
Wie wäre es wenn man einen "externen-Referenzeingang" einbaut -
Mit einen Analogschalter oder Relais + kleiner Schutzbeschaltung schalten man
die Sollvorgabe von U/I auf Extern um und koppelt den Signalgenerator ein.

Im Prinzip hast Du recht. Die Idee war aber "Arbitrary"-Funktionalität zu haben, und das bietet bislang noch kein Modul für sich.

Außerdem
- hat nicht jeder ein DDS
- müßte man das DCG modifizieren (wir haben da schon einige Modifikationen und die Varianten werden langsam unübersichtlich)
- wäre die Lösung nicht standalone (DCG-only)

Grüße
Paul

Hm, das stimmt auch wieder. Eine Idee - Viele Ansichten.

Liebe Grüße
TrippleX